How to set the maximum concurrent requests that can be handled by a servlet using Tomcat
I wanted to know how many concurrent requests a web application using a servlet can handle (using Tomcat 7). I have configured the maxThreads, acceptCount, minSpareThreads attributes of the server.xml file.
My question is: Should the underlying OS also need to be considered?
For example:
maxThreads= 5;
acceptCount= 1;
OS= 1 processor with 4 cores;
So a maximum of 4 requests can be processed at the same time with 1 wait request? Assuming each request will take some time. Should hyper-threading be considered as well?
source to share
Good question, but no direct answer. You must define the server parameters yourself and test it under load.
A few questions that pop into my head.
1.) How time
long each request takes to process.
2.) How many threads are used / configured in thread pool
.
3.) How many server connections
have been configured.
OS, the server won't play a much larger role in this. Once you're done adjusting the options by clicking them there, you might even think about hardware.
In the server.xml file, you specify maxThreads , which specifies the maximum number of concurrent requests that can be processed. If not specified, this attribute is 200.
From statistics / blogs
A single Tomcat server with default settings on modest hardware should handle 2k requests per second easily, assuming it has too much on-demand work. If it takes more than 500ms to process a single request, you will probably need to increase the number of threads in the pool thread and you can start pushing the limits.
source to share
There is no easy way to come up with these numbers just by guessing. Generally, you do not need to specify anything that could clog the car. But at the same time, the network interface is so slow that it is difficult to intercept the web server (unless each request takes a long time to process) before you create the network.
My suggestion is to leave these values alone and monitor the server to see how it behaves on boot. If you can, do some load tests - there are great tools out there that can simulate thousands of users using your server at the same time.
Also from experience: the database is the bottleneck. There will be several requests that will stop everything. It is difficult to say which ones in advance because performance depends on many things: the amount of data in the database, the indexes, the actual SQL being executed, the disk speed, the network between the DB and the web server, to name just the most important ones.
source to share