Apache JMeter Reviews

I mainly used Apache JMeter for manufacturing environments at an enterprise level. One specific use case was where we had to send bulk files via API, which we could not replicate with LoadRunner as it might require additional protocol purchases. With Apache JMeter, we could simulate this scenario, uploading millions of files via API.

There is no significant financial investment as Apache JMeter is a free tool, which helps in scenarios where cost constraints are present.

One valuable feature of Apache JMeter is the ability to replicate scenarios where bulk files have to be uploaded via API. This is something we couldn't simulate with LoadRunner without purchasing another protocol.

The user interface is not as user-friendly as LoadRunner. The scripting, which is a record-and-replay setup, seems less intuitive, potentially since I have more experience with LoadRunner. 

Documentation is not comprehensive, making it difficult to find the right answers.

I have used Apache JMeter for around two to three years.

I have not seen Apache JMeter getting crashed in between uses, and it is generally stable without major issues.

Apache JMeter has limitations as it only supports one protocol: the web protocol.

Apache JMeter does not have direct support due to it being open-source, however, there are online communities where I search for answers.

Neutral

I have not used any other open-source tool for performance testing. I have used LoadRunner, but given the choice between LoadRunner and Apache JMeter as a tester, I would choose LoadRunner. However, from a purchasing perspective, I would not go with LoadRunner due to its cost.

The setup of Apache JMeter is straightforward and not complex.

We have a production support team, which is a large team. They handle various tasks besides deployments, supporting all enterprise-level tools.

As Apache JMeter is a free tool, there is no direct investment, making it cost-effective for web protocol jobs.

There were no costs involved as Apache JMeter is a free tool.

I have not used any open-source performance testing tool other than Apache JMeter.

I would recommend Apache JMeter to others if there are cost constraints.

I'd rate the solution six out of ten.

We use the tool for data load testing. 

Most of our products and the entire industry operate on APIs now. The end user interacts with the user interface, but the entire backend runs on APIs. Even when one application needs to interact with another, we use APIs. It's an API-driven world, and Apache JMeter supports API testing.

We had some challenges testing HTTP/2 APIs, which are becoming more prevalent with advancements like 5G. So, we added another plugin to help with HTTP/2 API load testing. Apache JMeter, with additional plugins, now supports HTTP/2, which is critical as everyone moves from HTTP/1 to HTTP/2.

We used many features, and we like all of them. It's hard to say which one is better than the other. The ability to simulate heavy loads from multiple users is definitely a standout. We can increase the number of threads, ramp up, ramp down, and run stable load tests. We've validated all these use cases.

The tool's reports are user-friendly and self-explanatory. It has good visualization aspects as well. 

Performance and stability are key industry requirements. Often, functionality testing is prioritized, but performance and stability are crucial once the product is in production.

To the best of my knowledge, the documentation could be improved. It should be enhanced to better support newcomers. Currently, only people with some experience can easily understand the content. Including more sample programs, applications, and use cases would help many more people adapt to using the solution.

I have been using the product for a few years.  

I rate the product's stability a nine out of ten. 

The scalability can be viewed from one instance and multiple instances. We haven't explored the multiple instances part, so I can't speak to that. However, with a single instance, we've been able to get good performance, explore all the features, and cater to our use cases.

I haven't contacted the tech support yet. We search the internet or call experts for help. 

The tool's deployment is straightforward. You need to follow the user documentation to deploy it. 

The solution can be deployed with the help of in-house engineers. 

The tool is open-source. 

I rate the overall product an eight out of ten. I recommend it wherever I go. 

There is room for improvement in the scripting concepts. The scripting and even the results and reports were very elaborative and informative in LoadRunner, but not in JMeter because everything has to be done manually. 

And, whichever metric we need, we need to add it manually and start monitoring it, but not in LoadRunner. It was a very elaborate report. A lot more information, but not in JMeter.

I have been using it for four to five months. I have been with the organization for just four to five months.

It is scalable. It is cloud-based. Whenever, based on the requirements, we can scale it to whatever extent we need. But with respect to LoadRunner and NeoLoad, since they are all paid ones, we had to follow a procedure even if we had to scale for certain protocols or with respect to users. We had to pay the cost.

There are around seven to eight members using this tool.

I have switched over to a new company where they used JMeter. Earlier, we used Micro Focus LoadRunner.

More than NeoLoad, I prefer LoadRunner the most because I have had experience from the past 13 to 14 years, majorly on LoadRunner. 

Any of the customers would be very easily convinced with the LoadRunner or the NeoLoad reports more than the JMeter reports. And even interpretation of the results, everything would be very much comfortable and customer-friendly with respect to LoadRunner and the other tools, but not with JMeter.

If I had to compare with respect to JMeter and other tools, the script creation, user-friendliness, handling of the tools, customization of scripts - everything is very much easy. Even for training, it would be very easy with LoadRunner more than JMeter.

And documentation, materials, support, technical support, installation, everything - whatever the support- also looks pretty good in LoadRunner or NeoLoad, not in JMeter. Since it's open source, everything has to be done on your own. And the training of freshers and juniors would be more comfortable with LoadRunner than JMeter.

It is free.

I propose they use Micro Focus LoadRunner or NeoLoad. I have even put forward the proposal here [in my current company] as well.

Overall, I would rate it a six out of ten. 

I use Apache JMeter primarily for performance testing projects. It is a day-in, day-out tool where we run performance test executions to create a production-like load on systems. We analyze the results and share recommendations with customers. We use it for load testing, stress testing, and endurance testing on systems.

Apache JMeter helps us meet our requirements for performance testing by allowing us to create scripts and run them. It is part of our daily routine, and it provides us the capability to test using different protocols like gRPC, which is essential for our operations.

The most valuable features of Apache JMeter include SCTP sampler, throughput controllers, stepping up thread group, parallel controller, timers, and the ability to use gRPC protocol. These features meet our requirements and allow us to effectively create and run our performance testing scripts.

Apache JMeter has room for improvement in handling larger infrastructures as it consumes a lot of CPU and memory. It requires integration with other tools for live metrics, which is time-consuming. 

Also, the failure response times are calculated in the overall response time analysis, which should be separate. Better script maintenance and integration with ALM or repository tools would be beneficial.

I have been using Apache JMeter for about 14 years.

Apache JMeter is generally stable, with a high stability rating of nine out of ten. Any instability could impact timelines, project deadlines, releases, and revenues.

While Apache JMeter can scale to the required number of user loads, it requires a lot of manual work and larger infrastructure, which are challenges to its scalability.

There is no dedicated support team for Apache JMeter as it is an open-source tool. We rely on community support, which is not enough and needs to be improved.

Positive

I previously used LoadRunner. We switched due to customer preference for a commercial tool.

The initial setup of Apache JMeter is rated between eight and nine out of ten. If you have knowledge, it's an easy setup.

No specific team is required to maintain Apache JMeter. Performance test engineers familiar with the tool can maintain it.

Apache JMeter is an open-source tool, so there are no costs associated with its setup, pricing, or licensing.

We evaluated NeoLoad and found LoadRunner to be more realistic than NeoLoad and Apache JMeter.

For those looking into open source, JMeter is an excellent tool and should be the first option. For commercial needs, BlazeMeter is a good choice, or LoadRunner is a good choice for a commercial setup.

I'd rate the solution ten out of ten.

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.

We use the solution for performance and security testing.

The solution's most valuable feature is its ability to install and automate functions with ease.

They should improve the solution on its UI front.

 We have been using the solution for six years.

I rate the solution's stability as a seven or eight.

We are an enterprise business using the solution. It flips a bit whenever we add more than 10,000 virtual users to the solution. It becomes impossible to get the expected result. We have to use distributed testing to deal with the issue. I rate the solution's scalability as a six.

We check with the solution's community support forum in case of any queries. It is very active.

We tried out solutions such as LoadRunner and NeoLoad. As these were commercial tools, we settled for JMeter. Also, the reviews from those who have used the solution helped us switch to it.

I rate the solution's initial setup as an eight. It is easy.

Regarding deployment, you have to download the installation file and save it in the system. If it has specific prerequisites, such as installing Java, you need to ensure it is compatible with JMeter's current version.

The solution is free of cost as it is open source.

The solution works well for small or medium applications but not with 10,000 or more footfall. I rate the solution as a seven.

Any front-end technologies like Angular, React, or others might access the services. Therefore, you must ensure that using SAP with JMeter works fine. Unless you ensure this, the front-end team may not access the services properly.

You can save the state of your tests and test plans after conducting tests, allowing you to showcase the results to others later. This feature makes it easier to demonstrate what testing was done and share those test cases.

From an improvement perspective, consider a scenario where your application needs to retrieve data from PayPal and store it in an Excel file in an external network. Connecting to such a source using JMeter might take some time. Previously, you might have linked your application to a server to obtain these results. However, achieving this kind of integration directly in JMeter can be challenging. If it were possible to configure JMeter to handle such server connections seamlessly, its capabilities would greatly be enhanced.

I have been using Apache JMeter since 2004-05.

It is a stable tool and has been stable for a long time. Organizations have been using it extensively since 2017. However, it's important to note that while JMeter is excellent for testing the performance of your service, you cannot directly forward the results to the end user.

You can increase the testing scale. When deploying a microservice in a production environment, performance testing is essential. You should test to handle at least one million users, a minimum benchmark. 

From a developer’s perspective, if your service can handle one or two million users with a response time of less than one second, it is considered acceptable, provided the data is accurate. In production environments with multiple servers, response times might vary, but it is crucial to perform thorough testing in a local environment to ensure the system meets performance criteria. JMeter helps verify that the service can handle the expected load and deliver accurate results.

I am using Azure and GCP.

JMeter is easy to set up, taking about half an hour to install. However, the real effort lies in configuring and developing the tests, which can be time-consuming. 

If there is an update, it doesn't typically take long to come. They may release an upgrade within one or two years. If you have a test suite, it can be easily imported, and you can start using it. This process hardly takes more than half an hour.

Apache JMeter is configuring it properly, especially when dealing with SSL configurations. It can be tricky and time-consuming if you're unfamiliar with handling SSL certificates, keys, and JMX configuration. However, the process becomes straightforward if you know where and how to pass the necessary keys and configurations. Without this knowledge, you'll likely need to spend time researching and Googling how to set everything up. In contrast, if you're familiar with these configurations, setting them up in JMeter is quick and straightforward.

Overall, I rate the solution a nine out of ten.

I consider Apache JMeter to be a fundamental tool in the industry for performance testing. Its primary advantage lies in being free, making it accessible to everyone. The platform boasts a wide range of plugins, regularly updated, and has a substantial community. You can find information on almost any topic in the community forums or Q&A sites related to code.

Apache JMeter is well-known and widely used among developers, particularly on popular developer forums. While it may not have the most user-friendly interface, it offers strong support through official manuals and various articles from companies providing load testing services. 

The tool is free, has a substantial community, and serves as a fundamental choice for testers, especially those new to performance testing. While other tools like K6 may be more developer-oriented, JMeter's affordability and accessibility make it suitable for those without extensive performance testing experience.

Given that Apache JMeter is a free and open-source tool, documentation improvement may not be a major concern, as it is mostly contributed on a voluntary basis. The essential information is already available. However, in terms of the interface, there are occasional bugs, and the tool may not address them as quickly as some users would like. Fixing defects and bugs might take a considerable amount of time, with users sometimes having to wait for several months or even a year for the next release to address specific issues.

I have worked with Apache JMeter for years. 

In terms of stability, there have been some instances of unknown bugs, but these are documented on the official pages and tracked in bug repositories where users can find descriptions and potential workarounds. Users with less experience may encounter unexpected behavior, but with online resources, such as Google, they can understand and address the issues. Some known problems, like internal loop issues when launching from the MacOS terminal, can affect stability, but they are not critical and usually have workarounds. While these issues may slightly impact the user experience, they do not significantly detract from it. On a scale of ten, the overall user experience with JMeter might be rated around seven or eight.

Scalability is possible for both small and large companies. In smaller companies, JMeter can be scaled across multiple machines, utilizing them as load generators. For more complex network setups, collaboration with the DevOps or system administration teams may be required to handle firewall configurations. In large enterprises, options like Docker Swarm or Kubernetes can be employed. Additionally, using JMeter images or containers within these frameworks allows for quick scalability.

While I haven't personally engaged in direct interaction with support, I have encountered challenges and utilized forums and official support channels to address and resolve those issues. So, yes, I've had experiences leveraging these resources for problem-solving.

A few years ago, I found Apache JMeter to be a reliable tool, and while it may have changed since then, I haven't used it recently for a direct comparison. Around five years ago, I had a positive experience with Neotys, which was an excellent tool, albeit expensive. However, as its pricing is now contact-based, I'm not sure about the current costs. Additionally, I've recently explored K6, which seems promising. K6 is actively developed and evolving rapidly. It caters more to a coding-centric experience, making it favorable for developers who appreciate JavaScript-based coding without extensive installations. This tool might see significant growth in functionality in the coming years.

If someone is completely new to Apache JMeter, it might take around one hour to half an hour to set it up initially. This includes spending time reading manuals, watching YouTube videos, and getting familiar with the tool. For those with some experience, the setup process could take as little as ten minutes. This involves downloading and installing JMeter, configuring Java if necessary, and adjusting path variables. The overall time may vary based on the machine's readiness and the user's familiarity with the setup process.

One piece of advice I often provide to those venturing into performance testing with Apache JMeter is to carefully consider the expected load. Due to its utilization of the Java Virtual Machine, JMeter can be memory-intensive. For extensive testing scenarios with a high volume of virtual users and transactions, it's crucial to meticulously configure JMeter, considering each element in the scenario. However, for simpler yet intensive testing needs, individuals might find less resource-intensive tools like Gatling or Locust more suitable.

If it were a commercial tool, I'd rate it an eight, but given that it's a free and non-commercial tool, I'd lean more towards a nine. While it's not perfect, I believe it's one of the best options available for now.