Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Date: Wed, 4 May 2005 12:51:14 -0700 (PDT)
From: Dirk-Willem van Gulik <dirkx@webweaving.org>
To: test-dev@httpd.apache.org
cc: dev@httpd.apache.org, "'Sergey Ten'" <sergey@sourcelabs.com>
Subject: Re: stress testing of Apache server
In-Reply-To: <opsp9b1db4rf0xls@ganesha.library.cornell.edu>
Message-ID: <20050504124931.V62938@skutsje.san.webweaving.org>
References: <200505032007.j43K6uXW018681@sourcelabs.sourcelabs.com>
 <4277E46B.4070209@force-elite.com>
 <opsp9b1db4rf0xls@ganesha.library.cornell.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


> 	Ok,  there's one area where I've had trouble with Apache performance,
> and that's in serving very big files.  If you've got a lot of people
> downloading 100 MB files via dialup connections,  the process count can
> get uncomfortably high.  I've tried a number of the 'single process' web

My expericen with dialup or satcom links is that such is mostly a function
of the OS and its TCP stack. Apart from upping the obvious it can help to
disallow (or intentionally) allow large buffers on OS level and/or tune
the moment the lingering starts to let apache off the hook again. The
behavioural differences between BSD, Linxu and Solaris are enourmous for
this type of workload.

Dw