第3回 設計段階で性能を見積もろう
Webアプリケーションの画面を設計するとき、皆さんは性能について意識していますか。機能面の要望を取り込むことに集中するあまり、性能は二の次になっていないでしょうか。 あとになって性能が問題になるプログラムは、設計時に過ちを犯していることが少なくありません。そのような性能トラブルは、チューニングで簡単に解決しないことが多いものです。設計時に性能リスクを明らかにして早めの対策を打っておけば、致命的な性能トラブルの多くを防げます。 今回は設計段階で性能リスクを早期に発見するための性能見積もり手法について紹介します。設計段階で性能を作り込む手法には、多様なものがありますが、今回解説するのはその前段階として必要になるものです。どの機能に対して、工数をかけて性能を作り込むべきかを明らかするのが狙いです。 性能を見積もるメリットは二つ 設計段階では動作するプログラムが存在しないので、性能評価においては、
第2回 「応答一律3秒」という性能要件はやめよう
今回は、性能要件を具体化するポイントを紹介します。皆さんは、性能要件に何を定めればよいと思いますか。 システムの性能要件で、「Webアプリケーションの画面レスポンス時間は3秒以内であること」「バッチアプリケーションは毎日午前0～午前5時の間に終了すること」としか定義していないプロジェクトを見かけます。この場合、以下のような問題が潜んでいます。 （1）全機能の処理時間を同じレスポンス時間に収めなければならない 全機能に対して同じレスポンス時間を目標とするのは現実的ではありません。なぜなら、機能によって求められるレスポンス時間と処理の複雑度は異なるからです。 例えばコールセンターのシステムで、「（a）電話オペレーターが操作する画面」と「（b）管理者がマスターデータをメンテナンスする画面」があるとします。レスポンスの悪化が直ちにビジネス機会の損失につながる（a）の方が、求められるレスポンス時間は
第1回 性能品質は開発工程全体で作り込もう
性能要件の実現は重要だと認識しながら、「結局、性能は構築し終わるまで分からない」といったスタンスでプロジェクトに臨んでいないでしょうか。最初に性能要件を定義したあとは特に何もせず、カットオーバー直前にわずかな性能テストとチューニングを行うだけというケースを、筆者はよく見かけています。 そのようなスタンスでシステムを開発しても、性能要件をしっかりと実現できる可能性は高くありません。カットオーバー直前にその場しのぎの対策をするか、巨額の追加コストをかけてハードウエア増強に走る、といった状況に追い込まれがちです。 ITシステムの性能品質は本来、ライフサイクル全体を通して作り込むものです（図1）。設計、実装、テストの工程を通じて、システムの性能要件達成に取り組み、検証していく必要があります。 本連載では「システムの性能を確保するために何をすべきか」というテーマで、性能をマネジメントするための考え方
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
