Set Your Sights

Set Your Sights
What are your application’s performance requirements? Using our example, assume you must grow the workload by 400 percent and still run it in the same amount of time (one hour). This means you must process 500,000 records in one hour. It also means you must use 5,000 seconds of CPU time (because the CPU time per CA record was 10 milliseconds).
Now you must ask yourself:
1. Is there enough CPU time available to do the work in the prescribed elapsed time?
2. What must I do to increase the throughput rate by 400 percent?
3. How many disk arms do I need to maintain my throughput rate without the disks becoming a bottleneck?
Regarding CPU availability, you have a couple of options. One is to reduce the amount of CPU resource used by the job so you can process 500,000 records in 3,600 seconds. In our example, only one job is running at a time; this is key because on the AS/400, a single job that isn’t using multi-threading can use only one CPU at a time. Assuming, for now, that the job could drive the processor to 100 percent busy, you’d have a shortfall of 1,400 seconds (500,000 records at .010 seconds/record is 5,000 seconds). With 3,600 seconds available in an hour, the requirements exceed the machine’s current capability.
Continuing with the assumption that the job could drive the processor at 100 percent busy, the job’s CPU usage must be reduced from .010 seconds per CA record to .0072 seconds per CA record (or 28 percent) to meet the requirement. If you can’t reduce the CPU usage this much, you’ll need more CPU time to meet the processing time objective. You need a machine that’s at least 28 percent faster so you have the equivalent of 5,000 seconds of the current system’s CPU time available in an hour.
The key assumption here is that the application job can drive the CPU to 100 percent busy. In almost all cases of batch database processing, this isn’t the case — at least not initially. Most batch work runs at CPU utilization rates between 2 and 8 percent. In our example, the job used 1,000 seconds of CPU time in an hour, which is 27.7 percent utilization.
So how do you drive up the CPU usage? The answer is to run multiple concurrent jobs (i.e., use batch-job parallelism) by restructuring the runtime environment to have more than one copy of the job running at once.
If your single job is using some percentage of the CPU in a single job environment, and you want to increase your application’s throughput, your objective is to get k copies of the job running, where k is 100 divided by the job’s CPU utilization. In our preceding example, k would be about four (100/27.7). You need to distribute the processing workload (e.g., input data) evenly over four jobs and let them run. In some applications, this is easy to achieve with the OVRDBF (Override Database File) command; in others, it requires some study and reworking of the application.
What if the value of k is so large that you over-commit the processor and try to drive it at 150 percent or higher? In this case, you need to have more CPU time available, which means moving to an n-way processor. The n-way processors have multiple CPUs, which provide you with (n x 3,600) seconds of CPU time per hour (or n seconds of CPU time per second).
Thus, with a demand for 5,000 seconds of CPU time to complete the job in one hour, you need at least a two-way processor that has 7,200 seconds of CPU time available in an hour (3,600 seconds per hour per CPU times two CPUs). If you run five copies of the job simultaneously, they should complete their work in the prescribed time and use about 70 percent of the CPU (5,000/7,200).