Blog ブログ

1. jMeter
• 適切なシナリオ
2. サーバ環境　・・・　今回はLAMPで行きましょう
• xdebug　・・・　プロファイリングのために必要です
• KCachegrind　・・・　Mac上でxdebugのプロファイル結果を見れます
1. 準備編
2. 入門編
3. 実践編
• MySQL　・・・　スロークエリの設定（まずは500msでいいかと思います）
3. モニタリングツール
• MUNIN
• その他クラウドサービスに備え付けのモニタリングツール

みなさんはどのようにシナリオを考えておりますでしょうか？

一番の負荷の想定で大事なのは同時接続数ですが、例えば以下のように考えてみてはどうでしょうか？

1. ピーク時のDAUを想定
2. DAUからピーク時間中のアクセス率を想定
• 大体n〜m％ぐらい　・・・　過去の経験から想定するとよりいいですね
3. 1プレイで呼び出されるAPI数を想定
• 朝昼夕夜の4ローテーションでAPI数を算出
4. ２,３を元に、同時接続数を算出

いかがでしょうか？負荷テストは「想定」の上に成り立っておりますが、何事も仮説があって検証してこそ実証されるのです。

さて、私は特に注意しているのが、「３．1プレイで呼び出されるAPI数を想定」です。

ここを外してしまうと、全く意味のない負荷テストになってしまいます。

APIの想定

ではどのように、想定すればいいいのでしょうか？

要点だけ軽く説明致します。これは当然ゲームによっても異なりますし、ゲームの設計に合わせて変更すべき内容のため、みなさまの環境に応じて変更してください。

※注意点として、負荷テスト用にレスポンスのデータ構造を変更してはいけません。

　意図しないデータ構造での負荷テストは意味が無いためです。

1. 呼び出し順序は適切か？
• ログイン処理を毎スレッド通るようになっていないか？
2. 呼び出し回数は適切か？
• 例えば1日1回ガチャを回すということはあるのか？
• 例えば1日1回パーティー編成を行うということはあるのか？
• 例えば1日1回売却を行うということはあるのか？

jMeterでシナリオを作ったことがある人ならわかるはずです。ランダム、ループ、1度だけ実行といったさまざまな処理を組み合わせて用意してください。

負荷テストの実施

はっきり言います。負荷テストは「トライアンドエラー」しかありません。

楽してチューニングなどできないのですが、日頃の行いがいいと、負荷テストも楽になります。※前回のCPU使用率についての時のjMeterで自動化の話をすればいいのです。

実施方法ですが、

1. jMeterシナリオの実行
• 複数台から実行するときは
• 【jMeterフォルダパス】/bin/jmeter.sh -n -t 【シナリオファイル名】
• 止めるときはshut_down.shというのがあるので、それを使う
• 単一実行の時は、Ctrl+Cで止めればいい
2. モニタリングツールを常に監視
1. 今までにあげた注目ポイントを見ましょう
3. ２で負荷がかかっている箇所をチューニングしていきましょう
• xdebugで無駄な呼び出し回数はないか？
• スロークエリはないか？
• インデックスの見直し
• 呼び出し方法をリファクタリング
• etc。。。。
4. ３が終われば、また１からの繰り返し

今回記述した内容は特別なことは書いておりません。もしかすると当たり前のことかもしれません。ですが、みなさんはその当たり前のことができておりますでしょうか？

負荷テストは本当に長いトンネルのように解決できない時は頭をかかえるかもしれません。そんなときは、一度シナリオから見直すことをオススメ致します。

想定が正しいのか？というところは常につきまといますし、私の経験上、それによって解決することもありました。大半は自分たちが書いたコードが原因ではありますが、常に「疑いを持って取り組む」ということをすれば、負荷テストもきっと楽におわらせられるようになるはずです。