The loadbalancer forwards the packet to tomcat, and as such, tomcat sees the keep-alive request.
If tomcat has keep-alive enabled, it will set up keep alive on its end.


Andrew


On 29.10.2004, at 17:31, Peter Lin wrote:

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]



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



Reply via email to