Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <438DCCF3.2050709@cornell.edu>
Date: Wed, 30 Nov 2005 11:01:55 -0500
From: Paul A Houle <ph18@cornell.edu>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: OT: performance FUD
References: <438CB0FB.1010103@web.turner.com> <438CBCAB.3000601@cornell.edu>
 <31F7A2911619B094CD102466@st-augustin.ics.uci.edu>
 <438CC408.4070007@cornell.edu> <438CCA73.7080903@ptc.com>
In-Reply-To: <438CCA73.7080903@ptc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jess Holle wrote:

>
> So if one uses worker and few processes (i.e. lots of threads per), 
> then Solaris should be fine?
>
    That's what people think,  but I'd like to see some numbers.

    I've never put a worker Apache into production because most of our 
systems depend on PHP or something else which I wouldn't trust 100% in a 
threaded configuration.

    Now that I think about it,  there is a common situation where people 
with modest web sites (at the 50,000 ranking in Alexa) have performance 
problems with Apache...  That's the case of people doing downloads of 
big (>>1 M files.)  Conventional benchmarking,  which fetishizes a large 
and constant number of connections on a LAN doesn't model the situation 
well (it doesn't model any real-world situation well.)

    The trouble you have a population of people with really bad 
connections that take forever to download things...  Back when I had 
dialup,  I used to download ISO images,  I'd just use a download manager 
and have my computer running overnight to do it.  For one project I work 
on,  we have people uploading files that sometimes are in the ~1 M 
range,  then we do processing on the files that is sometimees 
extensive.  We were worried that some processes were running for 20, 30, 
40 minutes,  but we discovered that many of our users have horrible 
connections.

    The result is that a site with a modest number of "hits" per day can 
have > 1000 simultaneous connections.  With prefork you end up burning a 
lot more RAM than really seems fair -- although it's not so bad if you 
can afford to load your machine with 8G.