Step 4. Assessing the Average CPU per Server Interaction
What is your average server CPU time per server interaction from your RAS?
If the average number is greater than 1.0, you need to stop and think carefully about your application and your performance expectations. Even if this number is lower (0.3 or less) and you are going to have a lot of application users, you need to think carefully about this number and what it means.
You should do some rough calculations here about average CPU cycles per transaction, the number of concurrent users, user clicking rates / server hit rates, etc, and see if what you want to achieve and what it is possible to ever achieve are at least in the same ballpark.
Note: A Ballpark Example – Imagine providing 1000 users, who all hit the server on average every 5 seconds, in an application with a 1.5 average CPU seconds per transaction time. They expect a 2.0 second PERT time. In a 5 second interval your server needs to provide (even just theoretically and grossly simplistically) at least 1000 x 1.5 = 1500 CPU seconds. That’s asking it provide 300 CPU seconds of processing power per elapsed second, which is nonsensical. Maybe 32 processors would help? It would, but you’d still probably be out by at least an order of magnitude.
Performance tuning your System i server will not normally reduce this number (it appears that sometimes it will if you are using complex SQL requests).
Normally IBM i level performance tuning will only impact the elapsed time of an application.
You can only really reduce this number by:
- Performance tuning your programs to use less CPU cycles.
- Increasing the power of your System i server so that it can execute more CPU cycles per second.
Imagine a high average CPU time of 2.0 per interaction.
This means your application requires 2.0 seconds of dedicated CPU cycles to complete its work (on average). This absolutely does not mean you can expect a 2.0, 3.0 or even 5.0 second PERT time unless it’s 11:15pm at night, you are on a 1000Mb LAN, using a memory resident application, and that nobody else is using the server or communications network.
On a busy system, getting access to 2.0 seconds of CPU cycles may take 30 elapsed seconds (or even a lot more) as your L4Web job competes with other L4Web jobs, 5250 sessions, batch jobs, the Apache HTTP server, network file managers, printer writers, etc.