I am using Tomcat 5.0.18 to load test an application using JMeter.
When the no of connections exceeds 250, there is a connection timeout
exception, with that particular not reaching the server. This occurs only
for a few requests and not all.
I have set maxThreads=200, connectionTimeout= 60s in server.xml
Exception on JMeter :
jmeter.protocol.http.sampler.HTTPSampler: Connection timed out: connect
java.net.ConnectException: Connection timed out: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
at java.net.Socket.connect(Socket.java:452)
at java.net.Socket.connect(Socket.java:402)
at sun.net.NetworkClient.doConnect(NetworkClient.java:139)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:402)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:618)
at sun.net.www.http.HttpClient.<init>(HttpClient.java:306)
at sun.net.www.http.HttpClient.<init>(HttpClient.java:267)
at sun.net.www.http.HttpClient.New(HttpClient.java:339)
at sun.net.www.http.HttpClient.New(HttpClient.java:320)
at sun.net.www.http.HttpClient.New(HttpClient.java:315)
at
sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.j
ava:521)
at
sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:4
98)
at
org.apache.jmeter.protocol.http.sampler.HTTPSampler.connect(HTTPSampler.java
:889)
at
org.apache.jmeter.protocol.http.sampler.HTTPSampler.sample(HTTPSampler.java:
957)
at
org.apache.jmeter.protocol.http.sampler.HTTPSampler.sample(HTTPSampler.java:
445)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:277)
at java.lang.Thread.run(Thread.java:534)

let me know if there are any configuration settings on Tomcat that
will help me over come this problem.

make sure, the OS is not limiting connections due to license issue (e.g. per user license in Windows Server).

make sure, the OS is not limiting connections due to license issue (e.g. per user license in Windows Server).

I would look at operating system parameters related to the TCP/IP stack. For example, tcp_max_connections, tcp_timeout, etc.


Jose Ramon Huerga
http://www.terra.es/personal/jrhuerga

I rather doubt it has anything to do with the OS, because if it would, it would appear very differently:

1) If the number of max connections is restrained on the OS level, the client of the connection should be getting connection refused or connection reset/disconnect messages. That's not the case.

2) If the number of connections is limited on the OS level, that should not lead to the complete crash of the Tomcat server (which is what happens, indeed) after the number of connections reach some number around 200.

Restriction on the CP/IP stack may result in request not reaching Tomcat, but how can it crash Tomcat? It does crash.

With what stack trace does Tomcat crash? The stack trace is see is JMeter not being able to connect.

Did you find a solution to this problem ? i happen to have a similar problem...

From HP site http://www.hp.com/products1/unix/webservers/apache/techtips/tomcat.html Tomcat is a multi-threaded servlet container this means that each request needs to be executed by some thread. Prior to Tomcat 3.2, the default was to create a new thread to serve each request that arrives. This behavior is problematic for loaded sites because: • Starting and stopping a thread for every request puts a needless burden on the operating system and the JVM. • It is hard to limit the resource consumption. If 300 requests arrive concurrently Tomcat will open 300 threads to serve them and allocate all the resources needed to serve all the 300 requests at the same time. This causes Tomcat to allocate much more resources (CPU, Memory, Descriptors...) than it should and it can lead to low performance and even crashes if resources are exhausted. The solution for these problems is to use a thread pool, which is the default for Tomcat 3.2. Servlet containers that are using a thread pool relieve themselves from directly managing their threads. Instead of allocating new threads; whenever they need a thread they ask for it from the pool, and when they are done, the thread is returned to the pool. The thread pool can now be used to implement sophisticated thread management techniques, such as: 1. Keeping threads "open" and reusing them over and over again. This saves the trouble associated with creating and destroying threads continuously. o Usually the administrator can instruct the pool not to keep too many idle threads, freeing them if needed. 2. Setting an upper bound on the number of threads used concurrently. This prevents the resources allocation problem associated with unlimited thread allocation. o If the container maxed out to the threads upper limit, and a new request arrives, the new request will have to wait for some other (previous) request to finish and free the thread used to service it.

I'm running my server on a Linux box

We had the exact same issue. After simultanous connections reach some number around 200, Tomcat crashes and application becomes unavailable.

What we did was - limited number of simultanous connections on Apache, which we have in front of Tomcat. This way, on pick loads URLs may be unavailable but at least - the application does not crash and when pick load goes away - everything comes back to normal.