Apache JMeter Reviews

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.

We've been using Apache JMeter for load testing, spike testing, and endurance testing. We use the solution mostly for nonfunctional use cases, except for the security aspects, because those aspects require a different tool altogether.

What I like best about Apache JMeter is its user-friendly GUI because even if you don't have very good coding knowledge or understanding, or even if you don't come from a development background, you can still use the solution with just a few clicks. This is what's unique about Apache JMeter, in comparison with other tools in the market.

As Apache JMeter is open source, when there's a missing feature, you can search in several community blogs for plugins that you can use to modify Apache JMeter to meet your requirements, and this is another advantage.

What needs improvement in Apache JMeter is the very high load requirements when you want to scale it beyond certain thresholds. For example, small to mid-range testing is very easily done with Apache JMeter, but if you scale and increase the load, then it would be a problem because the tool consumes a lot of resources, probably because Apache JMeter provides an enriched UI experience, so it consumes a lot of memory and requires high CPU usage. This means you have to manage your infrastructure, or else you'll have high overhead expenses.

As Apache JMeter is a heavyweight tool, that is an area for improvement, though I'm unsure if Apache can do something about it because it could be a result of the way it's architected.

What I'd like to see from Apache JMeter in the future is for it to transition to the cloud, as a lot of cloud technologies emerge around the globe, and a lot of people prefer cloud-based solutions or cloud-native tools. Even if a company has a legacy system, it's still possible to transition to the cloud. I've worked with a company that was an on-premise company that moved to the cloud and became cloud-native. If Apache JMeter could transition to the cloud, similar to k6, then it could help lessen the intense resource consumption that's currently happening in Apache JMeter.

I've been using Apache JMeter since 2020, so it's been two years since I started using it.

Apache JMeter is a stable product overall. A very large community in the software industry uses Apache JMeter, and though it's open source and there's a continuous phase of improvement going on with it, it has stable versions available for my company to continue testing it.

Apache JMeter is scalable in the sense that there's a master/slave architecture available for it where I can scale as many slaves along the way, but when a huge number of users is required in a particular load test, and you have to scale a lot beyond a particular threshold, the resource consumption becomes too high and requires considerable overhead. Apache JMeter consumes a lot of memory, and that's a hurdle, but it's scalable up to a certain point. If a very, very large organization requires very heavy load testing to be done, it would be better for that organization to go with some other tool.

Because Apache JMeter is an open-source tool, you get support from the community. The challenge with open-source tools is that if there isn't enough community, then the support and development you get would be limited, but as Apache JMeter is widely used, the community is vast and the support is sound. Unlike with Micro Focus LoadRunner, when you encounter an issue, you can report that to Micro Focus and the Micro Focus team will take care of your issue. It doesn't work that way with open-source solutions.

For the support I get from the community, on a scale of one to five, I'm rating it a three because there could be instances where you could not get a resolution for your issue. After all, Apache JMeter is a free product, so you can only rely on community support. Though the community for the tool is so big and Apache JMeter is widely used, and there'd be a lesser amount of circumstances where the solution for your issue isn't available yet, there could be between one percent to five percent chance of it happening, so that could be troublesome.

The initial setup for Apache JMeter is pretty simple. There isn't much dependency, in general. For example, in macOS, you can just download the tar files entirely and just untar the files. There's no installation of specific extensions required. That's for macOS. For Windows, there would be .exe files. From that perspective, setting up Apache JMeter is quite easy. You can just run it locally, untarring it in any particular location. Just one setup that's required to be done is setting the Java home path to start the app. Otherwise, it's pretty straightforward and very quick to set up.

On a scale of one to five, I'm rating the initial setup a four because there's always some room for improvement.

Apache JMeter is an open-source solution, so it's free to use.

I evaluated k6 and Locust.

I'm using Apache JMeter for work. Locust is also used within the company, as well as k6, but I only touched base on those solutions.

The projects I'm working on currently use Apache JMeter, but my company works across regions and uses different tools, including Gatling and Locust.

Apache JMeter is used daily, for the range of projects I've been testing it on. A new government project came in, and I chose Apache JMeter for it because of its simplicity and user-friendly interface.

My rating for Apache JMeter is seven out of ten.

Our company uses the solution for performance testing on web applications, API load testing, and automation of APIs and web applications. The solution provides three streams of use. 

We also integrate Selenium with the solution to perform automation testing. 

The solution has good transition controllers and distributed testing. 

The solution's setup could be easier and security could be improved to minimize vulnerabilities. 

I have been using the solution for four years.

The solution is used to test the stability of other applications through a three-step process. 

Load tests look at the CPU, memory, and APM tool and assess the current load to determine if it can be increased from 60% to 70% for example. You continuously monitor the APM to see fluctuations in memory and CPU usage. If load tests are successful, then you move on to stress tests. 

Stress tests find bottlenecks and determine how many users the application can handle within the current infrastructure. Baseline tests can be performed to determine results such as response time when increasing users. 

Endurance tests determine if an application is stable and for how long stability can be expected. For an endurance test, you set up a particular user load and run it for at least eight hours but up to twenty-four hours. During this time, you see how the application is behaving and whether the CPU and memory are stable. This will allow you to assess overall stability without OOM leakages. 

The solution determines if there are lags in application performance. For one project with 500 continuous users per hour, we used the solution to find that there were only two lags from 50,000 samples generated.  

The solution is used to perform baseline tests for applications and compare them to SLAs to determine user load and scalability. 

I have not needed technical support. 

The initial setup can be complex depending on the application you want to test. 

If the application is straightforward without much logic, then setup is easy and only requires a simple transaction controller. This scenario is common for users who log in, perform simple actions within 15 minutes, and log out. 

Applications with internal logic require scripting that includes sample JSON extractors, pre- and post-processes, transition and throughput controllers, and precision throughput timers. This scenario is common for users who perform multiple actions over a longer period of time, is not straightforward, and involves multiple transaction controllers. 

Our company implements the solution for customers.

First, we ask our customers about critical work flows and categorize them based on user loads to create a workload model. Then, we create scripts and proceed with testing. 

Often, we request access to a remote desktop for installing scripts and resetting networks. We follow the workload model to initiate load, stress, and endurance tests. 

The solution is open source with no user fees or licenses. 

The solution is comparable to LoadRunner because it works with multiple plugins but is free to use. 

I recommend the solution and rate it a eight out of ten. 

The solution is open source so on occasion there are security vulnerabilities. 

There's a third-party platform that is getting migrated to, so with the newer version migration, we were looking to see if there are any performance degradation with the migration. The product platform assures the user loads that we are planning to have on the system. Nevertheless, we wanted to have validation from a business perspective. We wanted to see that it'll still support the loads that we are looking at.

The ability to create a large number of user loads has been very helpful for us. 

It's typically straightforward to set up. 

The solution can scale well.

It's stable and reliable. 

There is lots of useful community support. 

In terms of platform support, they need to extend the support for backend platforms and more of the legacy types of platforms.

We've used the solution for a long while. We've used it for a few years. 

It's a well-trusted product. A lot of people use it. There's a lot of support in the community also. Therefore, the stability is pretty good and it is quite reliable.

We can create demand as we need. It's quite scalable. 

We have five people suing the product. The performance testers use it.

We can get a lot of support from the community. It's pretty easy to get assistance. 

We've had no issue so far when we've needed to get help. We are satisfied with the support. 

Positive

We did not previously use a different solution. 

The solution can be easy to set up depending on the target system that we are testing. However, there are situations where Apache JMeter is not supported.

The deployment took two to three weeks to set up and deploy.

We have a team of five people that can handle deployment and maintenance. 

We did the setup in-house. We have the capabilities within.

Most of the time, it's the end client who manages the license for us. We don't purchase the product by ourselves; it's the end customer who does it for us. I'm not sure what the actual cost of the product is. 

We likely are using the latest version of the solution. However, I can't be sure. I'm not sure which version number we're using. 

It's a tool that is being used by many, many others as well. There's a lot of community support out there. I'd recommend it, as long as it supports the platform.

I'd rate the solution seven out of ten. 

We use this solution to load test functional behavior, and measure performance.

We really appreciate that the solution comes with a live community, which continuously provided plugins and support protocols.

We would like some reporting and analysis tools to be added to this solution.

We would also like the manual available for this solution to allow for better usability; it can be quite complex for new users, and the product is not always very intuitive. 

We have been working with this solution for 12 years.

We have found this solution to be a stable and reliable tool.

This solution is easily scalable, you can distribute the larger generation among several machines in the LAN, or you can use the cloud variation of the product.

This solution doesn't come with technical support, but there is plug-in wide community support, where organizations can ask questions about issues they are experiencing.

This solution isn't actually deployed, it is a zip file, which is extracted. It can also be deployed via public cloud, if an organization chooses the cloud-based model.

This is an open-source solution, so there are no licensing costs involved.

We would recommend that organizations considering this solution invest time in research of the product before implementing it. There are a lot of online resources that can assist with this, so the business can check if the solution will meet their requirements.

I would rate this solution an eight out of ten.

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.

We use this solution for functional API testing, and performance testing.

This solution allows us to test all the functional APIs through it, then record and run the APIs.

This solution is easier to use than any other tool in the market; there is not even a requirement to learn a lot of scripting in order to use it.

We also appreciate that the solution is open source, so it has a very big community to utilize if we need help with an issue.

At present, if the number of virtual users increases beyond 10,000 when testing, then it results in a Java heap which causes the solution to crash.

I have been working with this solution for around seven years.

The stability of this product is good, outside of the issues with adding virtual users during testing.

This solution is scalable, but only up to a certain point when adding virtual users, before performance issues begin to occur.

The initial setup of this solution was quite straightforward, and deployment only took one to two minutes.

We implemented this solution using our in-house team.

This is an open-source solution, so there are no licensing costs associated with it.

We would recommend this solution to any QA or developer as a 'must-try product'.

I would rate this solution an eight out of ten.

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.