Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <27e674a9041029100845d180df@mail.gmail.com>
References: <49FAD908-29BA-11D9-A610-000393758B2E@2sheds.de>
 <27e674a9041029080212c95f21@mail.gmail.com>
 <0AAE0CF0-29BE-11D9-A610-000393758B2E@2sheds.de>
 <27e674a9041029083128b99c40@mail.gmail.com> <41826549.7040708@apache.org>
 <27e674a9041029085313bd3c91@mail.gmail.com>
 <CBC51549-29C3-11D9-A610-000393758B2E@2sheds.de>
 <27e674a9041029100845d180df@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <56D8B0E8-29CF-11D9-A610-000393758B2E@2sheds.de>
Content-Transfer-Encoding: 7bit
From: Andrew Miehs <andrew@2sheds.de>
Subject: Re: Tomcat in a High Traffic Environment
Date: Fri, 29 Oct 2004 19:24:07 +0200
To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>


On 29.10.2004, at 19:08, Peter Lin wrote:

> if you're looking for better client performance I would explore other
> areas first.
>
> 1. use gzip compression - this can reduce the html to 1/10th the size.
> your mileage will vary.
>

This is being looked at - loadbalancer vrs tomcat


> 2. caching results on the web-tier

Very dynamic content

>
> 3. putting the images on a dedicated image server
>

Already being done. 2x Servers running apache - which also have this 
keep-alive problem. Running 1000 threads per server is NOT my idea of a 
good time. I will be having a look at a couple of other alternatives to 
apache over the next couple of weeks. Due to operating system/ kenerl  
overheads
time for one request <> (time for 10 parallel requests)/10 <> (time for 
1000 parallel requests)/1000

Squid is a good example of how you can server MANY connections without 
starting thousands of threads.

> 4. distributing your servers across multiple ISP. many service
> providers don't tell you this, but often their pipe is saturated and
> can't really handle a large number of concurrent requests. if you host
> your own servers i would recommend getting more than 1 connection and
> use different providers

This is NOT a pipe saturation issue. The issue is definitely a tomcat/ 
number of connections issue.
I already have this problem in my local network with load tests.

>
> Most browsers today are Http1.1 compliant, which means they are
> limited to 2 connections to the same server. Normally the browser will
> use the same connection to get the html and the other resources like
> images and javascript.
>

This will only happen if keep-alives are enabled. If keep-alives are 
disabled each GET will be a new connection. The F5 load balancers (4.5) 
have a 'cool-feature?!' that 'forwards' the keep-alive connection 
through to the backend server - With the 4.5 version of the software 
they are doing packet mangling. This means that even though the cllient 
only has 2 connections, the load balancer multiplies this connection to 
EACH of the backend servers with which the client is communicating, ie: 
static servers get 2 connections per client, statistic servers get 2 
connections per client, tomcats get 2 connections per client..

Version 9 of the software has just come out, and it does proxying this 
should hopefully help solve this problem - I am still in the process of 
testing the new version.

Andrew


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