you don't need to use keepalive. generally, in a load balanced setup, keepalive is disabled because the load balancer is already making sure the user goes to the same webserver for the life time of the session.
keepalive is usually set in the HTTP header by the client, so I don't think you need to do anything to tomcat's config. someone correct me if I'm wrong. remy can provide a better description of what happens in the case a browser wants to use keep alive. peter On Fri, 29 Oct 2004 17:20:18 +0200, Andrew Miehs <[EMAIL PROTECTED]> wrote: > Hi Peter, > > The load balancer is an F5 and we are doing can do the balancing based > on JSESSIONID. At the moment we are doing persistence based on our own > cookie (Long story). > > How did you disable keep-alives? maxKeepAliveRequests="1" ? Doesn't it > make more sense to use keep-alives? And what does tomcat really do with > these keep-alive connections? Does it really keep 1 thread open for > each keep-alive? this seems VERY unnecessary.... > > Regards > > Andrew > > > > On 29.10.2004, at 17:02, Peter Lin wrote: > > > if you're using hardware load balancer like cisco localdirector, I > > would setup the load balancer to direct the traffic based on > > sessionid. > > > > this way, you don't need to use keep alive. when you say 8K > > simultaneous users, what does that translate to in terms of concurrent > > requests per second? An easy way to figure that out is to use a Http > > analysis tool like webtrends, or HttpAnalyze to generate statistics. > > > > I would look at the peak and average concurent requests. once you know > > that, it will be easier to determine if 14 servers are sufficient. > > > > peter > > > > > > On Fri, 29 Oct 2004 16:53:26 +0200, Andrew Miehs <[EMAIL PROTECTED]> > > wrote: > >> Dear List, > >> > >> I am new to the list and have a few questions about Tomcat 5.0. > >> > >> We are attempting to use tomcat in a High Traffic, many simultaneous > >> Internet user environment. > >> > >> I have about 8000 simultaneous users, and plan on using 14 web > >> servers. > >> These servers connect via CORBA to a group of backend servers. The 14 > >> web severs are load balanced with a hardware load balancer. > >> > >> How does Tomcat deal with connections? > >> > >> When a request from a user arrives, is it assigned a thread? and is > >> this thread ONLY used for this connection, (including obtaining > >> information from the backend) until the request is finished? > >> > >> How are keep-alives dealt with? When a user requests a keep-alive, is > >> a > >> thread held permanently for this user, until the connection is > >> dropped? > >> If this is the case, how is this ment to scale? > >> > >> A connection pool of 750 threads seems unusable... How can 1 thread > >> per > >> connection scale? or have I misunderstood how tomcat uses its > >> connection pool? And should all of these threads ever have something > >> to > >> do at the same time, the box would just fall over with a load of > >> 750!!!! > >> > >> Would it not make more sense to use a smaller connection pool, and set > >> up queues? > >> > >> Would it not then be better when the request has been processed, to > >> put > >> this into a second queue for requests which then go to the backend, > >> etc, etc? So many threads can't help performance. Wouldn't the kernel > >> be busy the whole time with context switching? and no user would ever > >> get any data back.... > >> > >> Thanks in advance for any comments, > >> > >> Andrew > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
