AW: Meaning of threads
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? Even if not, the keep-alive timeout should be decreased instead of disabled all together. Additionally I'd like to see tomcat to be able to drop keep-alive connection exactly then, when all threads are busy and a new connection is to be etablished. That would give us the benefit of keep alive connections - faster data delivery for users - as well as optimal thread usage even on small thread pools. What is your opinion? Regards, Steffen smime.p7s Description: S/MIME cryptographic signature
Re: AW: Meaning of threads
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]
Re: AW: Meaning of threads
In my experience however, this does NOT work well in a high traffic situation. I'm sure you're not saying that Tomcat does NOT work well in a high traffic situation. You are just saying that in a high traffic situation one should turn off keep alives. Am I guessing correctly that I have only a few persistent visitors (such as an office web application that is a front end to a database) then turning keep alives on will cause the data to be returned to the user more promptly. But if, say, you are running an eBay type site, keep alives should be turned off. Any single user will suffer a little but the traffic will be handled better. Aaron Fude __ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: AW: Meaning of threads
Geachte relatie, Het door u gebruikte e-mailadres is niet meer actief. U kunt uw e-mailbericht sturen naar [EMAIL PROTECTED] of dit bericht beantwoorden. Bedankt voor uw medewerking, Met vriendelijke groet, ATP Hypotheken Het Spoor 40 3994 AK Houten Tel. 030 750 25 33 Fax. 030 750 25 88 [EMAIL PROTECTED] -- DIT IS EEN AUTOMATISCH GEGENEREERD E-MAILBERICHT -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
