画面の読み込みに30秒かかったり、レポートが終わらなかったりすると、すぐに対処しなければというプレッシャーがかかります。サーバーの増強、データベースの微調整、結果のキャッシュ保存。どれも効果があるかもしれません。しかし、なぜ遅いのかを知らなければ、その対策が長続きするのか、あるいは単に来月まで問題を先送りしているだけなのかを判断できません。
私は着実で段階的なアプローチを好みます。結局はその方が解決が早く、コストを負担する側への説明もはるかに容易だからです。
まず、何が遅いのかを正確に特定する
まずは具体化することから始めます。どの画面、どのレポートか？ どの顧客、どの期間、どの検索条件か？ 常に遅いのか、それとも月曜の朝だけか？ 実際にデータベースが混雑しているのか、それとも全く別の場所で遅延が発生しているのか？
次に、変更後の効果を比較できるよう、現状を測定します。本番システムでのテストには細心の注意を払います。一度実行するだけなら無害な処理でも、繰り返し実行されるとシステム全体を低速化させる可能性があるからです。
データベースの処理プロセスを確認する
データベースは、倉庫内でのルートを選ぶように、要求された情報をどう探すかを自ら決定します。ほとんどのデータベースはその「ルート」を表示することができ、そこに答えが隠されていることが多いのです。
ほんの数件のデータを探すために、巨大なテーブルの全レコードを読み取っていることがあります。あるいは、統計情報が古いために、扱うデータ量を完全に見誤っていることもあります。検索の書き方のせいで、既存のショートカットが使えなくなっていることもあります。ルートを確認することで、どこに時間が費やされているかがわかり、推測ではなく真の原因を修正できます。
慎重にインデックスを追加する
データベースの低速化に対する最も一般的な対策は「インデックス」です。これは本の索引のようなもので、データベースがすべてを読み取ることなく、目的のレコードに直接ジャンプできるようにします。
ただし、インデックスにはコストがかかります。容量を消費し、データの保存や変更のたびにわずかな追加処理が発生します。増やしすぎると、特定のレポートは早くなっても、スタッフが一日中使う注文画面が遅くなる可能性があります。そのため、既存の構成やシステムの利用頻度を考慮し、単一のレポートだけでなく日常的な運用全体に照らして変更をテストします。
不要な処理を止める
驚くほど多くの低速なシステムが、単に「やりすぎ」ています。最初の20件を表示するために5,000件を読み込む。すべてを取得してから後でフィルタリングする。同じ製品カテゴリリストを何度も読みに行く。注文の各行ごとにデータベースへアクセスし、一度に取得できるものをバラバラに取得する、といったことです。
こうした無駄を省くことが、しばしば最大の結果をもたらします。ただし、変更後も以前と全く同じ正しい結果が得られるよう、慎重な作業が必要です。
本当にデータベースが原因かを確認する
データベースが犯人にされがちですが、遅延はクリックしてから画面が表示されるまでのどこでも発生し得ます。アプリケーションがデータベースの順番待ちをしていたり、ネットワーク経由で過剰なデータを送っていたり、ページの生成に時間がかかっていたりすることもあります。
そのため、各ステップの時間を個別に測定します。修正後は、利用者が少ない時だけでなく、多くの人が同時に使っている状況でも耐えられるかを確認します。そして、何を変えたのか、なぜ変えたのかを記録し、将来また遅くなった時に次の担当者が参照できるようにします。
アプローチを一行で言えば
原因を特定し、測定し、1つだけ変更し、再び測定する。目的は、特定のレポートを立派に見せることではありません。途中で何も壊すことなく、すべての人にとってシステムを高速化することです。