Apache JMeter Reviews

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. 

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 Apache JMeter to test the performance of our platforms and applications.

The most valuable feature of this solution is that it is free. If not for that, we would be using a different tool.

The graphical user interface could be improved.

In this tool, automation in general is almost non-existent. Everything is done manually. I would advise those who put this together to try to simplify it for their end users, such as being able to automate at their desks. Such as manual relations and social management.

Purely on the feature set, it lacks automation, therefore it requires a lot of manual work.

As a performance engineer, I use it almost every day.

I have been using Apache JMeter for two years.

Apache JMeter seems to be stable enough.

In terms of scalability, we haven't pushed it to a large scale yet.

The majority of users are performance engineers, but there are also some developers.

There are four performance engineers and at least three developers who use JMeter on occasion.

We intend to increase usage, but it is already being used exclusively and extensively.

There is no technical support program for Apache JMeter. There is only an online community of people who help one another.

The community is helpful and fairly advanced.

In the past, I used to use various tools, primarily LoadRunner.

When I changed jobs, and the new company only used JMeter because we didn't have a license for LoadRunner, I started working with Apache JMeter.

The initial setup was very easy.

We used it on a desktop computer. It is also used in the cloud. The idea behind using it in the cloud was to spread loads across multiple machines.

We carry out the deployment ourselves.

We have one performance engineering consultant who maintains this solution.

That would not be applicable because it is a free solution.

Licensing costs are rare.

There are operational costs related to using Amazon Cloud, but the tool itself.

I looked into other options, such as Bluehost, SmartBear, Epic, and LoadRunner but Jmeter proved to be sufficient for our needs.

We chose JMeter based on its pricing structure.

My advice is that it requires a fairly consistent amount of initial learning. It is not simple to learn.

I would rate Apache JMeter a three out of ten.

We use this solution mostly for creating scripts, load testing, and performance testing. If my client doesn't have a tool or I don't have a tool, I try to leverage JMeter because it's an open-source tool.

I personally use JMeter for things which cannot be covered by our load testing tool, which is OATS, Oracle Application Testing Suite. This is a tool that was developed by Oracle but is no longer in use because Oracle has stopped developing it.

The solution is deployed on-prem and on private and public clouds.

JMeter should be more stable. Every time there is a new release coming up, a lot of its older functionalities or the new functionalities that are brought in are not very well-documented. It should be documented properly, and there should be proper use cases. A lot of the newer features don't work, and sometimes you have to spend a lot of time maintaining the scripts. That is something JMeter could probably look at.

For example, in JMeter 5 they brought in a lot of new controllers. But there isn't a lot of documentation available on the Apache site on how you're supposed to use those controllers. They've explained the controller functionality, but there aren't any proper use cases to show that. 

I have been using JMeter for a long time and do a lot of work with this solution.

It's not stable. With every new release, they come up with newer features, which aren't always very stable. So, stability is a concern.

It is scalable. You can scale up to 1,000 users in JMeter. If you can put up four slave servers, you can easily ramp up to 1,000 users. That's not a problem.

Because it's open-source, a lot of organizations try to leverage JMeter into everything. I don't think JMeter is currently very adaptable to all the technologies. That is something Apache should think of – incorporating other technologies and other tech stacks, which can be scripted from JMeter and tested using JMeter.

On a scale of 1 to 5, I would rate technical support 2.5

They're not very good because JMeter is an open-source tool. You can raise a bug to JMeter, and they might fix it or they might say that, "We will actually fix this in the next release." So, because it's an open-source tool, you do not get dedicated support. You have to raise tickets and wait. If you use BlazeMeter, the support is probably a little better because you can take your issues there.

I don't think support is great if you compare it with tools like NeoLoad or LoadRunner where they have a dedicated support team. You can raise tickets. You have a direct conversation with their engineers. They can help you understand where the issue is exactly. That kind of support is not in JMeter, at least not now. BlazeMeter has it, but I have not used BlazeMeter support, so I'm not sure how it is. But from what I have seen with JMeter, support is not great.

It is straightforward, but for JMeter 5, since they have introduced SSL handshake at the slave level, that becomes a little bit of a challenge for somebody who is doing it for the first time if you're doing a distributed execution, that becomes a challenge.

But since there was not enough documentation, I had to do a lot of troubleshooting on my own, since it was new. Now there's a lot of documentation available, but initially, there was not much documentation.

JMeter is pretty easy to use if you are using it for the purpose of only developing scripts. You can just uninstall the file and you can start using it. The only challenge happens if you're trying to access the internet over any kind of proxy. Then, you'll have to start it via the proxy mode.

Otherwise, deploying JMeter is pretty easy compared to other tools. You just have to download, unzip, and you are ready to go.

We installed JMeter ourselves.

I would rate this solution 7 out of 10.

Apache JMeter's key feature is its ability to manage load profiles, gradually increasing requests over time. This was crucial for us as we tested our application, handling unique protocols and increasing load steadily. JMeter helped identify bottlenecks by measuring response times as we increased request flow rates. This data guided us in optimizing our system's performance and scaling hardware when needed. Recently, new tools like Platinum Consultant have emerged, but I haven't explored them thoroughly. My colleagues prefer these newer tools over JMeter.

JMeter helps us track response times between request and response. As we increase our workload, response times also rise, indicating potential bottlenecks. We use JMeter to gauge when we need to upgrade hardware or optimize our application for better performance. It's effective in measuring various request types and their corresponding response times, making it a valuable tool for assessing system performance.

I appreciate JMeter's simplicity and power for performance testing. While I haven't used all its features, the ability to simulate heavy loads from multiple users is quite beneficial. However, in my current configuration, we haven't utilized this specific aspect of JMeter. Compared to other costly tools like Hewlett Packard, JMeter is free and easier to use, although there are newer tools like Gatling that I haven't tried. Overall, JMeter is simple and effective for performance testing.     

Improving JMeter's sync time could be beneficial. For example, compared to a Hewlett Packard tool that required four machines for load generation, JMeter reduced this to possibly just two machines for the same workload.

I've been a junior with a few years of experience using Apache JMeter for load testing. It's a straightforward tool with useful features, although not entirely unique. 

Scalability is near-linear, especially with custom configurations.

Setting up JMeter is straightforward, not complex at all. Deployment time depends on the code you write for JMeter, which is executed efficiently.I've used it on-premises, but it might also work in a cloud configuration

Since it's free, there's no need for extensive support or improvements in pricing.

Overall, I'd give JMeter a solid ten for its simplicity and effectiveness in typical tasks. While the UI could be slightly better, it's not a critical issue. JMeter provides valuable data and insights through its graphs, and its main benefit lies in being free, simple to use, and widely recognized.

We are using this for performance testing and some automation. We consolidate the test data in our own systems and then use an API to send this data to JMeter. The software testing team then uses it to perform all the tests they wish to do. Nowadays, we are mainly focused on regression testing and working with that.

It works really well. 

To be honest, the UI could be more user-friendly. As a UX guy, I believe it's quite cold. The solution that I have nowadays is a very traditional one. So, there is room for improvement in the UI of Apache JMeter. 

I have been using Apache JMeter for two years. We have it in-house. It's a solution that my company has been using for a long time.

There are around seven users in my company using this solution. 

In terms of setup, it's quite simple. It has its benefits, but we are already used to it. In terms of experience, it could be nicer, to be honest. Sometimes, I get a little bit lost.

Two people are required for the deployment and maintenance. They can be he managers, tech leads, engineers, or developers.

The users need to pay for licenses.

We are not switching because we have several testing teams, and we sell them to several customers. So the solution sometimes is not ours; it's the customer's, and they provide some licenses because usually, companies like Vodafone have corporate licensing. They can provide licensing without being responsible for it. 

We also have our own solutions, but we are not sometimes responsive before saying I don't want to use this or I don't want to use that. Because we are an outsourcing company, we put people accordingly to the field desired by our customers. So if I need a Selenium expert or an Optimum or TestRail, whatever, I go to the market, and I outsource this to the customer.

Overall, I would rate the solution a seven out of ten. I recommend it because I know a lot of people who use it, and they don't have any complaints.

My clients are using it for BI reporting dashboards and executing dashboards. It's basically a reporting tool.

There are many features I like in Apache JMeter. First, it's open source, so I like that about the product. And there's a lot of community support for it.

There are some challenges in terms of recognizing the objects in some critical cases. These are object identifiers because Apache JMeter cannot recognize those dynamic objects.

I have been working with Apache JMeter for 12 years. It has been a long time. 

It is a stable solution. I would rate it a nine out of ten. 

It is an evolving product. It is a scalable tool. I would rate it an eight out of ten. We have medium-sized clients.

Most of the time, we get the solution from the open-source community. However, I have never interacted with Apache's customer support. 

The initial setup is very easy. We always use the latest version. It doesn't take much time to deploy the solution. 

It's a matter of hours to run a full test. However, it may take some time if you need to configure a project and create the skill to run it. Debugging can also be time-consuming. To set up an end-to-end process, it may take several days.

One or two people would be enough for the deployment. Someone from the infrastructure team can provide support in case of port issues, connectivity, or technical challenges. 

I have a different technology stack, such as BI tools like Tableau, Microsoft Strategy, and custom data applications. In some cases, I feel that Apache JMeter is not suitable. So, I am looking out for a different tool.

One tool cannot fit into all kinds of applications and business use cases. But by and large, it can cater to many applications. Overall, I would rate the solution a nine 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.