Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
負荷テストについて
skill wednesday
2016.8.17
自己紹介
なまえ: 石田尭大
おしごと: サーバーサイド
好きなもの: 酒, 音楽
好きな言語: Ruby, Python, PHP etc…
(まあ何か動的なやつ)
(でもelixirいいよね。
最近全然書いてないけど)
負荷テストについて
※HTTP APIを中心に話します
…そもそも何で負荷テストをするの?
Web(に限らずですが)アプリケーションが直面する問題
・運用開始したは良いけれども、思うような性能が出ていない
(大してユーザー居ないのに全然アクセス捌けない!!!)
・ユーザーが順調に集まって開始早々サーバーがヒーヒー言っている
(性能上限...
チューニングの必要性のため
つまるところ…
最終的にはこのようなサイクルを回したい
テストの実施
ボトルネックを推測
改善施策を実施
でも負荷テストって何すればいいんだ?
そもそも負荷テストにはどのような種類があるのか
基礎テスト : システムの負荷特性を調べるための基本的なテスト
ストレステスト : システムの限界値を探るためのテスト
ピークロードテスト : 高負荷時を想定したテスト
スパイクテスト : メディ...
知りたいことはなんだろう
負荷テストを行う上で最低限知りたい事
スループット : 単位時間あたりに処理出来るデータ量
レスポンスタイム : 処理要求に対してシステムが応答するまでに掛かる時間
リソース使用量 : メモリ・CPU・ネットワーク使用量
こんな感じの図で表現したい
この図を得るため以下を実施
5分間、エンドポイントに対して、リクエストを発生させて負荷を掛ける
このテストを10クライアントずつ数を変化させて、グラフを生成するのに必要な分計測を
実施
基礎テスト+ストレステストのような感じ
テストするAPIを選別
本来は全てやるべきであるが、
コードと設計書から重要なAPIを選別してテスト対象に
計測に使用したツール
cURL
dstat
(pm2-interface)
テストツール。pythonでシナリオ作成可能
レスポンスタイムをlogに出力するために使用。
リソース使用量をlogに出力するために使用。
プロセス自体のリソース使用量...
データを整理して図が得られた!
ここで結果をダラダラ並べても面白くはないので…
ボトルネックについて考えてみる
ボトルネックと言っても多岐に渡る
DBネック
ネットワークネック
CPUネック
ディスクネック(I/Oネック)
etc...
どこが問題なのか切り分ける
DBのCPU Utilizationが高騰していないか
SQL実行数が予想以上に多くないか
不要なデーター読み出しをしていないか
キャッシュを利用出来ているか
ここの部分で何が起きているか考える
※GETパラメータに応じてデーターを DBから持ってきてJSONにして返す処理
問題の切り分け
RDSのCPU Utilizationは最大でも11%
Network Trafficも20Mbps程度
APサーバー内部で、ディスクに書くような処理は無い
(dstatで見てもioの読み書きは発生していない)
APサーバーのC...
CPUネックと分かったら
サーバー側コードでの該当部分を見る
処理内容精査
冗長な部分が有れば修正
これ以上修正出来なければサーバーの
台数を増やせないか検討
再度負荷テスト
結論
・ボトルネックの箇所は処理内容で全然異なる
・吐き出されるログが全て物語っているので、頭を回して読み取る
ご清聴ありがとうございました
Upcoming SlideShare
Loading in …5
×

負荷テストについて

1,115 views

Published on

2016年8月17日に開催されたskill wednesdayの時に発表した資料です。

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

負荷テストについて

  1. 1. 負荷テストについて skill wednesday 2016.8.17
  2. 2. 自己紹介 なまえ: 石田尭大 おしごと: サーバーサイド 好きなもの: 酒, 音楽 好きな言語: Ruby, Python, PHP etc… (まあ何か動的なやつ) (でもelixirいいよね。 最近全然書いてないけど)
  3. 3. 負荷テストについて ※HTTP APIを中心に話します
  4. 4. …そもそも何で負荷テストをするの?
  5. 5. Web(に限らずですが)アプリケーションが直面する問題 ・運用開始したは良いけれども、思うような性能が出ていない (大してユーザー居ないのに全然アクセス捌けない!!!) ・ユーザーが順調に集まって開始早々サーバーがヒーヒー言っている (性能上限が分かっていなかった!)
  6. 6. チューニングの必要性のため つまるところ…
  7. 7. 最終的にはこのようなサイクルを回したい テストの実施 ボトルネックを推測 改善施策を実施
  8. 8. でも負荷テストって何すればいいんだ?
  9. 9. そもそも負荷テストにはどのような種類があるのか 基礎テスト : システムの負荷特性を調べるための基本的なテスト ストレステスト : システムの限界値を探るためのテスト ピークロードテスト : 高負荷時を想定したテスト スパイクテスト : メディア露出など、瞬間的なアクセス発生と発生後を想定したテスト 耐久テスト : 長時間の稼働を想定したテスト
  10. 10. 知りたいことはなんだろう
  11. 11. 負荷テストを行う上で最低限知りたい事 スループット : 単位時間あたりに処理出来るデータ量 レスポンスタイム : 処理要求に対してシステムが応答するまでに掛かる時間 リソース使用量 : メモリ・CPU・ネットワーク使用量
  12. 12. こんな感じの図で表現したい
  13. 13. この図を得るため以下を実施 5分間、エンドポイントに対して、リクエストを発生させて負荷を掛ける このテストを10クライアントずつ数を変化させて、グラフを生成するのに必要な分計測を 実施 基礎テスト+ストレステストのような感じ
  14. 14. テストするAPIを選別 本来は全てやるべきであるが、 コードと設計書から重要なAPIを選別してテスト対象に
  15. 15. 計測に使用したツール cURL dstat (pm2-interface) テストツール。pythonでシナリオ作成可能 レスポンスタイムをlogに出力するために使用。 リソース使用量をlogに出力するために使用。 プロセス自体のリソース使用量を logに出力するために使用。 計測自体はスクリプトを書いて、半自動実行できるように
  16. 16. データを整理して図が得られた!
  17. 17. ここで結果をダラダラ並べても面白くはないので…
  18. 18. ボトルネックについて考えてみる
  19. 19. ボトルネックと言っても多岐に渡る DBネック ネットワークネック CPUネック ディスクネック(I/Oネック) etc...
  20. 20. どこが問題なのか切り分ける DBのCPU Utilizationが高騰していないか SQL実行数が予想以上に多くないか 不要なデーター読み出しをしていないか キャッシュを利用出来ているか
  21. 21. ここの部分で何が起きているか考える ※GETパラメータに応じてデーターを DBから持ってきてJSONにして返す処理
  22. 22. 問題の切り分け RDSのCPU Utilizationは最大でも11% Network Trafficも20Mbps程度 APサーバー内部で、ディスクに書くような処理は無い (dstatで見てもioの読み書きは発生していない) APサーバーのCPU Utilizationが50% CPUネックの疑いが大!!!
  23. 23. CPUネックと分かったら サーバー側コードでの該当部分を見る 処理内容精査 冗長な部分が有れば修正 これ以上修正出来なければサーバーの 台数を増やせないか検討 再度負荷テスト
  24. 24. 結論 ・ボトルネックの箇所は処理内容で全然異なる ・吐き出されるログが全て物語っているので、頭を回して読み取る
  25. 25. ご清聴ありがとうございました

×