Apache JMeter Reviews

The most valuable feature of this solution is being able to launch many requests and scheduling simulating human interactions with the application. There are some other plugins for monitoring and collecting data for JMeter but we don't use them. 

If JMeter could integrate with the EPM solution, it would be great. It could also be improved by offering more integrations for security. For example, most applications are secure with OpenID Connect protocols.

I have been using this solution for more than 10 years.

This is a stable solution. 

We previously used Katalon. 

The initial setup is straightforward. 

I would rate this solution an 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.

I use JMeter for concurrency and some backend services. We are also using JMeter to apply our tests within our framework by sending some requests to JMeter to assess our application's performance. My company is developing software based on data analytics that produces insights and graphs like Tableau or Power BI. We use JMeter to test the graphs, how the tables are rendered, and how long it takes to render some applications. 

For instance, we have a problem with one of our clients that use some complex scenarios or queries that take too much time to retrieve from the application or render to the end user. We ran a couple of tests on the application using JMeter and spotted the service or request that was taking too much time.We alerted the developers about this, and they took the appropriate action to fix this problem. Afterward, we run another cycle of JMeter to ensure everything is working as expected.

There are two modules. The analytics module is the interface for the stakeholders and company decision-makers. The number of users isn't that big, unlike the retail applications websites. It's 500 users at most. The other module is deals with data volume. We are currently doing some POCs to check whether we will benefit from JMeter in this area because it's not a concurrency issue. It's a data volume issue.

We have a hybrid deployment because we are using JMeter to assess the performance of our products. If the product is deployed on the cloud, we use JMeter on the cloud. If it's on-prem, we are using it on-prem. At my previous company, we mainly used JMeter on-prem.

I expect that we will continue to rely more on JMeter, and we have multiple DevOps pipelines using JMeter to test another module in our application.

I use all the tools, but one feature that stands out is JMeter's ability to test when services are sending a particular kind of request. We are using specific ports to send queries, and assess the performance based on the time it takes these queries to respond. You can use it with stuff other than the web performance.

The UI needs some work. The first time I used JMeter, I couldn't record the full scenario to mimic the user experience. Since then, they have introduced some plugins and a third-party tool called BlazeMeter. It's working on this, actually.

It's an excellent plugin that you can use to record the scenario from Google Chrome, and it integrates easily into JMeter. They could also make it easier to generate the built-in report. Now, you run the tests and generate the charts in a separate column. The graphs and charts that display the test metrics could be better.

I worked with another tool called Web Performance Tester, and its interface is better than JMeter's. They have intuitive graphs while you are running the tests, so you can see how things are going. It shows you the number of concurrent users logged into the system, the number of failures, response times, etc.

I worked in performance testing from 2011 until 2019. I was working with another tool, but in the last few years, I started using JMeter for a couple of projects.

It's hard to say definitively. When there's something wrong with JMeter, we're unsure whether it's something in the device because there are lots of requests coming from the machine. Maybe we didn't use it that many times from our local server. There are some bottlenecks, but in many cases, we only need to restart JMeter, and it works fine.

JMeter is scalable. I did a test using it in a distributed environment with more than one client. We used JMeter to load from the server and also the plugin tool. It works fairly well in a complex environment. I still need to research the maximum concurrent JMeter can handle. Is it 1 billion or 10 million? 

In my work experience, I need to load maybe 1 million users. For example, most of my work is on the backend of e-commerce websites with a maximum of 1,000 users. We have many clients, but the load is not that big. 

I don't think JMeter has technical support because it's an open-source application, but there is support for third-party apps that use JMeter. For instance, BlazeMeter has good technical support.

I have more experience in a tool called Web Performance Tester, but it has some limitations. For example, it doesn't support some forms. A long time ago, their support was better, but lately, their support hasn't been so good. They always ask us to switch to the consultancy service and they don't give us the solution. If we face problems, they always tell us, "Okay. You can consult us." This is not a good practice, actually.

Also, Web Performance Tester isn't well-known, so some of our clients aren't confident in it because it doesn't have a reputation.  They were more familiar with JMeter, and it's something I've used.  However, I have no problem with Web Performance Tester. It's hard to compare the two tools because it's not apples to apples. 

I joined this company in October, and they had just started using JMeter. Previously, they were using a tool that they had developed in-house. They found that JMeter has more capabilities and specificity than the tools they were using.

Setting up JMeter is straightforward. It doesn't need an installation like other tools. There is a batch file for Windows. Around four people in my organization are responsible for maintaining and managing JMeter.

JMeter is a free open-source tool. There are some third-party tools built on top of JMeter that have a license or something like BlazeMeter. I think you can also purchase some additional services.

I rate Apache JMeter eight out of 10.  Before using JMeter, you should find some tutorials because you need to be trained to use it. It's not a plug-and-play tool. This is what I did. Spend some time researching JMeter's capabilities. We met a lot of people who knew about JMeter, but when you tell them that it can do something, they're not aware of it. 

For instance, through taking some courses, we learned that JMeter has distributed performance capabilities. Some people still know that you can't make these recordable scenarios. This information hasn't reached everyone in the IT market.

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.

We primarily use the solution for performance and delivery testing.

It's a free tool. It's a very common tool. There's a lot of support in the community for this. It mainly supports web API testing.

The UI could be better. It can have some Reach UI also, which would be helpful, and maybe a relatively simpler way of using it. It needs simple modules. There are quite a lot of things which are kind of abandoned, so they can definitely improve on it.

Integration with some of the other features should be managed. However, it's open source, so there is not much to complain about there.

It's an open-source tool; we cannot ask for additional features really.

The product could use some kind of filtering and monitoring and different degree of dashboards and analysis. If that can be provided, that would be very, very helpful.

I’ve used the solution since 2009.

The solution is relatively stable. There are no bugs or glitches, and it doesn’t crash o freeze. It’s reliable.

It can scale. However, what others say about scalability is that you need to have some proper calculations to be done first.

We have dealt with support. Technical support is found in more technical forums. It’s open-source, and communes are where you go for information. We have received good responses when we have inquiries. There are quite a lot of forums in general available.

Now, as we have grown as an organization or as a team, there are still questions such as, "What are the limitations of this tool?" And we put that to JMeter so we can learn what is best for the maintenance.

The installation can be a bit complex. There are quite a lot of things and issues if you go deep into it and if you're setting up JMeter. For example, direct script captioning is slightly different. It's a bit more complex, the correlation parametrization. Setting up the workload model can be complex as it is based on a Java service mechanism.

It becomes a bit challenging to manage. If I want to put a 50,000 user load, I have to be very careful how the memory is utilized. I must be very aware of the underlying system's capability to execute this. I have to make it into multiple nodes and run them in parallel. There are some calculations, and there are some good power processes that will be required when you are using JMeter. You need to understand its limitations and load work them on.

The solution doesn’t really need maintenance. They're open-source tools, so we don't expect any maintenance. What we typically do is we pick up a particular version and understand the limitations of it. We then play within those limitations.

We handled the initial setup in-house. I handled the setup myself.

The solution is free to use.

We may be using the latest version. I don’t know the exact version number.

It is on-prem. However, we can put it on the cloud as well. We install it on any machine, so it can be a local or cloud-based machine.

I’d recommend JMeter. One critical piece of advice is to plan properly. For JMeter, planning and having an understanding of the limitations are important. If you play within those limitations, it is a really great tool. There are trade rules that apply to a lot of things that we use. However, there's plenty of material available so far. Whoever is doing it, can plan it accordingly. They can create those tests, and execute those tests. That said, at the same time, be aware of the scalability of the JMeter. For example, a single JMeter line, which is running, can take 1,000 to 2,000 threats, not more than that. Again, it depends on the available hardware. If you want to scale to, say, one million or something, different parts of planning are needed.

I’d rate the solution eight out of ten.

We use JMeter for performance testing. Our testing team has 50 to 60 people.

JMeter lets us generate virtual users and T-load, per our requirements. It's easy to configure and adjusting the virtual users according to the DPS we want to achieve.

It should be easier to combine multiple scripts. If you have multiple scripts, you need to write a new script to combine those scripts. The virtual user generator is slow.

We've been using JMeter for six months.

With an on-premises deployment, we run into some performance problems when we have a high load. It's not that stable if we increase the scripts or the load. But that could be something in our environment.

JMeter is an on-premise solution, so it has limited scalability. We are looking for a cloud-based solution that is scalable and elastic. 

I rate JMeter six out of 10.

We have a couple of applications in banking.

It's an open-source tool, Apache JMeter. 

It's easy to customize. Customization depends on the requirements, however. It provides an enormous amount of plugins. Based on the customer requirements, we can customize our code and we can go out and execute the test. JMeter integrates well with Jenkins. The cloud offers CI/CD activity. 

The solution is scalable.

The stability is good. 

Its initial setup is very easy.

There is good documentation available. 

Until now, JMeter is not supporting most of the protocols. It's widely using web HTTP and a few other protocols as well, however, it's not supporting the SAP or Citrix ones. Protocol-wise, the JMeter needs to improve.

Recently, there was a Log4j error. They have since mitigated that, in JMeter, for the free version. The security concern was handled quite well compared to the previous versions.

I've been dealing with the solution for more than five years.

The solution has been stable. There are no bugs or glitches. It doesn't crash or freeze. It's reliable. 

It's scalable. We have very good load balancing or load distribution. It will be very easy for us to add multiple machines and make whatever we need. However much we want, we can scale.

It is very easy to set up. It's not overly complex or difficult. 

The solution does offer a free version. 

I'd rate the solution eight out of ten.

Regardless of, whether it is used for personal performance, load, volume, UI test, or functional test Apache JMeter is the best tool on the market.

It is cost-effective and simple to use.

Take, for example, a performance test with, the Micro Focus performance test tool, and compare it to Apache JMeter. Apache JMeter is far less expensive than HP Performance Center.

When you run tests with JMeter, it generates test version five, which is extremely large. Also, when you have a large number of tests to run, it requires a large size or memory size, which basically means it consumes a lot of memory. It would be helpful to come up with a way to be able to use Apache JMeter in a way where it did not use as much memory. It will be much easier, and beneficial for the individual to run it on their own machines rather than having a high-end infrastructure, more CPUs, or more memory that has been consumed by Apache JMeter.

I have been working with Apache JMeter for two years now.

I am working with the latest version.

It's on digital platforms rather than the cloud.

I am absolutely satisfied with the stability of Apache JMeter.

Apache JMeter is a scalable product. We are pleased with the scalability of this solution.

When we have encountered difficulties and reached out to technical support, they respond very quickly and most of the things are readily available with them, for all of the challenges or support that are required. If I had to rate them from one to ten, I would rate the technical support an eight out of ten.

Positive

It is very easy to set up. There have been no issues, it's hassle-free, and it doesn't require a lot of expertise or specialization to configure and set up JMeter. 

It is very straightforward and very easy. That is something that anyone can do.

Our team completed the deployment. It only requires one person and takes no more than two to four hours.

In terms of maintenance, we only require one person.

When you compare it to HP because prior to using this Apache JMeter, we used this HP Performance Center, and in terms of ROI, while I don't have exact figures, when it comes to HP Performance Center, we have nearly five times more. You can say that it's five times less of an investment and five times written on the investment by using Apache JMeter. With Apache JMeter, you receive five times more. It's higher.

It's a yearly license.

I would rate Apache JMeter an eight out of ten.

Apache JMeter is quite flexible and it is also well distributed. It is quite flexible compared to Micro Focus LoadRunner.

JMeter is easy to script. There is less of a problem with doing correlations and parameterization. 

It is not something that can be compared with Micro Focus LoadRunner. It gives the facility too easily; you do things through UI. With JMeter, you really do not have any easy UI to work as, like a Micro Focus LoadRunner.

The stability could be a bit better.

Compared to LoadRunner, it hasn't any proper UI. Recording the script is also not flexible in JMeter. In LoadRunner, we have a couple of options, such as URL-based recording and HTML-based recording. In JMeter, it's not like that. JMeter has a recorder, however, it is not easy to use. It is a bit tricky to configure the automatic recording in JMeter. 

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

JMeter, stability-wise, is good, however, it is being developed by the community. Therefore, stability is always an open question there.

The solution can scale a bit. It is scalable, however, not like LoadRunner. I have not tested it as such yet. I'm not sure about how fully scalable it is. 

I'm also familiar with Micro Focus LoadRunner.

The implementation process is not so easy. It's difficult to configure.

I'd rate the solution a seven out of ten.

I'm an end-user and a customer. 

We use Apache JMeter for the load generation scripts for performance testing.

The thread groups, samplers, and listeners, which are all determined by the script's requirements, are the most valuable features of this solution.

We use many plugins to customize our scripts, which is its main purpose. We wanted to be able to use a larger variety of customizable plugins to meet our needs. Along with our, JMeter, you would use a variety of plugins.

The number of customization plugins should be increased.

There could be improvements in terms of memory utilization. We are going to migrate away from JMeter in the near future.

The data storage should be improved.

Scalability could be improved.

It should support more protocols.

I have been working with Apache JMeter for three or four years.

We use version 5.0

We are using the cluster mode because one node is definitely not enough. Scalability can be improved.

When compared with other solutions, it's not as good, which is the reason we are moving to another solution.

Scalability must improve.

Generally, we use open forums, to resolve any issues we may have.

I also work with BlazeMeter.

I worked with Apache JMeter, from the beginning.

The initial setup is straightforward.

We have a small team to maintain this solution.

We completed the installation on our own. It was completed in-house.

Apache JMeter is an open-source solution.

We don't use the paid version of this solution.

Everything is included, and there are no additional costs.

I would suggest that instead of using a GUI-based implementation, try to make it code-based. Try to replicate the configuration. The plug should be job-ready, and ready to be integrated as well. Rather than having a UI, and limitations.

Three or four years ago, I would have given it a seven or eight, but now that there are more powerful competitors, I would give Apache JMeter a five out of ten.