MORE負荷をかけてみよう2015.03.25皆様お久しぶりです。シニアプログラマの小田です。今回は、今までお伝えしてきました負荷についてを理解を深めるために、実際に負荷をかける手順について記述致します。I/Oは?と思ったそこのあなたは、きっと私の追っかけでしょうwブログを読んでいただき有り難うございます。次回のタイミングでお話致します。今回行うのは「負荷をかける」なのですが、注意点にも触れていきたいと思います。朝昼夕夜の4ローテーションでAPI数を算出2,3を元に、同時接続数を算出いかがでしょうか?負荷テストは「想定」の上に成り立っておりますが、何事も仮説があって検証してこそ実証されるのです。私は特に注意しているのが、「3.1プレイで呼び出されるAPI数を想定」です。ここを外してしまうと、全く意味のない負荷テストになってしまいます。APIの想定ではどのように、想定すればいいいのでしょうか?要点だけ軽く説明致します。これは当然ゲームによっても異なりますし、ゲームの設計に合わせて変更すべき内容のため、みなさまの環境に応じて変更してください。※注意点として、負荷テスト用にレスポンスのデータ構造を変更してはいけません。意図しないデータ構造での負荷テストは意味が無いためです。呼び出し順序は適切か?ログイン処理を毎スレッド通るようになっていないか?呼び出し回数は適切か?例えば1日1回ガチャを回すということはあるのか?例えば1日1回パーティー編成を行うということはあるのか?例えば1日1回売却を行うということはあるのか?この2点です。え?それだけ?と思ったかもしれませんが、私が注意するのはだいたいこの2点です。いえこの2点だけでも条件を満たすシナリオを作るのは骨が折れます。jMeterでシナリオを作ったことがある人ならわかるはずです。ランダム、ループ、1度だけ実行といったさまざまな処理を組み合わせて用意してください。負荷テストの実施はっきり言います。負荷テストは「トライアンドエラー」しかありません。楽してチューニングなどできないのですが、日頃の行いがいいと、負荷テストも楽になります。※前回のCPU使用率についての時のjMeterで自動化の話をすればいいのです。今までにあげた注目ポイントを見ましょう2で負荷がかかっている箇所をチューニングしていきましょうxdebugで無駄な呼び出し回数はないか?スロークエリはないか?インデックスの見直し呼び出し方法をリファクタリングetc。3が終われば、また1からの繰り返しまとめ今回記述した内容は特別なことは書いておりません。すると当たり前のことかもしれません。みなさんはその当たり前のことができておりますでしょうか?負荷テストは本当に長いトンネルのように解決できない時は頭をかかえるかもしれません。そんなときは、一度シナリオから見直すことをオススメ致します。想定が正しいのか?というところは常につきまといますし、私の経験上、それによって解決することもありました。ログの残し方や対応方法によっては負荷にはなりませんが、知らないうちに負荷になりえるのです。ログの残し方は他のエンジニアがブログに書いていくと思いますので、私からは注意喚起だけにとどめて締めくくりたいと思います。採用情報クラウドクリエイティブスタジオではプログラマを募集しております。