Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
Webサーバの性能測定  ~ 初めての性能測定~                  2012/06/10         h13i32maru@Twitter           maruyama-r@KLab
自己紹介• 丸山 亮(h13i32maru) 最近はPHP/JSを触ってます• KLab株式会社所属32   http://blog.h13i32maru.jp     http://twitter.com/h13i32maru     htt...
わーい、Webサービスできた    よ(・∀・)
あれ、全然性能出てない   \(^o^)/
ということにならないために事前に性能測定しておきま     しょう
性能測定• 測定対象 • 今回はWebサーバの1台の性能測定を行う• 測定方法 • 攻撃マシンから大量の並列HTTPアクセスを行  う
環境EC2 + Python + Tornado + nginx + HAProxy
性能とは?• 1秒間あたりに処理できるリクエスト数(req/sec) • 多ければ多いほど良い• リクエストを処理する時間(レスポンスタイム) • 短ければ短いほど良い
req/secとレスポンスタイム• 攻撃マシンから並列リクエスト数を上げると? • req/secとレスポンスタイムが徐々に上がってい  く • →ある程度までreq/secが上がると、レスポンス  タイムが急激に上がる(サーバのリソース不足)
限界性能とは?• 攻撃マシンから並列リクエスト数を上げると? • req/secがどこかで頭打ちになる → 限界 • レスポンスタイムが著しく上昇する → 限界 • CPU使用率が100%近くになる → 限界 • LoadがCPUコア数より多く...
準備:攻撃するURL• どのURL(機能)を攻撃するか決める • ユーザの一連の行動に近いURL群 • ユーザが頻繁にアクセスするURL群 • 処理が重いであろうURL群
準備:攻撃マシン• 同じLAN内に設置する • WAN経由だと測定に影響がでてしまう• 並列にHTTPリクエストを実行できるツール • green-hakai • https://github.com/KLab/green-hakai
準備:リソース可視化• Webサーバの各種リソースをグラフで表示 • CloudWatch, Gangila, etc...• リソース • CPU, Load, Memory, NIC, Disk • DBも一応見ておく(qeury/sec,...
準備:LANの帯域測定• LANのネットワーク帯域を測定しておく • iperf使うと簡単• リクエスト数が膨大になると帯域を使い切ること がある
準備:変動させるパラメータ• 何を変動させて性能を測定していくかを決める• 今回は • Tornadoのプロセス数 • nginxのWorker数 • 並列リクエスト数
測定• パラメータを1つずつ変えながらグラフを作成 • 一度に沢山のパラメータを変えない• req/sec, レスポンスタイム, CPU, Loadなどをグラフ にする• 測定は2分以上したほうが良い • 1分毎にリソースを監視するツールが多いため
検討• リソースをぎりぎり使いきっているか? • CPUは100%近いか? • Loadがコア数以上発生していないか?• 予想していたグラフになっているか? • 異なる場合はどこに原因があるのか?
予想 → 測定 → 検討 → 調査     これ大事
その他• プログラムのプロファイルも取って見る • PythonならcProfile (これはまたの機会にまとめ  る)• HTTP キープアライブの検討もしてみる • JSONなどを返すAPIサーバの場合、ちょっと長  めにとっておく(20~3...
最後に• はじめて性能測定をやってみて面白かった• 予想、測定、検討、調査のサイクルでボトルネッ クを探す• まだまだ初歩的なことばかりだけど何かの参考に なればいいな
おわり
Nächste SlideShare
Wird geladen in …5
×

Webサーバの性能測定

  • Als Erste(r) kommentieren

Webサーバの性能測定

  1. 1. Webサーバの性能測定 ~ 初めての性能測定~ 2012/06/10 h13i32maru@Twitter maruyama-r@KLab
  2. 2. 自己紹介• 丸山 亮(h13i32maru) 最近はPHP/JSを触ってます• KLab株式会社所属32 http://blog.h13i32maru.jp http://twitter.com/h13i32maru https://www.facebook.com/ryo.maruyama https://github.com/h13i32maru
  3. 3. わーい、Webサービスできた よ(・∀・)
  4. 4. あれ、全然性能出てない \(^o^)/
  5. 5. ということにならないために事前に性能測定しておきま しょう
  6. 6. 性能測定• 測定対象 • 今回はWebサーバの1台の性能測定を行う• 測定方法 • 攻撃マシンから大量の並列HTTPアクセスを行 う
  7. 7. 環境EC2 + Python + Tornado + nginx + HAProxy
  8. 8. 性能とは?• 1秒間あたりに処理できるリクエスト数(req/sec) • 多ければ多いほど良い• リクエストを処理する時間(レスポンスタイム) • 短ければ短いほど良い
  9. 9. req/secとレスポンスタイム• 攻撃マシンから並列リクエスト数を上げると? • req/secとレスポンスタイムが徐々に上がってい く • →ある程度までreq/secが上がると、レスポンス タイムが急激に上がる(サーバのリソース不足)
  10. 10. 限界性能とは?• 攻撃マシンから並列リクエスト数を上げると? • req/secがどこかで頭打ちになる → 限界 • レスポンスタイムが著しく上昇する → 限界 • CPU使用率が100%近くになる → 限界 • LoadがCPUコア数より多く発生する → 限界 • etc...
  11. 11. 準備:攻撃するURL• どのURL(機能)を攻撃するか決める • ユーザの一連の行動に近いURL群 • ユーザが頻繁にアクセスするURL群 • 処理が重いであろうURL群
  12. 12. 準備:攻撃マシン• 同じLAN内に設置する • WAN経由だと測定に影響がでてしまう• 並列にHTTPリクエストを実行できるツール • green-hakai • https://github.com/KLab/green-hakai
  13. 13. 準備:リソース可視化• Webサーバの各種リソースをグラフで表示 • CloudWatch, Gangila, etc...• リソース • CPU, Load, Memory, NIC, Disk • DBも一応見ておく(qeury/sec, Thread数)
  14. 14. 準備:LANの帯域測定• LANのネットワーク帯域を測定しておく • iperf使うと簡単• リクエスト数が膨大になると帯域を使い切ること がある
  15. 15. 準備:変動させるパラメータ• 何を変動させて性能を測定していくかを決める• 今回は • Tornadoのプロセス数 • nginxのWorker数 • 並列リクエスト数
  16. 16. 測定• パラメータを1つずつ変えながらグラフを作成 • 一度に沢山のパラメータを変えない• req/sec, レスポンスタイム, CPU, Loadなどをグラフ にする• 測定は2分以上したほうが良い • 1分毎にリソースを監視するツールが多いため
  17. 17. 検討• リソースをぎりぎり使いきっているか? • CPUは100%近いか? • Loadがコア数以上発生していないか?• 予想していたグラフになっているか? • 異なる場合はどこに原因があるのか?
  18. 18. 予想 → 測定 → 検討 → 調査 これ大事
  19. 19. その他• プログラムのプロファイルも取って見る • PythonならcProfile (これはまたの機会にまとめ る)• HTTP キープアライブの検討もしてみる • JSONなどを返すAPIサーバの場合、ちょっと長 めにとっておく(20~30sec)
  20. 20. 最後に• はじめて性能測定をやってみて面白かった• 予想、測定、検討、調査のサイクルでボトルネッ クを探す• まだまだ初歩的なことばかりだけど何かの参考に なればいいな
  21. 21. おわり

×