ステップ4. サーバーとのやり取りに必要な平均CPU処理量を評価する
サーバーとのやり取り1回当たりの平均CPU時間はどの程度だったでしょうか。
1.0秒以上であれば、いったん作業をやめて、パフォーマンス要求について検討した方がよいでしょう。また、値が小さい(0.3秒程度以下)であっても、ユーザー数が多いのであれば、大人数が使った場合にどうなるか考えてみる必要があります。
大雑把にトランザクション当たりの平均CPU時間、同時利用ユーザー数、ユーザーのクリック率/サーバーへの要求頻度などを見積もり、どの程度のパフォーマンスが必要か、大まかに見て達成できそうなパフォーマンス要求か、を検討してみましょう。
注：大まかな見積もり例 - ユーザーが1000人いて、全員が平均5秒ごとにサーバーに要求を送り、トランザクション当たりのCPU時間は平均1.5秒であるとしましょう。体感応答時間(PERT)の目標を2.0秒程度と想定します。この場合、5秒間に、少なくとも1000 × 1.5 = 1500秒のCPU処理時間が必要です(条件をごく単純化した理論値)。CPU時間300秒に相当する処理を1秒で処理しなければならないことになり、話になりません。サーバーを32台、並列に動かしたとしても、多少はましかも知れませんが、パフォーマンスが1桁足りません。
System iサーバーのパフォーマンスチューニングによっても、1桁のパフォーマンス改善はほとんど不可能でしょう(もっとも、複雑なSQL処理の場合、この程度改善できることがないわけではありません)。
通常、IBM i レベルでのパフォーマンスチューニングでは、アプリケーションの応答時間を改善する効果しかありません。
本当にパフォーマンスを改善する手段は、次の2つに限られます。
· プログラムを改良してCPUの処理量を減らす
· System iサーバーの処理能力を強化して、1秒あたりのCPUサイクルを増やす
応答が返るまでの平均CPU占有時間が2.0秒であるとしましょう。
CPUによる処理時間だけで平均2.0秒かかる、ということです。夜中の11時15分に作業し、1000MbitのLAN環境で、アプリケーションがメモリー上に常駐しており、ほかに誰もサーバーや通信ネットワークを使っていない、というような条件が揃っていない限り、体感応答時間(PERT)2〜3秒を実現するのは不可能ですし、5.0秒も難しいでしょう。
負荷が高いシステムでは、CPU占有時間が2.0秒であっても、体感応答時間は30秒以上になってしまいます。ほかのL4Webジョブはもちろん、5250セッション、バッチ・ジョブ、Apache HTTPサーバー、ネットワーク・ファイル・マネージャー、プリンター・ライターなど、多くのジョブが稼働しているからです。