Re: threads, performance, and exceptions

[Andrew Miehs]

You may want to try turning off keepalives in your tomcat. (I assume  
you are only using tomcat, and not proxying through mod_jk and  
apache/ IIS).


In your connector settings have a look at 'maxKeepAliveRequests=1'

If you really have that many threads, you will probably be best of  
using Linux, with a 2.6 Kernel due to the way Linux deals with threads.



Regards


Andrew


On 02/10/2006, at 5:16 AM, Peter Warren wrote:



My question is: how can I best improve the performance?  Is the server
really refusing client connections or is the load test bogging down  
and

reporting spurious messages (the load test uses many threads as well)?
Is the high # of threads on the server a problem?  Would running on
Linux or another OS help?  Is there a way for me to minimize the # of
servlet threads required?




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: threads, performance, and exceptions

[Leon Rosenberg]

Hmm,
I would suggest you stop having continuos connections. 30 seconds is a
lot of time, maybe you should re-establish connections on request. I
know re-establishing costs 3 additional tcp packets, but it negligible
since you have small packets sent seldomly.
I assume your chat is an applet, since you wouldn't need 2 threads
otherwise. Since your applet is running in browser you could try to
use the browsers connection (via loading document in a hidden frame
from the applet, executing javascript in the loaded document that
calls a method in the applet). This way you'll need no own threads at
all. If you don't like the solution (which I would fully understand)
you could still switch to polling with 1 thread on the server side:
On timer in applet you use your 1 thread connection and send the request
the server  reads the request and sends the response after the request
the client reads the response and idles :-)
Its pretty similar to the http protocol in this case. If you use above
advice with reestablishing connections you can get rid of threads and
switch to thread-pools which will give you a performance boost of
factor 10 or more.

regards
Leon


On 10/2/06, Peter Warren [EMAIL PROTECTED] wrote:

I have an application that links users so they can chat.  My client
operates within a browser.  To be firewall friendly and avoid client
server sockets listening for incoming requests, I implemented the client
so that it makes http requests and sits and waits (maybe for minutes on
end) until it gets a response.  And each client has 2 threads that are
constantly waiting for an http response from 2 different urls (which
ties up 2 servlet threads).  I knew full well that this would be thread
heavy on the tomcat server side but thought I'd try it out.  The server
is tomcat 5.5.20 running on Windows XP Pro with 1GB of RAM.  After some
preliminary load testing, I find I'm able to handle about 500 simulated
users (each sending a message every 30 seconds) concurrently
communicating before getting connection refused messages.  I would like
to improve that.

So with each client having 2 threads constantly waiting on servlet
requests, that's 2 servlet threads per client or 1000 threads on the
server, which seems like a lot to me.  With 500 clients communicating
every 30 seconds, fairly evenly distributed, that's about 16 requests
per second.  It seems like I should be able to do better than that.

Initially when running my load test, I ran into OutOfMemoryErrors:
unable to create new native thread.  Lowering the thread stack size in
Tomcat's configuration dialog seemed to help.  Now the limiting issue is
that my clients receive connection timed out and read timed out
messages.

On the client I see the following stacks:
java.net.ConnectException: Connection timed out: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at sun.net.NetworkClient.doConnect(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.init(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at
sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown
Source)
at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
at com.seekspeak.applet.URLTalker.initConnection(URLTalker.java:44)
at com.seekspeak.applet.URLTalker.send(URLTalker.java:50)
at
com.seekspeak.test.load.RecipientTest$RefreshThread.run(RecipientTest.java:206)

java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read1(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown So
urce)
at java.net.HttpURLConnection.getResponseCode(Unknown Source)
at com.seekspeak.applet.URLTalker.send(URLTalker.java:54)
at
com.seekspeak.test.load.Communicator$ListenThread.run(Communicator.ja
va:217)

In the catalina log, the only problem I see is this stack:

Oct 1, 2006 7:59:01 PM org.apache.catalina.core.StandardWrapperValve invoke
WARNING: Servlet.service() for servlet invoker threw exception
java.net.SocketException: Connection reset