Apache JMeter Reviews

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.

I am using the solution for load, endurance, and performance testing.

Scripting with the solution is good.

The solution needs to improve reporting. Currently, there is not enough automation involved with the feature. For example, there should be an automatic way of saving reports. I have also found the recording should be improved too. When you are entering a launch in the controller the recording request should be inside it. Lastly, if they could make the technology better in terms of speed, this would help us.

I have been using the solution for two months.

When I compared this solution to others there were variations in the response times but it is stable.

We have used the current solution process for approximately 400 users.

The customer service is quite good. They get a lot of people requesting support but even under those conditions, they are still efficient at responding.

I have previously used NeoLoad.

The setup is easy, it is not that complex.

I would recommend Apache Jmeter. 

I rate Apache JMeter an eight out of ten.

We're primarily using the solution for its performance. It's on our data center.

The tool has been a great help to our organization, which is focused more on quality testing as opposed to performance testing. It's provided a lot of insights. With the digital transformation that is currently happening, the need for that shift was rather critical.

The performance of the solution is excellent.

They have designed the product so that it is very easy to configure. 

You can basically do anything you like with the product. It's not very restrictive.

We like the fact that the technology is open-source.

The user interface could be improved. If they had better UI, it might make it easier to use.

You really need a technical team in order to really utilize the product.

The scalability could be better, or the process of scaling itself could be a bit more clear.

We've used the solution for a couple of years at this point.

The stability is quite good. There haven't been any issues with bugs or glitches. It doesn't crash of freeze. It's very reliable.

Nobody ever has used any tool to its full capacity, including this one. Half of the time it's how you set up and how your environment is. We can easily scale on cloud. So far, we're worried about its ability to scale. Our setup is basically a hybrid cloud where we can have private data centers and we can know exactly where each is located. However, the scaling is a big concern for me. I'm looking at BlazeMeter as well, and, although I've only really read about it, it looks like it scales quite well. With scaling, I'm sure I'll find more complexities, especially if I look into kiosk testing. I'll want to explore further test cases.

Currently, those that are on the product are mostly testing communities approaching it from a performance aspect. Every project is different and therefore the number of users goes up and down.

There isn't really a need for tech support with JMeter. There is a vibrant community, which is a good way for a lot of users or developers to go on and post a question and get an answer. The team prefers it this way. It's a positive aspect of JMeter.

I have some experience LoadRunner, however, it is expensive for what it offers. This product is open-source which makes it affordable.

The initial setup is pretty straightforward. My team was very hands-on. They didn't struggle with the UI at all and it wasn't too complex for them. That said, if a person with lesser skill levels, maybe someone who has a lower skillset, may struggle a bit with the implementation. It's geared slightly towards more technical users.

The product is an open-source solution.

I understand the Apache also has something called BlazeMeter, which is something I recently looked into.

I'm not quite sure which version of the solution our team is using right now. It's likely the latest version. We did the upgrade on our tools in 2019. It's open-source, and therefore everybody picks up the latest one.

As an open-source tool, there's a good community surrounding it. If you have automation frameworks or a DevOps pipeline, you can connect that and easily configure everything to streamline processes. Due to the fact that it's open-source, you don't have to wait to get the approvals and the budgets in order. That part alone can take months to sometimes years. If your company has the time, they should review the tools. If it seems to fit your organization, I'd recommend trying it out. 

Overall, I would rate the solution seven out of ten. It's a good open-source tool that you can configure easily, and it's very competitive in the market in terms of usability

We are using Apache JMeter for profiling and stress testing the application. It is a part of our delivery architecture to stress test the application. It is a part of the build chain. It is not just something that we use internally to verify what we are going to use or going to do.

In terms of a specific use case, we are using Apache JMeter to simulate user engagement. Our software is about customer engagement, and we use JMeter to simulate the customers and engage them on our platform as aggressively as we can.

The features that I appreciate are quite basic. It is easy to ramp up the threads and start calling the application. A lot of connectors can already be found within Apache JMeter, but we are not using the entire set because the integration between the customers and platform is based on HTTP. We are just going to produce lots of HTTP sequences.

Currently, the integration pipeline is implemented by using Jenkins or a similar tool platform. These are continuous integration tools. As far as I know, integration is done by using custom scripts. It would be good if the integration with a continuous integration pipeline, like Jenkins or Hudson, can be done out of the box without using a script.

I have about two years of experience with JMeter. I started to use it two years ago with a new job.

It, for sure, is stable. Apache JMeter is a consolidated tool that has survived for several years. 

It is mainly used by automation tools. These automation tools are around whenever needed. We have about 70 people, and this is a spot adoption.

I have never tried Apache support.

The initial setup is quite easy because this is just a compressed archive. There is no real installation of the tool. You just need to extract it to integrate with Jenkins Pipelines and automatic tools by using the command-line calls. After you expand the archive, you have to adjust Apache JMeter to its proper configuration, which is not a big issue.

In terms of open-source adoption, it is completely free.

I would recommend this solution. 

I would rate Apache JMeter a ten out of ten. I don't have anything else to compare it with, and I don't know if a competitor can achieve better.

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 use Apache JMeter for lower-end performance testing. Sometimes we use it for Rest API testing, as well.

This solution allows us to have a detailed look at performance using different metrics. We can look at the deviation and the median values and see how it is performing. We can also analyze our servers and see how they are performing in terms of CPU and how much memory is allocated.

The most valuable feature in JMeter is the Thread Group, which helps us to see whether the performance is good.

The plugin for git allows us to scan files directly from the GitHub site.

The reporting is good and there are a lot of different formats available.

If you want to see the data that is associated with a response then you can download it in JSON format.

There is a large user community that can help you to learn and use JMeter.

When we are testing with too many threads then the solution hangs.

JMeter does not support JavaScript.

Automation is difficult in JMeter.

We have been using JMeter for the past two years.

Stability becomes an issue if we use more than 10 or 20 threads.

We have not been in contact with Apache technical support.

There is a large user community and if you need help then you can get instant help from them.

We also use Postman and when it comes to making a very large request, it is the better option. It is also a user-friendly solution and you do not have to go through a lot of documents to start using it.

JMeter works better for iterative testing.

It is easy to set up and administer JMeter.

This is an open-source product.

This is a good solution but many features would have to be added to use this tool alone. Postman has more features, so JMeter is really only good for performance testing.

I would rate this solution a seven out of ten.

Our primary use for it is testing websites: load testing and performance testing.

JMeter is very easy for a user who doesn't have too much programming knowledge, as scripting is not mandatory nor essential to create the testing scenarios. This means the user doesn't need to know how to write code to run a complete set of load tests. Although, If you're an advanced user, JMeter does gives the possibility of using BeanShell, Groovy or Java to script your tests.

JMeter has a very friendly and intuitive User Interface which allows users to configure the scenarios reusing components already defined, which you can also modify to fit the requirements of the tests.

One very important feature of JMeter is that it is open source and it can be easily extended through a huge set of available plugins.

Considering the kinds of tests we are performing here, where we launch several tests at the same time as a batch request, JMeter is not the best tool for the job. Those kinds of things could be done easily with other tools, like k6. It would be simpler that way. JMeter is a very old tool. It has been around for about 15 years. While it has been improved over the last few years, it is a little complicated to run several tests at the same time with different sites.

JMeter could be easier. It would be a great improvement if it was easier to integrate with the CI deployments, with tools like Jenkins or CircleCI.

Our teams have been using it for about five years.

It is a very stable tool.

In my opinion, it is not scalable. We haven't found an easy way to do that.

We would like to increase our usage but we are trying to figure out the best way to integrate it with our new circuit. Our plan is to use a tool like this with customers. That is the reason we are evaluating the pros and cons of different tools. We want to incorporate these tools into our web development process, mainly in our CI/CD process. We are trying to figure out how to use tools that are designed to empower developers.

We have used LoadUI and SmartBear with tools like Selenium. Some of the developers, at that time, were used to JMeter and they introduced it. It is a very nice tool.

The initial setup is simple. It is not a hard tool to use. It has a very nice UI and the end-users are very comfortable using the tool. People deploy it themselves.

I would definitely recommend JMeter. It is a very nice tool. It is easy to use and there are several components already developed in the tool that you can use to simplify the process of defining and redefining scripts. But I would like it to be more flexible and integrate with other tools.

In general, the primary use case of this solution is for performance testing and load testing.

Typically it is for load tests. They have to focus on three metrics including throughput, response times, and the utilization of the resources including the CPUs.

We are delivering some bank houses with performance tests, through JMeter.

The deployment model varies depending on the client. Some have a private line.

From the customers' perspective, the most valuable feature is the price.

The most valuable feature for us is the available information on the forums and to be able to discuss and get answers from the people that are involved in using this tool.

They have to find a way to prepare the script or to prepare a detailed analysis. We have to collect all the information on each of the services we have to call. Based on this they have to collect in the phase of preparation for the performance test and then we can run our audit. It is easy to prepare a script to run a performance test.

You can't rely on the support. It's something that is not fully working.

The scalability of this solution needs some improvement.

There is some work to be done with the integration.

This solution is stable, but it does have one limitation with the number of throughputs. For example, if I want to generate four, five, or two thousand people working concurrently then they have to prepare our setup for ten PC servers.

Normally they can run a load for five thousand people, customers, or users working concurrently. It is scalable but needs some improvement.

The technical support on the site is not fully functioning.

The initial setup is easy and straightforward.

You can have it running within thirty minutes.

I had always implemented this solution myself, but It's been a couple of years since I did it last.

Now it is done through our company technicians.  I just coordinate activity-performance tests for our customers.

This is an open-source solution, and there are no fees.

The requirements for most of our customers is to provide them with cheap solutions, and most prefer not to pay for software. This is the right solution for them based on some of the open-source tools that are available.

There are some commercial solutions that provide better integration to the solutions that must be tested when running loads.

I would rate this solution an eight out ten.