まず処理速度を測定する
速度を向上するときに最初にやることは、現在の処理速度（処理にかかる時間）を測定することです。
このときのポイントを列挙します。
- 本番で想定される件数のデータをDBに登録しておくこと。
- 本番で想定される件数のデータを実行して測定すること。
- 2と同じデータで再実行できるようにしておくこと。
- 処理のかたまりごとにログを仕込んでおくこと。
ログ出力も処理時間がかかる
Javaでもシェルでも何でもそうなのですが、ログは出力するだけで時間がかかります。
測定対象の処理を実行したときに、ログが1000行以上出るようだとログ出力による性能劣化が発生するので留意しておく必要があります。本番でもその通りにログを出力するなら、そのまま改善作業に入りますが、本番とは違うログレベルで実施している場合は、「ログが出なければ目標値クリアできるのでは？」ということも検討する必要があります。
ボトルネックを見つける
出力されたログからすぐにボトルネックが見つかることもあります。「明らかにこのSELECT文で全体の8割の時間がかかってるね」という場合はラッキーです。そのSELECT文をインデックスが効くようにすることで、処理時間は0秒に近づいていくでしょう。
ただし、そんなケースは希です。多くの場合は、特定の箇所で時間がかかっているのではなく、複数の処理のかたまりがあって、全体的に時間がかかっているという感じだと思います。
そのときは、複数ある処理のかたまりのうち、最も時間がかかっているところから改善していくのが良いでしょう。1つのかたまりが改善されることで、目標値をクリアできるなら、それで良いでしょう。
Webアプリ（ソースコード）の処理速度向上
Webアプリの処理速度向上は、エンジニアの技量が問われます。次のような観点で見てみましょう。
- 重複した処理はないか。
- ループの中で1件ずつ同じデータを取り直していないか。
ループごとにデータを取り直しているなら、データ取得処理をループの外側でやることで、データをとる回数を最低限にすることができます。
SQL・DBアクセスの処理速度向上
SQLやDBアクセスに時間がかっているとします。どのような改善が可能でしょうか？
SELECT文の場合は、まずWhere句で指定しているカラムの順番が、インデックスが効くようになっているかを確認します。SQL Serverなどでは、カラムの順番がインデックス通りでなくても、SQL Server側で適切なカラムの順番に直して実行してくれるようです。
サブクエリ（副問い合わせ）が使用されている場合は、クエリを分割して、クエリ1つずつの実行計画を確認して、インデックスが効いているか、フルスキャンが発生していなか確かめていきます。インデックスが効いていないなら、インデックスを効かせることで、SQLの実行速度は最低でも数十倍は改善します。
UPDATEやDELETEもSELECT同様にインデックスを確認することで改善できます。
INSERTはプログラム中からどのように呼ばれているかが問題です。1件のINSERTでは時間がかからなくても、注文－明細のようなデータ構造の場合、明細数が多いときは改善できる可能性があります。
Javaであれば、PreparedStatementを使って明細をINSERTする場合、1件ずつINSERTするのではなくて、PreparedStatement#addBatchで明細を溜めていき、最後にPreparedStatement#executeBatchをすることで、アプリサーバ→DBサーバのやりとりが減り、劇的に処理速度を改善することができます。200件INSERTするとしたら、1件につき20倍ぐらい高速化できることがあります。
処理速度向上しやすいアーキテクチャにしておく
処理速度向上、性能改善の案件に入って感じたことですが、処理速度の改善をしやすいアーキテクチャにしておくことが重要です。
これは、性能テストフェーズに入ってからでは遅くて、アーキテクチャ構築時から意識しておく必要があるポイントです。
処理速度向上しやすいアーキテクチャって何かというと、要するに「変更しやすい」ような作り、クラス構造にしておかないとダメということです。
と言っても、処理速度向上に限ったことではなく、保守フェーズにはいってプログラム修正するときと同じです。ボトルネックがわかって、処理速度向上に必要な施策を思いついたとします。しかし、クラス同士が複雑にからみついていたり、層が深くて可読性の低いクラス構造になっていると、安全に変更を加えることができません。
保守性の低い＝変更リスクが高いクラス構造になっていると、せっかくボトルネックがわかっても、変更することを躊躇してしまうのです。