色々知見が溜まってきたのでポエムします
言いたいこと
- 「なにをもってゴールとするか?」の合意を取ろう
- まず実測
- 本番環境にできうる限り近い環境でやろう
- 実測ツール紹介
- 中央値も見よう
「なにをもってゴールとするか?」の合意を取ろう
やろうと思えばどこまでも高速化できてしまうので、最初に、なるべく実際の負荷に近いと思われる条件の元、 どんな条件で、どのような結果ならばOKか? の合意をチーム内で取りましょう
どんな条件での例
- アクセス方法(どのページにどんな頻度でアクセスするか?なるべく実際のユーザの挙動に近いほうが良い
- キャッシュの有無(厳密にやるならば、実際のキャッシュヒット率に近くなるようにやるべき。ページキャッシュやら、SQLキャッシュやら
どのような結果ならばOKか? の例
- 限界テスト : 何アクセス数まで、サーバが落ちないこと
- 性能テスト : 何アクセス数まで、平均レスポンスタイムがn秒以内であること
まず実測
計算上耐えられる負荷に耐えられることは100%無いです。 何かがボトルネックになって、計算上耐えられる負荷より前にサーバが悲鳴を上げます。本番でそれが起こると目もあてられないので、さっさと実測しましょう。 可能ならば、CIとかに組み込んでメトリクスを取ると更に良いです。
本番環境にできうる限り近い環境でやろう
可能ならば本番サーバでやるのが良いですが、無理ならば 可能な限り本番環境に環境を近づけて測定しましょう。 本番でだけproxyサーバを挟んでいる? それがボトルネックになって、本番環境だと負荷に耐えられないと思いましょう。 最近はAWSとか仮想環境に環境を構築している場合が多いと思うので、面倒臭がらずに同様の環境を1つ用意しましょう。あと、データも本番と同様にね!
実測ツール紹介
簡単に単一URLで負荷試験をしたい場合は、Apache Bench が楽に色々なデータが取れるのでオススメです。
複数URLで負荷試験したい場合は、apachebench-for-multi-url というツールも見つけましたが、自分は使わなかったので、誰か使ってみて下さい。
自分の場合は、色々制約や条件があったので、最終的にrubyで負荷ツールを自作しました。ただ、 自作ツールの場合、ツールそのものがボトルネックになる可能性も否定できない ので気をつけて下さい。
中央値も見よう
実測した結果を見てガッカリする前に、平均値だけでなく中央値も見てみましょう。
中央値 : 有限個のデータを小さい順に並べたとき中央に位置する値
平均値だけ高い場合と、中央値も平均値も高い場合とでは、対策が異なるので、平均値だけ見ていると無駄な努力をする羽目になります。
中央値も平均値も高い場合
- 全体のレスポンスタイムを下げる施策が必要
平均値だけ高い場合
- 特定のリクエストの場合のみ遅いのであれば、その原因を調査して取り除く
- リクエスト数によってタイムアウトや待ちが発生している場所を探す
そんなかんじです。良き計測ライフを!
