Apache JMeter Reviews

Load testing is something that we used to do on Apache JMeter. We have regular releases every two weeks with varying features and modules. For major releases, where most of the EPS are modified or new features are introduced with new pages, we perform a performance test once every three to four months. We have a fixed schedule for performance testing before the sale, such as Thanksgiving and Black Friday, to ensure stability and performance during the sales period.

It is an open-source tool that is easy to use. It can be easily integrated with multiple tools, including Selenium. The tool also provides a recording and playback feature, along with the ability for modification and parameterization. Since it is an open-source tool, it can be easily integrated with many other tools, such as BlazeMeter, making the integration process very helpful.

The UI of the solution needs to be better. The UI takes up a lot of our bandwidth. So, we always run on the command line. Hence, improving the UI is needed. If it can be more lightweight, the editing can also be made easier.

I have been using Apache JMeter for four to five years.

Apache JMeter is a stable tool. Around 10,000-12,000 users are using the tool. One can increase its usage, but we haven't done so since we will need multiple machines to be connected to a network to generate the load. So, we haven't exceeded its use beyond 10,000 users.

Apache JMeter is a scalable tool.

We haven't used the solution's technical support.

We used other solutions in the past, but they were costly since they require a license, whereas Apache JMeter is free. Hence, we prefer Apace JMeter.

The solution's initial setup process was straightforward since setup can be done by opening a JAR file. It can be deployed in half an hour. Experienced people can deploy it in 15-20 mins, and newer ones may take up to an hour.

Also, we don't deploy on any server. Normally, the tests are on local ones.

For deployment and maintenance, you need knowledge of scripting and APIs. But otherwise, maintenance should be easy. Once you record and have the script ready, until and unless there are modifications to the application, maintaining it should not be much hassle.

The implementation was done in-house.

There is no investment as such. Only the resourcing part is there in the tool.

Apache JMeter is a free tool.

I recommend Apache JMeter to others who want to use it. I rate the overall solution an eight out of ten.

I've used JMeter in conjunction with Selenium, Java, and Log4j for logging. I used it before
I ended that contract in August. Its version was up to date at that time.

It was used for an e-commerce site that is specialized in C-PAP or weaving machines in effect. Their max was a thousand people logged in at once. I, of course, pushed the boundaries on that, but it was to test the performance of the website, and of course, I'm had to try subsystems, database interactions, etc.

I'm a total geek, so I liked the fact that I got to program. The biggest thing I liked about it is that there is a huge user base out there, and being shareware and being Apache, if I have any question on how to get something done, I get 18 different answers. Out of those, there would be at least a few good approaches for what I was trying to do. So, the support system out there is most valuable.

I sometimes found the documentation to be not as explanatory as I would've liked it. In the cases that I can think of, I was looking for a rather hand-holding approach with Step A, B, and C, but then I realized that with a product that is open source like this, you can't do handholding. That is because there are so many different uses and different unique environments and setups for it, but I remember thinking a few times that if they only just said this.

If I were going to be Mr. Selfish and say anything I want, I'd say a full feature GUI that lets me drag and drop different modules in line. It could have a simple-to-use GUI.

I have been using this solution for probably a year and a half.

I didn't have any issues with the stability of JMeter itself. There were definitely issues with the program I was testing, but that's why I was testing it.

It was very easy to scale, but I was barely scratching the surface. I have spent 17 years at Microsoft, and for the performance testing that we did there, we had 8.3 million users at once, as opposed to a maximum of a thousand. If I'm scaling, I have to do it quite straightforward and simple, but it was very minimal.

Only I was using it. It was the QA department. I showed it to some of the devs, and they were very interested. A couple of them tried it, but none were actually using it day-to-day for testing out the environment.

I would rate them an eight out of 10 because sometimes, they would take two or three days to get back to me. Of course, at that point, you're like, "I need the answer; I need to answer." So, it was a little bit unrealistic in terms of expectations.

At that particular company, I was the one who was tasked with coming up with the solution, so that was the only one that I looked at simply because JMeter is industry standard, but at Microsoft, they wrote their own custom tools, so I used custom Microsoft tools.

It was rather complex. It is a complex product, but that part of it was very well-documented. I didn't have any problems with it.

Don't be shy in asking questions. Google/Bing is your friend. It is complicated. There's no reason to spend eight hours trying to figure out something, except unless you are trying to learn in-depth. There are a lot of people who've done exactly what you're trying to do, and it doesn't matter what it is.

I would rate it a 10 out of 10 because it is industry standard. It did everything I could've asked. I barely scratched the surface, but what I needed it for, it did well and in a very straightforward-to-implement way.

We primarily use the solution to manage our capabilities. Wherever the business goes, we need to work within the expected benchmark. In terms of the user bases we deal with, most of these are products from different locations with different types of functional flow-out. There are environmental integrations also running in the background, which a user is basically accessing while going through a particular workflow. 

We'll also handle the reporting section of our data management responsibilities utilizing this system.

The reports and analysis tools are very good. They are the solution's most valuable features.

The GUI could be improved. When we go into GUI mode, there are occasions where it will not sync with our expectations. There are crashes that happen that will stop the solution from performing. It seems we get minor glitches when we go into GUI mode.  

The data client architecture that we have isn't so great. If we are to consume the data, it won't clear because there is tech running on different agents. 

When I need to pull the reports from different agents, it's not user-friendly. The reporting can be difficult to handle. It's hard to increase it if you are working on a client's architecture.

It's not easy to get the data from one place or to do customizations. 

There are other solutions that allow users to model their load and structure with them. You can't do that on JMeter. 

On other solutions, like Silk Performer, you can do network packeting, which you can't do on JMeter. They should add this to the solution as a capability in the future.

The support management needs improvement. Support is coming from consultants; you will not be able to get on-premise support from all of their agents in one place. On Silk Performer, for example,  they have the capability where you can basically have a summarized report from different agents.

Personally I've been using the solution for the last 10 years. However, in the program we are in, I've only been using this tool for six months.

If you want stability, you will have trouble, because the system is not uniform. You have to do a lot of modeling. 

If you're talking about mobile platforms, JMeter will not allow you to capture the performance of applications on your mobile platform. It's an area where the solution is lacking. It doesn't have the capability to allow developers to check the performance on an AP app.

You can scale the solution, but you will run into issues if you want to run, say, 1,000 users.  You will have to configure multiple agents and then distribute your load. It's quite difficult to manage everything on a single agent.

The initial setup is straightforward. We found it quite easy. For us, it wasn't complex at all. The solution is up and running quite quickly and doesn't take long at all to set up and deploy.

We've looked at Silk Impact and Load Balancer in the past. Each of these solutions offers a few different functionalities that aren't necessarily available on JMeter. For example, on both, there are more network features available that aren't included in JMeter and you can model your load and structure with them as well.

If companies have mobile development, they should use JMeter. If they want to integrate it with the PA pipeline, JMeter will work well. However, there are other platforms and solutions as well.

Other options include Silk Performer and Load Impact. These two solutions have other capabilities that JMeter doesn't have. You can basically model your load and structure with them. You can't do that on this solution. On Silk Performer, you can also do network packeting, which you can't do on JMeter.

Then there are some network features available in Load Impact as well as Silk Performer that aren't in JMeter. 

I'd rate the solution eight out of ten. The solution has certain limitations, but it's still a good product. 

The use cases are mainly for performance testing and for test case management of the different APIs.

Initially, we didn't have any tool for performance testing, particularly open source. JMeter, since it is open source, we can test our APIs pretty quickly and we can work with different teams to provide performance testing very quickly. It doesn't take up much of our time.

The ease of scripting is great. 

The modular design is very useful.

It is easy to set up.

The solution is stable.

It can scale well. 

If JMeter could provide a web version of editing, that would be good. 

If JMeter can provide its own cloud version rather than depending on BlazeMeter, the commercial version of JMeter, that would be ideal. If we could have somebody right on the front end of JMeter, using it on any of the clouds, including AWS, GCP, or Azure, that would be very helpful. it would be better than me going for using commercial services.

I would like to have some kind of cloud version that can be implemented. Or we would like a Docker version. A Docker version is something that I would look for.

I've been using the solution for four or more years. 

It is a stable, reliable product. There are no bugs or glitched. It doesn't crash or freeze.

The solution has been scalable. 

We have almost 100 users on the solution. 

We likely won't increase usage in the future.

I do have some knowledge of technical support. 

This is an open-source tool. If I write any issue in the forums, somebody will answer it pretty quickly. The open source technical support they have on offer is good.

We did use a different solution previously. 

Most people know JMeter more than the other tools. It's easy to learn and quick to execute. It's also open source. You can get a lot of solutions across the internet. If you are having some issue or error, somebody or the other may have faced that same issue, and he may have found out the solution. It makes troubleshooting easy, having crowdsourced troubleshooting. That was a factor in our decision-making. 

The initial setup is not straightforward. It's simple and not complex at all. 

We only need two people to maintain the product. It doesn't take a lot of staff. 

We have our own in-house team that can handle the setup. 

We've definitely seen an ROI. 

We use an open-source version of the product. However, there are cloud services that we use. I'm not sure of the cost of the cloud services.

We looked into Micro Focus and Cavisson NetStorm. However, they were licensed tools, and we decided against them. 

We are using the latest version of the solution. 

We are using a cloud version of JMeter that is called BlazeMeter.

If you are a company that is evaluating other licensed tools, just go for JMeter. It's open source, easy to use, and the most widely used across platforms. It would be much simpler than using the other licensed tools. Other licensed tools may have pretty good technical support. However, most problems with JMeter can be solved using the solutions that are available on the internet.

I'd rate the solution eight out of ten.

I've been using JMeter mainly for performance testing and some repair testing as well.

The solution is open source, so we don't have to pay for anything. That is a good thing since we can save the licensing costs, et cetera, as an organization. If you go for an expensive tool like LoadRunner or even Loyalty or Locust, you'll have to spend from your budget. JMeter has everything we need without the cost.

It's a powerful tool that is open source. There are various functionalities that can be used in various combinations. You can use Jmeter for automation, like getting some APIs. You can use JMeter for the performance testing. You can add listeners. You can look at the results and can generate a load with JMeter. The beauty of JMeter is there is a lot of support from the communities online who have worked on JMeter and can give first-hand advice. Most of our queries are already answered by someone, so we get the benefit of learning from them. 

It's a good tool for automated performance testing and some behavioral things.

It has a lot of customizable features. There are a lot of open libraries that you can download, and each time when you go for a new requirement, you will get new libraries. 

The setup is pretty easy.

The only thing is the learning curve. It's high.

We'd like to see more third-party integrations that can be handled quickly.

Support-wise, while the community is strong, it would be nice to have the option to reach out directly to JMeter. 

For performance testing, you need to correlate, et cetera, so we have to do it manually in order to get the right to regular expressions.

I've been using the solution for five years. 

As an open-source tool, when changes happen, it may be a bit unstable. This is occasional, and for the most part, it is fine. I'd rate it seven out of ten in terms of stability. 

The solution is scalable. I'd rate it ten out of ten.

While there isn't any traditional support, there is a very strong community around the solution. There are so many people using it and contributing to solving problems, you can easily find answers to your queries online.

The solution is straightforward to set up. I'd rate it five out of ten. There is a bit of a learning curve at first, however, once you start using it and taking advantage of its capabilities, I'd rate it nine out of ten. 

In the areas where we do some prototyping and also some areas where we want to save money and not focus on the revenue, we use JMeter. It's a very powerful tool. 

This is an open-source solution and is, therefore, free to use. 

I'm a customer and end-user.

I'm not sure which version of the solution I'm using. It's not the latest, however. It may be about one year old. 

You can deploy both on-premises and on the cloud. 

Once you go ahead and implement JMeter and you learn the process, it's a great tool. It could be a great asset for any organization as it is a highly customizable tool. If you can handle the learning curve, it will be worth it. Plus, as an open-source tool, you can save a lot of money on licensing. 

I'd rate the solution eight out of ten. 

The primary use case for the solution is to test web applications.

The most valuable feature is that the solution is open source.

There are a lot of areas in this solution that can use improvement. The solution is not user-friendly, there is no framework for autocorrelation or parameterization.

I have been using the solution for a little over one year.

The new version of the solution is stable.

The initial setup is straightforward as long as you do not require an advanced setup, which can be difficult. The basic setup takes only one hour.

The solution is open-source.

I give the solution

The only support available for the solution is online because it is open-source and does not come with technical support.

To anyone that is thinking of using the solution, I suggest you familiarize yourself with regular expression.

I am using JMeter only to test some web services.

You can moderate some transactions which aren't available to too many users. You can use JMeter and compress as needed or to support as many users as possible. 

I am a basic user. I couldn't explain the different features deeply. I use, for example, the web services. I like the features where you are programming at an increased rate in web services. I use those features. For example, as part of using our web services, if there are 100 transactions with three threads, and I want to finish with 5,000 transactions with 20 threads on different pages, I can find the rate which my server used on each page. I like this feature in JMeter.

It's easy to set up.

Apache should have a graphic interface. That would help beginner users a lot. Sometimes it's hard to do what you need to do via the command line. 

I've been using the solution for around two or three years. 

The solution is stable. There are no bugs or glitches, and it doesn't crash or freeze.

The solution can scale. However, it requires configuration to do so. I don't have much knowledge in regards to how to scale exactly.

On the other hand, if you have a cloud server with 10 servers and you are using the same DNS for all servers, as all servers are working with the same application, and you have for example a load balancer that provides balancing to each one of these ten servers, I am not sure if Apache JMeter will report the different servers separately. I imagine not.

Different implementations of JMeter Runtime could be used to point to each one of these 10 servers. You can use JMeter in different OS, for example, Windows, Linux, or Unix. You have a lot of features to use different instances with JMeter. However, this load balancer concept would be harder to explain.

Right now, we have around two or three guys working directly with the product.

We are evaluating automatization apps currently. We are using Jenkins, and I am sure we will start with JMeter later. However, I have not defined a roadmap to expanding usage of this product just yet.

I have not used technical support.

I have used some other solution previously. However, I cannot recall the name. It was likely SoapUI. We picked up JMeter as it is free to start with and easy to pick up.

The product is simple to set up. 

For example, you can just support Apache JMeter with the Java installer feature, which downloads the JDK or Java Runtime from the Oracle pages, for example. Or you can add the Runtime as a part of your installer, and after the installation, have a common user in Windows, for example, as an option. There is some knowledge of Java needed, and you do need to use the command line. Some may feel a bit lost when they start. However, there are different ways to do it according to your comfort level. 

It should have something for the front-end user to help them prepare the environment correctly, however.

We have two to three people handling the maintenance of the product at this time. 

I have not really noticed a return on investment. 

I cannot recall the exact version number we are using. I always download the latest. 

We are currently using our own servers to provide the network.

I recommend JMeter if your goal is to design some stress tests. JMeter has some features. For example, you can start with tests on the command line. You can join instantly on our current deployment batches. Jenkins has some support for JMeter as well. On another hand, you can make a simple bridge to start the JMeter process with the command line in the same Jenkins deployment. You have a lot of features on hand.

I'd rate the solution eight out of ten.

Our primary use case for the solution is comprehensive performance testing. It measures how our applications are doing overall with a lot of users. For example, if we want to simulate 100 users doing transactions simultaneously, we want to see if our app handles it well and how fast it responds. In addition, we can utilize the solution to identify time spent on operations.

We find the ease of use and the reports and graphs available valuable.

The solution needs more metrics for reporting.

We have been using the solution for two years.

The solution is stable, and we have not had any issues.

The solution is scalable, but I cannot comment on the extent of its scalability because we have yet to scale widely.

We have not had experience with customer service and support.

The initial setup is straightforward.

We use the tool as an open-source tool, so we do not pay for it.

We chose this solution because of its affordable cost, ease of use, and popularity.

I rate the solution a nine out of ten. I advise users considering this solution to take a course to get familiar with it quickly.