Apache JMeter Reviews

I use the solution for performance testing (Load testing, Volume testing and Endurance testing).

The solution has a friendly user interface and is a very good open-source solution for load testing. It supports both web and mobile network recording via proxy and offers a wide range of protocols. It has strong community support across multiple platforms.

The solution is open-source. 

It is very easy to code and develop the script and it supports web and mobile scripting.

There is a lot of good documentation available. 

The solution is stable. 

The memory utilization in JMeter is poor. Limited in terms of scalability. The system gets hung up for complex scripts and heavy loads which requires improvement.

It needs improvement in analytics and statistics reporting. The reports offer limited information on a load test. I would highly appreciate it if JMeter can provide better reporting capabilities.

I have been using this solution for two years.

It's a stable and reliable product. There are no major bugs or glitches and doesn't crash. 

The solution is scalable. However, it has a lot of memory issues during scale-up. That is the one concern. It's a bit limited in terms of scalability.

I have never contacted Apache customer service for any issues. However, the documentation is readily available online and very useful.

The initial setup is pretty straightforward and easy to implement. It's not overly complex. 

I'd rate it a five out of five in terms of ease of implementation. 

I can do the implementation by myself.

It is an open-source tool.

I'd rate the solution eight out of ten.

We primarily use the solution for API testing.

The ease of use is the solution's most valuable feature. Also, the ability to easily create test cases is also very good. It's easy to just ramp up on the solution.

The solution is new to us. I'm not sure if we're using the full capabilities of the solution yet, but from what we have used, we're quite satisfied.

In future releases, it would be helpful if there was an integration with ALM Octane.

The solution is stable.

The solution is very scalable.

We're not using too many features of the solution itself, so we haven't needed the assistance of technical support yet.

We previously used LoadRunner. We decided to switch because on LoadRunner scaling up was a problem.  We needed licenses to do so and it was becoming a problem for us to simulate the number of users we were expecting. 

The general setup of the solution is straightforward.

Before we chose JMeter, we looked at NeoLoad, but it looked to have the same issues surrounding licensing that LoadRunner did.

We are using the on-premises deployment model.

The advice I would give to others would be to look at your requirements and decide if the solution is right for you. For us, it was API testing and JMeter is very good for this.

I'd rate this solution nine out of ten.

We use it to measure the performance of the system and for balancing.

We like that Apache JMeter has different features and different plugins and that they are free of charge.

We also like that lots of people use it. So, if we happen to get stuck at some point, then we can search for solutions on Google and find them.

Report generation needs to be improved. It is quite difficult to get to.

We've been using Apache JMeter for two years.

It is quite stable.

It is a scalable solution.

On a scale from one to ten, I would rate Apache JMeter at nine. I would recommend it for medium-sized businesses.

We are writing scripts using various tools in multiple environments. We have tests set up where you have to pass the credentials in to get a session ID, and it sets and checks the cookies. Then, we check the response values and pass them on to the next function.

We have this solution integrated with Jenkins and we also use it for database performance testing.

The most valuable features are the integration with Jenkins and the reporting.

JMeter allows us to automate performance testing and raise diagnostic functions.

This solution should support the Ruby programming language for scripting.

JMeter should support dynamic throughput so that we can reduce or increase it during the execution of the scripts. 

For performance testing, we would like to be able to select different bandwidths such as 3G or 4G.

The interface could be made more user-friendly.

I have been working with Apache JMeter for the past three months.

We have not had any problems with stability.

So far, I haven't had any issues with scalability when performance testing.

We have not yet been in contact with technical support.

I have also started working with BlazeMeter. One of the differences is that the automation is not possible in BlazeMeter. However, BlazeMeters allows for the selection of different bandwidths, it takes less time to write tests, and it is more user-friendly.

The initial setup is straightforward. We have not yet completed our full deployment with all of the tests.

Our internal team was responsible for the implementation.

We are currently comparing the differences between Apache JMeter and BlazeMeter.

JMeter is a good solution but it requires writing manual scripts and takes longer than BlazeMeter. It takes longer to cover the same number of use cases and is not as user-friendly.

I would rate this solution a four out of ten.

We are using it for load testing. We test other companies' programs.

We are using it just for load testing. We are using its free version, and it is scalable.

I am not satisfied with this solution. Its UI side is not so easy to use for beginners. It should be easier. 

Modeling a test is difficult. If you don't have much knowledge, you won't be able to do it easily. Testing APIs is also difficult.

For JSON, you can use tools such as JSONBuddy, but they are difficult to get in JMeter. It should be easy to get JSONBuddy from the website. I have to use BlazeMeter only to get JSONBuddy.

It has been about five months.

It is not so stable.

It is scalable.

Their support is fine. There are not many Apache documents, but you can find other documents on the web.

It is not so difficult.

We are using the free version.

I would rate it a seven out of 10.

I was experimenting with Apache JMeter. I was doing a proof of concept for myself to see if it fit my needs. I wanted to compare it with LoadRunner to see how it compares in terms of recording, ease of use, and functionality.

I like the fact that JMeter integrates well with other tools. For instance, we are also looking at OctoPerf and, I know for OctoPerf, you can import JMeter scripts, whereas, for LoadRunner, you cannot import LoadRunner scripts into OctoPerf.

I like the graphing; it is good.

Once I got past the learning curve, it was okay.

There were a lot of features that translated well from LoadRunner. I have LoadRunner experience, so once I applied my base knowledge to JMeter, then it was okay. The terminology was a little different, but the functionality is similar. For instance, They are called "extractors," in JMeter and called "correlation" in LoadRunner. 

Once I learned the terminology and how to navigate through JMeter, then it was easier.

I still think LoadRunner is a better tool, but for some purposes, JMeter would suit the need.

The installation needs some work. It could be simplified.

When compared with LoadRunner, LoadRunner is a more mature product.

I used it for a couple of weeks.

It's pretty stable, I don't have any complaints.

We didn't do a large load test. I didn't explore the scalability.

I was the only person using this solution, but I ran 100 user load tests.

I did not need to use technical support.

Previously, we were testing LoadRunner.

I reviewed some YouTube videos and went through them. It wasn't necessarily intuitive.

There was some configuration, and file that had to be set up.

It wasn't like LoadRunner where they have an automatic installer and wizard that does everything for you.

It wasn't as easy, but anyone who is technical can work through it.

When comparing the price with LoadRunner, and if the cost is an issue then JMeter is a better choice. LoadRunner is very expensive.

I like LoadRunner better, although I might be biased because I do have LoadRunner experience. I am a little more familiar with it. I was leaning towards LoadRunner.

I would advise others to look at YouTube videos for the setup. Other than that, it was pretty straightforward. I was pretty much satisfied with it. It's a good tool, and it sounds like it's been around for a while.

I would rate Apache JMeter a seven out of ten.

We primarily use the solution for performance download testing.

It's a solution that's easy to use. It's a bit different from SoapUI and LoadUI.

The user interface is a little bit tricky.

The solution is very stable.

It's not 100% scalable like LoadUI, but LoadUI is very expensive. We're an outsourcing company, so we have approximately ten users. We may have plans to expand in the future.

The solution doesn't have technical support. If we need answers, we look for them on the internet.

Previously, we used the basic version of LoadUI. We switched because LoadUI is very expensive and Apache JMeter is free.

The initial setup was complex. We did have it done in a day. It took approximately one hour. We have about five to six people that manage the solution.

The solution is free. You don't need to worry about licensing costs.

We didn't evaluate other options before choosing this solution.

We are using the private cloud version of the solution.

I would rate this solution eight out of ten. If it had a bit of a better user interface, I would rate it higher.

I like the ease of using JMeter. It can be downloaded and can be used to record and run load tests. JMeter can record, run and create reports easily without the need to have licenses, complex installations and paid support. It can be used to performance test services, web applications, database queries, LDAP, etc.

We use JMeter for performance testing. We are able to know which module is lagging behind in performance, whether the software or hardware upgrades have improved the performance or not.

I think JMeter hangs up on large loads. I have seen JMeter becoming unresponsive in the middle of a test. It is because of garbage collection in JMeter. We use best practices to mute all listeners, use non GUI mode, etc., but even with many best practices JMeter pauses in between load tests.

It is a open source tool.

My advice would be to have load generator machines. Do not run JMeter (or any load testing tool) from a desktop. Do not have just one JMeter installation to generate load. Use several JMeter instances to distribute load. If possible, use JMeter in Client Server mode.