森俊輔 こんにちは。森です。
京都はぼちぼちな天気です。
負荷試験なんかで、こちらの想定よりも早い段階でサーバが悲鳴を上げると、やっぱりガーンて感じですよね。。
そんな時に見直す項目をいくつか挙げたいと思います。
今日は、DBサーバについてのみ書こうと思います。
1. インデックスを見直す
インデックスの張り忘れ、もしくは不正が最も高負荷に繋がります。
ですので、面倒くさくてもプログラム中の全SQLを抜き出してインデックスを再確認しましょう。
実行計画にて確認することが一番です。その際の注意点としましては、必ずある程度のデータ（多ければ多いほどよい）を用意しておいて下さい。
でないと、正しい結果を返してくれません。ちなみに応答速度は0.1秒以内を目指しましょう。
これだけで大体負荷は下がってくるはずです。
2. SQLを見直す
インデックスを設定してもダメな場合、まずはSQLを見直しましょう。
複雑なSQLはやっぱりレスポンスが遅いです。シンプルなSQLを心がけましょう。
１度のクエリで目的のデータが取れることはいいことですが、レスポンスが悪い場合は、思い切って複数回に分けることもありかもしれません。
SQLを変更したら、インデックスも設定ももれなくやりましょう。
3. プログラムを見直す
1, 2をやっても結果が芳しくない場合、プログラムを見直すことも必要です。
何回もループしていないか、何かおかしなコードはないか等、ログを埋め込みつつ原因を探りましょう。
4. テーブル構造を見直す
これ、最もやりたくないパターンです。
でも結果が出なければやらなければいけません。
テーブルを正規化することはとてもいいことですが、時には冗長化させた方がいいこともあります。
SQLはシンプルな方がいいということは、できればjoin句なんかも少ないほうがいいわけで、そうなるとテーブルの冗長化もある程度必要になってきます。
優れたSEさんたちは設計段階でそこまで計算しますが、設計がボロボロだと、後からとても痛い目にあいます。気をつけましょう。。
5. DBの設定を見直す
ここまでやれば、ほぼ負荷もなくなっていると思いますが、DBの設定は重要項目です。
必ずきっちり合わせて行きましょう。
これに関してはまた別途書きたいと思います。
6. サーバスペックをあげる
ここまでやってもダメな場合、ハード的にスペック不足を疑いましょう。もうやれることはやったと思いますので、思い切って上の人に相談しましょう。
大体こんな感じで負荷対策をしております。
随分ざっくりしていますが、何かの参考になれば幸いです。
