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.
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.
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.
We primarily use it for conducting different types of performance testing, such as load testing, spike testing, and endurance testing.
JMeter is basically the art of the entire performance testing process. We generate load on our application using JMeter and then monitor various metrics like CPU with different monitoring tools. It's the essential foundation for our performance testing.
JMeter is doing some good things with upcoming releases, but the main area for improvement is the extensions available.
Another area of improvement is the reporting part, specifically regarding report generation.
There are certain things like we can't merge custom metrics into the JMeter reports. We're limited to JMeter metrics, and other server metrics can't be integrated with JMeter dashboard. This forces us to rely on another tool.
We should be able to add or custom-configure server details directly in JMeter reports.
We have been using it for three years.
I would rate the stability a nine out of ten. It's generally quite stable, it hardly has crashes or issues.
Scalability is good for my use cases, but to generate a large load, you must go into distribution mode, which is more complex to configure and requires powerful machines. So, while it's fine for my needs, but the scalability wouldn't be a perfect ten. I would rate it a seven out of ten, as there are some limitations for large-scale testing.
I'm the one who uses it most extensively. And the other we have four to five people are using it just for their local testing. It's development testing kind of stuff.
It's an open-source community. So we can post our queries there. We generally get good responses from the forums. So it's good enough.
I used another tool like HP LoadRunner. And now it's offered by some different companies, ownership-wise, but it was long back.
I would rate my experience with the initial setup an eight out of ten, where one is difficult, and ten is easy. Even for new users, the installation is straightforward based on the documentation.
However, customizing and building something extra can be complex. But overall, it's easy enough to download and start working with.
Our main system is on the cloud, so we primarily use JMeter on the cloud. However, some use cases require on-premises deployment, and we use it there as well.
One person is enough for deployment. The deployment won't take much time. It is very fast, typically within five minutes.
We use the open-source version.
I'll definitely advise that you should at least give it a try. If it serves your initial needs and meets your expectations, you should go for it.
It's quite an old and up-to-mark tool with a proven track record in the industry, and there's a strong community behind it. So it's definitely worth giving a shot.
Overall, I would rate the solution an eight out of ten.
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.
We utilize it solely for load testing and performance testing.
JMeter is user-friendly, and that's a notable advantage of JVTech. It's straightforward and easy to use, unlike some other load testing tools, making it very easy to understand.
I have been using Apache JMeter for the past 4 to 5 years.
The last time I used it, there were some APIs that I tested, and they were running well before. We didn't make any changes to them, but when I tried to check them again recently, they didn't go through. It seemed like an issue at the integration level. I'm currently working on getting half an automation, where I'll have separate linear and rest. But that's the situation so far.
I prefer tools that I can easily teach people within twenty minutes, and JMeter falls into that category. It's part of the tools I use to help others learn load testing. While JMeter can be a bit tricky, I find it easy to grasp and teach. It's user-friendly, and I can quickly introduce someone to it. It's a tool that I can easily exchange with others, and I aim to achieve proficiency in it soon because of its simplicity and ease of use.
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 have a Neotys slave server configuration where we have one server that caters to three servers, and we test most of the load on Apache JMeter, particularly for a hundred users. We test the load for web applications, services, and the rest of the APIs, though our current setup for Apache JMeter isn't that big.
Initially, Apache JMeter had a complex configuration; its UI was tricky and required a lot of resources. Creating scripts and running tests on Apache JMeter was always confusing, but nowadays, with more documentation and UI enhancements, Apache JMeter has improved. Previously, recording and creating scripts was tricky, and you had to do it manually. Now there's a recording facility in Apache JMeter that lets you create and modify scripts and test faster, which helped improve my organization.
To me, what's most valuable in Apache JMeter is that it's a lightweight tool for application testing. It's the best load-testing tool for my company because Apache JMeter simulates your application during testing. Apache JMeter also creates threads with good server utilization. Apache JMeter allows you to focus on analyzing the situation, looking into measurements, response time, and client-server responses, which I find valuable.
Both scalability and stability could be improved in Apache JMeter.
What I'd like to see in Apache JMeter in the future is ease of use in terms of scripting. A recording capability similar to what LoadRunner offers, where you can record scripts, make some modifications, then the script will be ready, is another advanced feature I'd like Apache JMeter to have. The two features would make it easier for new users to learn how to use Apache JMeter and help users utilize the tool more quickly.
I've been using Apache JMeter for more than six or seven years.
Apache JMeter isn't as stable because it sometimes crashes when you're running a test. The performance of Apache JMeter could be improved because testing on it isn't always as smooth sailing.
The tool is partially stable. You can't expect Apache JMeter to run well for enterprise-level, high-load applications. It's a good tool for more straightforward or lightweight web applications but not for CRM-type applications.
Scalability-wise, Apache JMeter could be improved because if you try to implement it on multi-servers, the threads running on the tool don't hold up well.
We used LoadRunner before using Apache JMeter. As Apache JMeter is open source, and we only needed to test lightweight applications, we were pretty sure we wanted to go with Apache JMeter.
Apache JMeter is an open-source tool that you can install directly from the web with binary files, so setting it up on one to two machines is easy. The setup could be tricky if you hook Apache JMeter to three or more different machines, and it's also tricky when you execute it after.
We implemented Apache JMeter in-house.
I've seen ROI from Apache JMeter, mainly because it doesn't cost much to maintain, and we can use it on a few lightweight applications.
We didn't pay licensing fees for Apache JMeter because it's an open-source tool. We only paid for the machines where we installed Apache JMeter modules.
I have experience with Apache JMeter, with version 5.5. as the most recent version I've used.
Apache JMeter is deployed on-premises, but my company did a POC with Apache JMeter and BlazeMeter. BlazeMeter is a CA proprietor tool where you can hook up Apache JMeter scripts. BlazeMeter is a cloud-based tool where you can run tests with the help of Apache JMeter scripts.
At the moment, only two people use Apache JMeter within my company. Two people can handle the deployment of Apache JMeter, while only one person is required to maintain it.
My advice to people looking into implementing Apache JMeter is to make the decision based on the application portfolio. For example, if it's more diverse, then using Apache JMeter could be tricky, but if you're only testing lightweight applications, Apache JMeter will be a viable solution.
Apache JMeter requires minimal investment, yet it has some returns, and it's a good tool, so I'm rating it as seven out of ten.
I worked on the performance setting of my product, which is a product with an easy UI element that can be added in. People without forward knowledge will be able to easily understand the tool and use it right away.
Other cloud-based performance tools will allow you to view what's going on during the test. However, with this product, it's not possible to monitor live during a test, such as with BlazeMeter, which is very user-friendly.
It is very user-friendly. We just upload the script, and the dashboards are very informative. It's useful for both the person conducting the test and the higher management, like project managers or senior executives, who may not know about the test. They can easily view the results and gain valuable insights. Additionally, monetary benefits with Apache JMeter are notable since it doesn’t require a licensed version.
While using Apache JMeter, we are unable to view the graph while the test is running because it consumes resources, which is a drawback. With BlazeMeter, you can view the results in real-time.
I worked with it for five to six years.
The initial setup is very easy, just a couple of minutes.
Monetary benefits with Apache JMeter are notable as it doesn't require a licensed version, whereas BlazeMeter involves costs.
I would recommend starting with the basic tool to understand performance settings. I would recommend Apache JMeter first.
I'd rate the solution nine out of ten.