tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Miehs <and...@2sheds.de>
Subject Re: Tomcat in a High Traffic Environment
Date Fri, 29 Oct 2004 15:46:48 GMT
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 <andrew@2sheds.de>  
> 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 <andrew@2sheds.de>
>>> 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: tomcat-user-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>>
>>
>> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message