At 04:26 PM 7/7/00 -0400, Benjamin Saller wrote:
>Today, Chuck Esterbrook wrote:
> At 01:31 PM 7/7/00 -0400, Benjamin Saller wrote:
> >Today, Chuck Esterbrook wrote:
> > This feels like an important question when considering performance
> > requirements of a production web site.
> >How is this important? I agree that this is good information to
> have, but
> >I wouldn't say that for performance reasons. What do you have in mind?
> Well there are various technologies like CGI, PHP, Java app servers,
> app servers, etc. They have different costs, performance characteristics
> and other advantages/disadvantages.
> Whichever solution you choose, it has to perform adequately on the
> that you can afford for the maximum number of concurrent requests you're
> going to have.
>Right, but your original question was asking about peak load times and
>that was the part that threw me. You need to plan your resource allocation
>around the peak that you intend to support. Even if you can dynamically
>adjust the resources available to the application (say in a
>load-balanced cluster) you would do that based on some load/usage metric
>and not time of day.
Er, what? Isn't my peak going to happen around some time during the day?
Like maybe every gets home and checks this site in the mid-evening. Or
perhaps lunch time is popular.
I know approximately how many customers and how many hits in a month, but I
can't divide by 24 hours because hardly anyone will hit the site say from
12AM to 7AM. Assuming that all the hits for a day happen at the same time
is the other extreme.
I need something in between. A histogram of hits per hour of the day would
> Of course, another application of this knowledge might be knowing when
> production support will be heavy.
>In terms of customer support? Or is the expectation that peak load creates
>runtime problems and the site needs babysitting?