|
|
- 《 品質管理編 》
著しい性能不良が試験工程で発覚
性能不良は、ＤＢの設定及び検索条件文TBL-JOINや動的SQLなど
設計時から性能を意識したＤＢ設計や業務設計を行っていないと
試験に入ってから再度見直しを行うはめになります。
単純なハード増強では、不可能なものが多いのです。
またサードパーティソフトを多く用いることは内部処理が見えないために
実際に使用すると期待値を大きく外れた性能になってしまいます。
サードパーティソフトの詳細知識や過去に使用経験があり特徴を知って
いない限り慎重に性能を考えた設計を行う必要があるのです。
設計者の性能における知識不足や経験不足がわかっている場合、
プロジェクトリーダーは、予め性能担当者を確保すべきです。
いずれの対策をとったとしても、やはり性能問題は少なからず発生します。
やはりこの時には、ＤＢの性能担当者や多くの経験者による
性能改善チームを立ち上げてトレースやログをとって
一つ一つ検証しながら改善していくしかありません。
この地道な作業を少なくするためにも、予めわかっている最低限の
性能対策は早めに対応しておくことです。
アプケーション上の性能問題の次は、
ラッシュテストによる負荷試験の性能問題になります。
バッチ処理が同時走行したり、検索条件が複雑な検索が多くあったりと
さまざまな処理タイミングが重なる想定試験を行うのです。
特にＷｅｂの場合は、想定件数の設定によって大きく対応策が変わって
くるので注意しなければなりません。
私は、残念ながらDBやWebの性能問題について
そこまで十分な知識はありませんが、
設計時点で考慮していないものは、
今どきのWebでは使えないと考えます。
アクセスが増えた段階で再度作り直すのであれば別ですが。
性能問題は、
ＤＢ
ハードディスク
ＣＰＵ
メモリー
ネットワーク
プリンター印刷
などに負荷が集中して遅くなります。
データ量やユーザー数や検索方法や業務処理タイミングなどで
大きく変わってしまいます。
ゆえに想定ケースを設定するにも難しいのです。
必ず、
設計時点で予測可能な性能問題は解決しておかなければなりません。
たとえ小規模システムでも改良によって大きく化ける可能性も
あるのです。
|
