Apache JMeter Reviews

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. 

Public Cloud

Microsoft Azure

The distributed load testing is very good and the ramp-up. When we come out with the right ramp-up plan, it can be converted into Apache JMeter script very well. This accurately simulates how many of our transactions need to be triggered.

I would like to see exceptions improved. The initial setup is complex and needs to be upgraded. It would be great to have additional protocols other than HTTP, HTTPS, and APIs.

I have been working with Apache JMeter for the past seven years.

The stability is good and I am not finding any issues.

We are not having any problems with the scalability of Apache JMeter

Technical support is very good.

Positive

The initial setup is complex.

Apache JMeter is a free tool.

I would rate Apache JMeter a nine out of ten.

Hybrid Cloud

Other

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.

Public Cloud

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.

We use Apache  JMeter for API testing. Our latest task combines test cases with our CI/CD pipeline for deployment to Kubernetes. Tests are developed locally and automated for the build using standard Unit and Integration testing techniques. Once deployment is successful to Kubernetes, we develop the JMeter tests for automation in promotion scenarios. Thereafter, once a deployment is successful, we can automate promotion to the next level based on test success.

Test automation moves our organization close to rapidly deploying products. Unit and Integration testing is easy to automate, and most organizations perform these as part of their day-to-day operations. However, end-to-end testing, smoke testing, load testing, and performance testing are much harder to automate. Apache JMeter has aided in that challenge.

While there is a User Interface, the scripting ability is highly beneficial and is easy to use. Tests can be added to a CI/CD Pipeline for integration with testing and deployment scenarios once finalized and operational.

This is a difficult question to answer. On one side, JMeter is very flexible and allows for a high amount of customization. On the other, some tasks are common enough that it merits simplifying the process.

Authentication for API testing could use improvement. Currently, it is a multi-step process to call, extract, and utilize a bearer token securely for API calls. This process is becoming a common enough task that a "wizard" for creating and consuming popular authentication models is merited.

I have been using this solution for about six years.

Apache JMeter is stable, and I personally have not encountered any issues. Depending on the size of test runs, one might need to adjust their JAVA settings to align with the test requirements.

Its scalability works. It is a typically Java run. Therefore, it is limited only by what you can do in Java in terms of scalability.

Developers write tests, verify tests, and maintain tests using version control. They identify and tag each to ensure they are appropriately labeled for test purposes (E.g., unit testing, integration testing, performance testing, and the like). Unit and Integration test coverage is normally high. However, we require testing from outside of the system, and JMeter allows us to create tests automating this process.

Apache JMeter utilizes community support. It is well-documented and has an active community. As far as I know, there is not a "pay-for-support" option.

I have used Postman in collaboration with other developers. However, I prefer Jmeter only out of personal familiarity and not for any technical deficiencies of Postman.

Apache JMeter setup is easy. However, there is a medium-to-heavy learning curve for developing tests and getting started using it for practical uses. Depending on its intended uses, there could be a significant configuration task for a given set of tests.

Apache JMeter is under Apache License, Version 2.0 licensing. Understanding licensing requirements is important for the implementation of any tool.

Understand the use case. Choosing the correct tool for any task is always a challenge. Jmeter offers a significant amount of flexibility and will work for a lot of solutions. Jmeter requires a commitment to learning for optimal operation; without that investment, tests may not yield the appropriate outcomes.

Public Cloud

Amazon Web Services (AWS)

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. 

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.

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.

On-premises