Apache JMeter Reviews

I am using this solution for a banking use case. We have an older version of this solution. We are planning to upgrade to a newer version.

A lot of things are valuable. It is free. It has a lot of features, such as report generation and integration with CI/CD, which makes it very competitive with the other paid solutions available in the market. It is a good solution.

They can improve it a little bit in terms of distribution load testing. We struggled with it during the distribution. 

In terms of reporting, runtime monitoring is not currently included, and it should be included. They can also improve it on the reporting side in terms of the comparison of the reports. 

They can also focus more on integration with CI/CD. Currently, people are using their own customized tools. It would be nice if Apache can provide some standard tools and procedures for integration with CI/CD tools like DPR. There are some tools, but it would be nice if official standard tools and procedures are available.

I have been using this solution for almost three months.

It is stable. There is good support, and fixes are also available immediately.

We have not scaled it, but it is scalable. We plan to increase its usage. 

I didn't have to call Apache because if anything comes up, we are able to find a solution in the community.

Its initial setup was straightforward.

We are using the free version, and if required, we can easily switch to the other version.

I would definitely recommend this solution if it suits a use case. It is good, and it also looks promising. We plan to keep using it in the future.

I would rate Apache JMeter an eight 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.

Our use cases are for applications such as E-commerce sites where there are multiple concurrent users. In some cases, there is also API load testing where a high number API calls are required for load testing. 

Apache J meter has proved to be the tool of choice for Performance testing with various features and also it comes without any cost.

A valuable feature is that when there's a high number of TPS I can achieve more transactions per second given the hyper-limitations. If the TPS is more than 5,000 TPS, the CPUs get very high (for Load runner)  and JMeter handles that well. I'd also say that the scripting flexibility like co-relation using regular expression is good, it's in the central control. Those would be the two major valuable features. 

We have some scenarios for diameter load testing where TPS requirements are very high, 30K or 40K TPS. In the telco area, this is for simulating mobile usage. However, diameter load testing can be difficult in J Meter. The only way to imitate Diameter requests and process the responses of these requests is to implement them in the code of JSR223 samplers. JMeter generally provides synchronous calls. It's something that could maybe be improved in the future, because for achieving that very high kind of TPS, more than 30K, 40K requires a asynchronous solution. It's not a common thing, it's really very specific to the telco domain and a very few projects. 

I've been using this solution for about 18 months. 

We haven't encountered any major issues with the stability.

Scalability is good. 

Support is more open-sourced. There is a lot of material available online so we haven't had to contact Apache technical support and we have our own team in the company who maintain the product.

We sometimes use LoadRunner for various purposes but currently, we use JMeter 80% of the time because LoadRunner's CPU consumption becomes very high for TPS more than 5000. Also, LoadRunner is not free so we have to pay for the license. We're using it for very few projects now. JMeter can easily achieve a high TPS but LoadRunner has a lot of high-resource requirements. 

LoadRunner's advantage is that the output report is very comprehensive. JMeter reports are only good for the people who understand the detailed logs. Out-of-box, LoadRunner has nice reports and ease of execution. In JMeter, it's also simple but requires some online training or knowledge on the loader and the setup. 

Initial setup is quite straightforward, it takes about two hours, no more, although each project is different. It depends on the scripting that goes into the environment. In terms of the product alone, the deployment doesn't take long. If you include the hardware, it can take about a week because the hardware calls for a lot of couplers and storage units and that takes time.

For the load test which requires high transactions per second to be achieved, in the range of 15K transactions per second, this is a very good tool to use and the biggest advantage is that it is free. It has a big user group, so we can find solutions easily if there are any challenges. It's really a very good open-source tool for any organization to look at in terms of performance tests.

I would rate this solution an eight out of 10. 

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 primarily use the solution to manage our capabilities. Wherever the business goes, we need to work within the expected benchmark. In terms of the user bases we deal with, most of these are products from different locations with different types of functional flow-out. There are environmental integrations also running in the background, which a user is basically accessing while going through a particular workflow. 

We'll also handle the reporting section of our data management responsibilities utilizing this system.

The reports and analysis tools are very good. They are the solution's most valuable features.

The GUI could be improved. When we go into GUI mode, there are occasions where it will not sync with our expectations. There are crashes that happen that will stop the solution from performing. It seems we get minor glitches when we go into GUI mode.  

The data client architecture that we have isn't so great. If we are to consume the data, it won't clear because there is tech running on different agents. 

When I need to pull the reports from different agents, it's not user-friendly. The reporting can be difficult to handle. It's hard to increase it if you are working on a client's architecture.

It's not easy to get the data from one place or to do customizations. 

There are other solutions that allow users to model their load and structure with them. You can't do that on JMeter. 

On other solutions, like Silk Performer, you can do network packeting, which you can't do on JMeter. They should add this to the solution as a capability in the future.

The support management needs improvement. Support is coming from consultants; you will not be able to get on-premise support from all of their agents in one place. On Silk Performer, for example,  they have the capability where you can basically have a summarized report from different agents.

Personally I've been using the solution for the last 10 years. However, in the program we are in, I've only been using this tool for six months.

If you want stability, you will have trouble, because the system is not uniform. You have to do a lot of modeling. 

If you're talking about mobile platforms, JMeter will not allow you to capture the performance of applications on your mobile platform. It's an area where the solution is lacking. It doesn't have the capability to allow developers to check the performance on an AP app.

You can scale the solution, but you will run into issues if you want to run, say, 1,000 users.  You will have to configure multiple agents and then distribute your load. It's quite difficult to manage everything on a single agent.

The initial setup is straightforward. We found it quite easy. For us, it wasn't complex at all. The solution is up and running quite quickly and doesn't take long at all to set up and deploy.

We've looked at Silk Impact and Load Balancer in the past. Each of these solutions offers a few different functionalities that aren't necessarily available on JMeter. For example, on both, there are more network features available that aren't included in JMeter and you can model your load and structure with them as well.

If companies have mobile development, they should use JMeter. If they want to integrate it with the PA pipeline, JMeter will work well. However, there are other platforms and solutions as well.

Other options include Silk Performer and Load Impact. These two solutions have other capabilities that JMeter doesn't have. You can basically model your load and structure with them. You can't do that on this solution. On Silk Performer, you can also do network packeting, which you can't do on JMeter.

Then there are some network features available in Load Impact as well as Silk Performer that aren't in JMeter. 

I'd rate the solution eight out of ten. The solution has certain limitations, but it's still a good product. 

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.