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 > [EMAIL PROTECTED] > Charlottesville, VA > > >
