On Jan 24, 2005, at 11:09 PM, Steffen Heil wrote:

Hi

the number of threads will depend on the size of your
machine, but to support many concurrent users, you will want
to turn off keep alive connections, as these will have the
opposite effect.

Wouldn't it make more sense to enable keep alive connections and increase
the thread count - if memory suffices?



Unfortunately not. IMHO threads are over used and over rated. Have a look at the reasons THTTPD and Zeus webserver were created.

I was told that the 'Java Servlet Spec' (I think this was the one) requires
one thread per connection. I can understand the reasoning behind this,
as it makes the implementation much easier.


In my experience however, this does NOT work well in a high traffic situation.
It makes NO sense for a machine to need to deal with 1000+ threads. (Unless
of course you have an E15000 in the basement with 1000 processors). I had
major problems with Debian Woody as the supplied Glib C as I was unable
to get java to start more than 250 threads. Sarge was better in that it supported
the new linux threading library out of the box. I do not have any experience with
Solaris or Windows when dealing with that many threads.


You need to disable keep-alives, becuase if you don't you end up wasting a lot
of threads that just sit waiting for the next request on that connection - meaning
even more threads just hanging around.


The scary thing is, imagine something hangs on the backend for 30 seconds, and
then all your 1000 threads start trying to do something at once.... You will end up
with a load of 1000 and ALL your requests will take a long time to return.


It may be interesting to replace the http connector for tomcat with one that uses
"select" and uses 'threads' as a type of worker pool. This way, you can deal with
all the connections in the select loop (incl. keep-alive) and still have the advantage
of not needing to remember state due to the worker threads to the back end...


My 2c

Andrew




--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to