JMeter is highly scalable.

My server is capable of processing 60,000 API requests in one minute. I'm putting 1.2 million API requests per minute on my server because I have configured some scaling rules in the Azure environment. After reaching the optimized level of 60,000 requests, it automatically scales out by one load in the Azure cloud. JMeter generates that load with the specific time we have provided in our script and configuration.

In terms of scalability, we haven't pushed it to a large scale yet.

The majority of users are performance engineers, but there are also some developers.

There are four performance engineers and at least three developers who use JMeter on occasion.

We intend to increase usage, but it is already being used exclusively and extensively.

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. 

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.

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.

Scalability is possible for both small and large companies. In smaller companies, JMeter can be scaled across multiple machines, utilizing them as load generators. For more complex network setups, collaboration with the DevOps or system administration teams may be required to handle firewall configurations. In large enterprises, options like Docker Swarm or Kubernetes can be employed. Additionally, using JMeter images or containers within these frameworks allows for quick scalability.

It is an evolving product. It is a scalable tool. I would rate it an eight out of ten. We have medium-sized clients.

We are an enterprise business using the solution. It flips a bit whenever we add more than 10,000 virtual users to the solution. It becomes impossible to get the expected result. We have to use distributed testing to deal with the issue. I rate the solution's scalability as a six.

It is scalable. You can scale up to 1,000 users in JMeter. If you can put up four slave servers, you can easily ramp up to 1,000 users. That's not a problem.

Because it's open-source, a lot of organizations try to leverage JMeter into everything. I don't think JMeter is currently very adaptable to all the technologies. That is something Apache should think of – incorporating other technologies and other tech stacks, which can be scripted from JMeter and tested using JMeter.

There are around seven users in my company using this solution. 

Apache JMeter is a scalable tool.

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.  

Scalability is near-linear, especially with custom configurations.

We have more than 100 people using Apache JMeter in my organization.

We have multiple clients using this solution and all of our testers are using the solution.

My advice to others is for them to go through online tutorials before using the solution. It is easy to use, and anyone can quickly learn and test their application.

I rate the scalability of Apache JMeter an eight out of ten.

This solution is scalable, but only up to a certain point when adding virtual users, before performance issues begin to occur.

JMeter is scalable. I did a test using it in a distributed environment with more than one client. We used JMeter to load from the server and also the plugin tool. It works fairly well in a complex environment. I still need to research the maximum concurrent JMeter can handle. Is it 1 billion or 10 million? 

In my work experience, I need to load maybe 1 million users. For example, most of my work is on the backend of e-commerce websites with a maximum of 1,000 users. We have many clients, but the load is not that big. 

I would rate JMeter's scalability as seven out of ten.

We have around 12 Apache JMeter users in our organization. I rate the product's scalability an eight out of ten.

It can scale. However, what others say about scalability is that you need to have some proper calculations to be done first.

JMeter is an on-premise solution, so it has limited scalability. We are looking for a cloud-based solution that is scalable and elastic. 

It was very easy to scale, but I was barely scratching the surface. I have spent 17 years at Microsoft, and for the performance testing that we did there, we had 8.3 million users at once, as opposed to a maximum of a thousand. If I'm scaling, I have to do it quite straightforward and simple, but it was very minimal.

Only I was using it. It was the QA department. I showed it to some of the devs, and they were very interested. A couple of them tried it, but none were actually using it day-to-day for testing out the environment.

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.

We are not having any problems with the scalability of Apache JMeter

The solution has been scalable. 

We have almost 100 users on the solution. 

We likely won't increase usage in the future.

We are using the cluster mode because one node is definitely not enough. Scalability can be improved.

When compared with other solutions, it's not as good, which is the reason we are moving to another solution.

Scalability must improve.

Its scalability works. It is a typically Java run. Therefore, it is limited only by what you can do in Java in terms of scalability.

Developers write tests, verify tests, and maintain tests using version control. They identify and tag each to ensure they are appropriately labeled for test purposes (E.g., unit testing, integration testing, performance testing, and the like). Unit and Integration test coverage is normally high. However, we require testing from outside of the system, and JMeter allows us to create tests automating this process.

The solution is scalable. I'd rate it ten out of ten.

The solution can scale. However, it requires configuration to do so. I don't have much knowledge in regards to how to scale exactly.

On the other hand, if you have a cloud server with 10 servers and you are using the same DNS for all servers, as all servers are working with the same application, and you have for example a load balancer that provides balancing to each one of these ten servers, I am not sure if Apache JMeter will report the different servers separately. I imagine not.

Different implementations of JMeter Runtime could be used to point to each one of these 10 servers. You can use JMeter in different OS, for example, Windows, Linux, or Unix. You have a lot of features to use different instances with JMeter. However, this load balancer concept would be harder to explain.

Right now, we have around two or three guys working directly with the product.

We are evaluating automatization apps currently. We are using Jenkins, and I am sure we will start with JMeter later. However, I have not defined a roadmap to expanding usage of this product just yet.

Apache JMeter is a scalable product. We are pleased with the scalability of this solution.

Around 10 people are using the solution in my team.

I rate Apache JMeter a nine out of ten for scalability.

The solution is scalable, but I cannot comment on the extent of its scalability because we have yet to scale widely.

This solution is easily scalable, you can distribute the larger generation among several machines in the LAN, or you can use the cloud variation of the product.

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 give the scalability a five out of ten.

The solution is used to perform baseline tests for applications and compare them to SLAs to determine user load and scalability. 

Apache JMeter is scalable in the sense that there's a master/slave architecture available for it where I can scale as many slaves along the way, but when a huge number of users is required in a particular load test, and you have to scale a lot beyond a particular threshold, the resource consumption becomes too high and requires considerable overhead. Apache JMeter consumes a lot of memory, and that's a hurdle, but it's scalable up to a certain point. If a very, very large organization requires very heavy load testing to be done, it would be better for that organization to go with some other tool.

Since Apache JMeter is a scalable product, I rate the solution a ten out of ten. I am the only person using the solution in my organization.

Scalability is fine, although it is important to remember that JMeter doesn't run on its own. It needs to work with load-generations such as BlazeMeter. LoadRunner is the same in that you need a cloud-based infrastructure to run it.

There are around 50,000 users in my company using the solution. Also, most of the users are involved in performance testing. Scalability-wise, I rate the solution a seven out of ten.

With Apache JMeter, banking processes may face some scalability issues.

We can create demand as we need. It's quite scalable. 

We have five people suing the product. The performance testers use it.

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.

The product is scalable. My company has around four to five users for the solution. 

Apache JMeter is scalable.

We have less than five people using this solution in my organization.

Scalability is possible. You need to have the load generator for the scaling of your application. It's very simple to procure the load generator. You will have to install the JMeter agent file, where it'll be connecting to the monitor. It will not be as simple as a paid tool. For example, with BlazeMeter, they provide scaling with the cloud. BlazeMeter supports the JMeter items. If you have thousands of users, you will need the cloud and you'll need something like BlazeMeter. 

Currently, as this is a banking application, we don't have that many users. However, I've tried it with the 5000 users with the five to six load generators in the cloud. If we want to really scale, however, it's best to go with BlazeMeter.

We believe this to be a scalable solution, although we have not made any amendments in user numbers to date.

It probably scales up to a few thousand users but not beyond that.

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

Scalability is good, though you need to be aware of distributed and non guis test execution modes. 

It is scalable. It allows us to extend and add additional functionality and features.

We have around 10 to 15 people who use this solution.

I would rate JMeter's scalability as six out of ten.

JMeter is not designed for high loads, if you overdo it the tool becomes a bottleneck. Unless you're using JMeter in multiple systems and all the systems are connected through a particular LAN, there is a limit.

It is a scalable solution.

Scalability is good. 

I have found Apache JMeter to be scalable.

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.

The solution is very scalable.

The solution is scalable, but it all depends on the application. However, it is usually scalable by up to 2500 users. However, if you want to use it for any number of users, you can use JMeter as long as your machine supports it.

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.

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

The solution is scalable.

We've had no issues with scalability.

It is scalable.

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

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.

Yes, While running with a large number of simulated users, sometimes we got thread exceptions and we restarted our testing simulation.

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.

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