sounds like your goal is to maximize the number of connections to tomcat while reducing the threads. Would that be an accurate assesment?
if that is the case, then I would recommend not using servlets at all. about the only way to do that would be to use a server which multiplexes n connections to a set number of threads. similar to SEDA architecture. neither .NET, J2EE or apache provide these kinds of features. I think there is a webserver based on SEDA design from a commercial company, but I don't remember the name and have never used it. out of curiousity, how big are the pages? if the html is less 1% of the entire page (html, images, javascript, etc), and you have the budget, Akamai might be a viable solution to your problem. unless your webpages use lots of frames and layers, I would guess a single request would only require one connection, since you're already using a dedicated image server. I hope that helps peter On Fri, 29 Oct 2004 19:24:07 +0200, Andrew Miehs <[EMAIL PROTECTED]> wrote: > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
