Weitere ähnliche Inhalte Ähnlich wie 大規模ソーシャルゲームを支える技術~PHP+MySQLを使った高負荷対策~ (20) Mehr von infinite_loop (20) Kürzlich hochgeladen (11) 大規模ソーシャルゲームを支える技術~PHP+MySQLを使った高負荷対策~3. 自己紹介(1)
松井 健太郎
札幌出身、札幌在住
ke-tai.org 管理⼈
コーラとバイクツーリングが好き
株式会社インフィニットループ代表
19. Q. 言語やフレームワークは何をつかっていますか
A. 言語は主にPHPを使っていますが、
何でもいいと思います。フレームワークは自作です
開発言語
→ PHP, Perl, Rubyあたりをよく聞く
→ 得意な言語でよいと思うが、開発リソースの補充や、
新⼈教育が容易な⾔語が向いている
フレームワーク
→ 自作フレームワークを使っている
→ 以前はあえてのベタ書きだったが、開発効率や再利⽤性など
の⾯からフレームワークを作成し利⽤するように
→ symfonyなどの既存フレームワークを改造して使っている
などの話しも聞くが、最終的には魔改造されているようだ
25. Q. 負荷対策はどうしていますか?(2)
実際に使われている負荷対策チェックリスト
【共通処理編】
(1) 共通処理内で何をしているかを全て把握しているか
→ どういう処理が⾏われるか、SQLは何回流れているか、などを完全に把握すること
→ 共通部分に処理を⾜すときは、かならずチーム内で許諾を取ること
(2) そもそも、その処理は本当に必要なのか
→ 最も効果的な負荷対策は、処理の速度を速めるより処理⾃体を無くすことである
→ 特にクライアント - サーバ型のアプリの場合は、相当処理が削れる
→ クライアント側でキャッシュや処理できるような処理がないか⾒直す
(3) キャッシュはできないか
→ APCキャッシュ > memcache >>>>> MySQL の順で速い
(APCはWebサーバ単位でのキャッシュであることに注意)
→ 共通処理内では、SQL実⾏回数がゼロが望ましい
26. Q. 負荷対策はどうしていますか?(3)
(4) 無駄なものの発⾒
→ 無駄なrequireを潰すにはオートロードの導入が楽
→ XHProfのcallgraphでチェック
→ Jenkinsや自作スクリプトで、
無駄な定数や使われていないメソッドなどを掃除
(5) その他注意点
→ ロガーやエラーハンドラなど、思わぬところがネックになることもあるので、
呼ばれる回数が多いものは、必ずチェック&チューニングすること
→ $_SESSIONの利⽤は最低限に留めること
27. Q. 負荷対策はどうしていますか?(4)
実際に使われている負荷対策チェックリスト
【個別処理編】
(1) 遅いPHPランキングを作る(モグラ叩き法)
→ 実⾏速度を記録する仕掛けを作り、最も遅くて呼ばれる回数の多い順に対処
→ Apacheログからanalogなどで集計する方法も
(2) SQLの⾒直し
→ 遅い場合のほとんどはSQLが原因で遅い(アプリロジックでの負荷軽減は難しい)
→ 実際の本番とデータ数が違うと参考にならない、データは常に多めに入れておくこと
→ インデックス未使用のクエリやスロークエリログに載ってくるクエリを潰す
→ mk-query-digestで早くても実⾏回数の多いクエリを発⾒しチューニング
→ cactiなどのグラフから問題を発⾒する
(3) 仕様で⾒直す
→ 仕様をほぼ満たしつつも、影響なくルーズに作れるところがないかを常に検討
→ どうしてもダメなら仕様の⾒直しを相談
30. Q. 負荷対策はどうしていますか?(7)
ロック競合対策
負荷はかかっていないがパフォーマンスが出ない、
Lock wait timeoutが多発する、などの場合はロック競合を疑う
マスター分割されている場合は、
デッドロック検出がされないので更に厄介
【対策】
トランザクション時間は可能な限り短く
→ アプリ側に検出の仕掛けをいれている
→ MySlowTranCaptureなどのツールを活用
ロックが多くかかるテーブルは細かく分ける
→ ⾏ロックをかけるので、2つのポイントを同時に更新できない
→ ポイント系のテーブルなどで陥りがちな罠
user_point_tbl user_energy_point_tbl user_battle_point_tbl
× ・user_id ○ ・user_id ・user_id
・energy_point ・energy_point ・battle_point
・battle_point