What is your primary use case for Apache JMeter?

We use Apache JMeter for performance testing, and the Locust tool for Python framework for performance testing. We primarily do performance load testing.

I work with Apache JMeter for multiple projects that are currently running in Standard Chartered Bank. We have integrated Apache JMeter with Jenkins and for other purposes, such as executing testing performance center. We have added several plugins and we are using Apache JMeter for our load test executions. My usual use cases for Apache JMeter primarily include testing APIs and banking services, such as debit and credit card transaction details and getting other services.

I use Apache JMeter for performance testing of web applications. Specifically, I have automated the complete API cycles for performance testing and backend functionality testing. I also generate reports to evaluate the performance of an application, such as download times. Furthermore, I use it for sending end-to-end messages in banking systems and for UI automation.

We are using JMeter for load testing and UI performance testing in both GUI and non-GUI modes. We mainly use it for performance testing and rendering purposes across various projects.

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.

This is primarily the to go open source tool for performance/ load testing. There are newer solutions in the market. However Jmeter is a well matured tool for the purpose compared to the new kids on the block. It can also be used for functional testing. There are plugins to get junit like performance test reports too. It supports various AUTs/ protocols through its community backed vast range of plugins. Best part is either we can build our own new plugins or customize existing plugins for our specific need without waiting for vender support. Jmeter is one of the best examples for a OS tool. One major drawback is the lack of strong auto correlation capabilities available for free. Blazemeter as a commercial SAS platform also provides a commendable contribution for improving the tool further.  Jmeter can be also used in the CI/CD context for performance trend monitoring in conjunction with tools like Grafana. It's main purpose can be define as simulation of work loads (centralized or distributed manner) and capture the clientside/ backend performance metrics in a time series manner and also collate the results that can be further analysed to identify any performance issues or risks. 

We use the tool for data load testing.

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.

We primarily use it for conducting different types of performance testing, such as load testing, spike testing, and endurance testing.

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.

We utilize it solely for load testing and performance testing.

There's a third-party platform that is getting migrated to, so with the newer version migration, we were looking to see if there are any performance degradation with the migration. The product platform assures the user loads that we are planning to have on the system. Nevertheless, we wanted to have validation from a business perspective. We wanted to see that it'll still support the loads that we are looking at.

We use Apache JMeter for performance testing, including the response time of our websites for multiple users.

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.

My clients are using it for BI reporting dashboards and executing dashboards. It's basically a reporting tool.

The solution is primarily used for load testing.

We use the solution for performance distributing testing.

I've been using JMeter mainly for performance testing and some repair testing as well.

Our primary use case for the solution is performance testing for applications, and we deploy it on the cloud and on-premises.

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.

We use this solution for functional API testing, and performance testing.

JMeter is used by a team of four performance engineers. We monitor tasks on the API level, so all of the requests are hitting individually.

We primarily use the solution for performance and delivery testing.

We use Apache JMeter to test the performance of our platforms and applications.

We use JMeter for performance testing. Our testing team has 50 to 60 people.

We have a couple of applications in banking.

We use this solution mostly for creating scripts, load testing, and performance testing. If my client doesn't have a tool or I don't have a tool, I try to leverage JMeter because it's an open-source tool. I personally use JMeter for things which cannot be covered by our load testing tool, which is OATS, Oracle Application Testing Suite. This is a tool that was developed by Oracle but is no longer in use because Oracle has stopped developing it. The solution is deployed on-prem and on private and public clouds.

I mainly use JMeter to capture the traffic of the most-visited page to see how much load a particular page is getting and how many users are using that page for a particular amount of time. I've also used it to capture APIs for particular pages.

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

I implement this solution for my clients.

We primarily use the solution for testing. We have three types of testing. One is the APA testing, and the web, and one is mobile. All have been recorded through this protocol.

My main use case of JMeter is for web application performance testing as well as for API performance testing. We are customers of Apache.

I've used JMeter in conjunction with Selenium, Java, and Log4j for logging. I used it before I ended that contract in August. Its version was up to date at that time. It was used for an e-commerce site that is specialized in C-PAP or weaving machines in effect. Their max was a thousand people logged in at once. I, of course, pushed the boundaries on that, but it was to test the performance of the website, and of course, I'm had to try subsystems, database interactions, etc.

We use Apache JMeter ( /products/apache-jmeter-reviews ) for API testing. Our latest task combines test cases with our CI/CD pipeline for deployment to Kubernetes ( /products/kubernetes-reviews ). Tests are developed locally and automated for the build using standard Unit and Integration testing techniques. Once deployment is successful to Kubernetes ( /products/kubernetes-reviews ), we develop the JMeter ( /products/apache-jmeter-reviews ) tests for automation in promotion scenarios. Thereafter, once a deployment is successful, we can automate promotion to the next level based on test success.

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 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.

It is specifically used for performance systems. It is used for identifying the areas where we need to improve the application bottlenecks and for load testing. We are using its latest version.

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

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

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.

When I was last using JMeter, we were simulating 200 concurrent users and evaluating performance based on transaction times. We were defining SLAs based on the results. Essentially, we created load scenarios and testing different ones using different workload models.

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.

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.

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.

We use Apache JMeter for lower-end performance testing. Sometimes we use it for Rest API testing, as well.

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

We primarily use the solution for API testing.

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.

This is a cost-effective tool, which provides people the ability to do POCs without worrying about costs.

I set a script reporting and execute test report and analysis on almost all stages of the performance cycle except in regards to requirements and the environment.

We primarily use the solution for performance download testing.