In our previous example, the service requester signs up for 2,000 digital widgets a day. Do we simply assume the service usage rate will be linear throughout the day? And what’s the definition for the duration of a “day”? Twenty-four hours? Eight hours?
Service use often doesn’t occur in a linear fashion. There are peaks and valleys in usage rates. In the ’70s, when transaction systems became popular, it was apparent that people tended to work harder in the afternoon and some business services were more heavily used at specific times of the day just by the nature of the service. This became known as the peak hour demand (or demand latency). Some services might have multiple peak hours.
As peak hours occur, other ramifications develop. Since requester response time is elongating, the number of requests the requester really needs to make isn’t being addressed. So these new requests simply stack up, waiting their turn. This is similar to what happens on our roads at rush hour. A traffic light cycle time normally lets enough traffic through so the roads are only a little, if at all, congested. At rush hour, the same light cycle time is insufficient to allow the number of cars through the intersection to maintain a smooth flow of traffic. The cars back up and go slower. So is the peak hour of any digital service.
Using a 24-hour day, when there’s a peak hour demand, the digital asset/ resource requirements for the peak hour often double or triple the resources required for the other 23 hours. Figure 1 shows an example of peak hour representations of one service’s required resources.
If any of the resources are too con- strained to allow the utilizations represented in Figure 1, the requester perceives an elongation of response times plus a backup in user demand awaiting the service. Figure 2 shows a storage-constrained scenario.
There are two ways to deal with this situation. Each has pluses and minuses. Let’s take a look at each approach.
If there’s a workload manager controlling the service’s response curve and resources, it may dynamically add pool resources to address the storage constraint. It should simultaneously add extra server and bandwidth because, as we address the initial constraint, the demand may well flow to another resource constraint.