Suppose around time 13 in Figure 9-19 is when users are extremely upset. It's not time 23, because the users are asleep and the batch jobs are running just fine. The performance analyst must determine what is occurring-that is, the workload mix-during time 13 and work with the user community to shift a segment of that workload, perhaps to time 15. While this may seem unlikely, when confronted with a severe performance problem, a graphic clearly showing the situation (for example, Figure 9-19), users can be surprisingly flexible. But if they are told to change the way they work without understanding why, they will most likely rebuff any attempt to alter the workload.

Figure 9-19. Shown is a workload graph, which appears to have ample workload-balancing opportunities. By moving some of the workload during painful peak processing time to nonpeak processing times, the workload requirements during peak times are effectively reduced. This decreases response time, allows for increased workload of a specified type, or some combination of both.

In some cases, the users may not even be aware of the workload shift. For example, during a consulting engagement, I noticed a messaging process woke every 30 seconds to check for messages to transfer and then performed the transfer. I discovered even with only a few messages, there was a tremendous amount of overhead. I asked the application administrator (not the end users) if the message process could wake up every 5 minutes just during the peak processing times. To my surprise, he willingly embraced this rather elegant, zero downtime, and zero capital investment performance-improving solution.