httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From di...@covalent.net
Subject Re: [PATCH] convert worker MPM to leader/followers design
Date Fri, 12 Apr 2002 11:33:56 GMT

Whoa ! That sort of a situation in in my experience extremely common; e.g.
a URL flashed in a TV or Advert - or during a soap/talk show to 'vote' or
something. Bazillions of people on crappy modem links going on line and
fetching too-big-an images as the producers of the TV show think that you
reduce the size of an image by using <img width=10 height=10> but still
leave the SRC a 200k tiff.

Another area is in corpeate internets; where people all log on during the
morning; and need to fech a 1Mb applet. Or in brokerage/finance trading;
or the POS systems at the end of the day. Even the newspaper site I used
to work for had regular peaks which where about 150-250x higher during
predicatable 15-30 minute time slots; than the average - and the median
was well below that.

So no - you want to design for the capability to handle the worst cases -
whilst ensuring it does a good job of the avergage case :-)

Dw
-- 
Dirk-Willem van Gulik

On Thu, 11 Apr 2002, Cliff Woolley wrote:

> On Thu, 11 Apr 2002, Aaron Bannert wrote:
>
> >  Under typical conditions, long-running and short-running requests will
> >  be distributed throughout the children. In order for this scenario to
> >  occur, all M threads in a child would have to be in use by a long-lived
> >  connection. Assuming a random distribution of these clients, I don't
> >  see how this scenario can consistently occur except when all threads
> >  across all children are already being occupied by long-lived connections.
>
> Another thing of note is that this sort of problem will only happen (or
> rather, will only be severe) when the server goes instantaneously from x
> concurrent connections on average to x+y concurrent connections, where y
> is large, which is what's happening when you suddenly ab pound a server,
> because p_i_s_m doesn't have a chance to keep up.  Under production
> circumstances, the number of concurrent connections would tend to have
> less significant discontinuities.
>
> --Cliff
>
> --------------------------------------------------------------
>    Cliff Woolley
>    cliffwoolley@yahoo.com
>    Charlottesville, VA
>
>
>


Mime
View raw message