> -----Original Message----- > From: Leon Rosenberg [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 09, 2006 3:06 PM > To: Tomcat Users List > Subject: Re: Performance tricks with multiple > tomcat instances > > On 3/9/06, Justin Greene <[EMAIL PROTECTED]> wrote: > > > > > -----Original Message----- > > > From: Leon Rosenberg [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, March 09, 2006 10:28 AM > > > To: Tomcat Users List > > > Subject: Re: Performance tricks with multiple > > > tomcat instances > > > > > > On 3/9/06, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > > > > If I were to add my two cents, I would say the OS > > > scheduler, the bus, <SNIP>
> > I have to say that I am always surpised to read when people are > > setting application servers (such as Tomcat) to maxthreads > of 1000. > > If I had 1000 processes running at the same time on any of my > > application servers it would melt never finish any of them. It is > > more realistic to have 5 - 10 threads processing at any > given time and > > to allow requests to queue (though one must test to find the sweet > > spot). > > I would say, you are right, but if you want to support http > 1.1 keepalives 1.5 threads per user are blocked simply > waiting for incoming requests, so how are you supposed to > server 500 users with 75 threads? 500 users != 500 concurrent connections (threads). You can likely handle many users being logged in at the same time with very few threads if you take they do not all click a URL at the same time, and even if they did, you would not want to service them all at the same time as your system could not handle it. We set our keepalives pretty short, only a few seconds. If another request does not come in quickly, then it costs a little overhead to create a new connection. Oh well. Try taking an application that has some load and watching the # of active threads in the 'Manager'. We typically have 20 or 30 clients logged in at a time but only see a single active thread at any given time as it only takes milliseconds to service most requests (if we are writing our code well). Justin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
