LAMPで作るソーシャルアプリの負荷対策 [プログラミング]
http://www.contents-one.co.jp/social/2010/05/post-3.php
聞いてきた。前に行った→ http://nakagami.blog.so-net.ne.jp/2010-07-01 のと同じ感じだったけど、今回 PHP だったせいか、タイトルがぐっとくる感じだったのか前回よりやや盛況な感じがした。
また、前回は営業っぽいひともいた気がするけど今回は SAP のエンジニアとか多めな感じ。
書き漏らしもあるけど、忘れないうちにメモを転記
Cake PHP, symphony カスタマイズして使っている
ソーシャルアプリのインフラに求められること
・サーバーの追加/削除が容易なこと
・モニタリングが充実していること
DSAS の SAP 向けインフラもご提供中(ちょっと宣伝)
LVM + Apache 2.2 + PHP 5.2 + MySQL 5.1 + memcached
・Web サーバー メモリ8G で他は普通
・DB サーバー 8 core /メモリ64G SAS 146Gx8 のRAID5
MySQL のメモリキャッシュに 20G とか割り当ててる
・MySQL はシングルマスタマルチスレーブ
・ガングリアをカスタマイズしてモニタリング
インフラのチューニングだけじゃなくてアプリの対策が必要
負荷とは→ HTTP リクエストがたまっちゃうこと
DB チューンングで気をつけること
・レコード長を短く(int -> tinyint もバカにならない)
・不要なレコードは削除して select 時の負荷を下げる
・必要なインデックスのみ作成し、アプリで使わないインデックスは張らない
アプリの発行するクエリで気をつけること
・インデックスを使用しない SQL は発行しない
・不要な JOIN をしない
・結果セットはできるだけ小さく(limit 指定するとかする)
select はスレーブDBに逃がす
・昨日のランキング等
画像のパフォーマンスチューニングについて
・恋してキャバ嬢では画像の合成がボトルネックになっていることが判明
・恋してキャバ嬢では GD を他アプリでは ImageMagic をカスタマイズ
・GD ライブラリのチューニングで、画像はキャッシュしなくても良くなった
GD や ImageMagic のチューニングってファイルの読み込みとか不必要なメモリ内コピーとか、そんな感じらしい。やっぱ I/O がボトルネック。
そのほか、ふーんって思ったのは
・恋キャバ mixi でのスタート時数十台レベルでサーバー用意したけどダメだった
今は、チューニングが進んでるので数台でこなせるレベルなのに
・OpenSocail の API 呼んでるときとか画像合成してるときとか、必要なければ DB の接続を切ってる
・質疑応答の Gree の人によると Gree でも ImageMagic のチューニングはしてて
「ソース公開しないんですか?」との質問に、DSAS の人が「検討中」と回答
とりあえず、DSAS のインフラを使う SAP に提供しようか、とかそういう話らしい
というあたり
同じ問題(負荷対策)を違うアプローチでしてる人たちの話を聞くのは面白い。
一見、スレーブ構成がとれる KLab のほうが負荷対策楽そうに見れるけど、 gumi は update の負荷を TokyoTyrant に逃がすというアプローチを取っているのに対して、 KLab は、 update の負荷を下げるのが大変そうな気がする今日この頃。
(追記)
http://lab.klab.org/young/2010/07/%e3%80%90lamp%e3%81%a7%e4%bd%9c%e3%82%8b%e3%82%bd%e3%83%bc%e3%82%b7%e3%83%a3%e3%83%ab%e3%82%a2%e3%83%97%e3%83%aa%e3%81%ae%e8%b2%a0%e8%8d%b7%e5%af%be%e7%ad%96-%ef%bd%9e%e3%82%a2%e3%83%97%e3%83%aa/
聞いてきた。前に行った→ http://nakagami.blog.so-net.ne.jp/2010-07-01 のと同じ感じだったけど、今回 PHP だったせいか、タイトルがぐっとくる感じだったのか前回よりやや盛況な感じがした。
また、前回は営業っぽいひともいた気がするけど今回は SAP のエンジニアとか多めな感じ。
書き漏らしもあるけど、忘れないうちにメモを転記
Cake PHP, symphony カスタマイズして使っている
ソーシャルアプリのインフラに求められること
・サーバーの追加/削除が容易なこと
・モニタリングが充実していること
DSAS の SAP 向けインフラもご提供中(ちょっと宣伝)
LVM + Apache 2.2 + PHP 5.2 + MySQL 5.1 + memcached
・Web サーバー メモリ8G で他は普通
・DB サーバー 8 core /メモリ64G SAS 146Gx8 のRAID5
MySQL のメモリキャッシュに 20G とか割り当ててる
・MySQL はシングルマスタマルチスレーブ
・ガングリアをカスタマイズしてモニタリング
インフラのチューニングだけじゃなくてアプリの対策が必要
負荷とは→ HTTP リクエストがたまっちゃうこと
DB チューンングで気をつけること
・レコード長を短く(int -> tinyint もバカにならない)
・不要なレコードは削除して select 時の負荷を下げる
・必要なインデックスのみ作成し、アプリで使わないインデックスは張らない
アプリの発行するクエリで気をつけること
・インデックスを使用しない SQL は発行しない
・不要な JOIN をしない
・結果セットはできるだけ小さく(limit 指定するとかする)
select はスレーブDBに逃がす
・昨日のランキング等
画像のパフォーマンスチューニングについて
・恋してキャバ嬢では画像の合成がボトルネックになっていることが判明
・恋してキャバ嬢では GD を他アプリでは ImageMagic をカスタマイズ
・GD ライブラリのチューニングで、画像はキャッシュしなくても良くなった
GD や ImageMagic のチューニングってファイルの読み込みとか不必要なメモリ内コピーとか、そんな感じらしい。やっぱ I/O がボトルネック。
そのほか、ふーんって思ったのは
・恋キャバ mixi でのスタート時数十台レベルでサーバー用意したけどダメだった
今は、チューニングが進んでるので数台でこなせるレベルなのに
・OpenSocail の API 呼んでるときとか画像合成してるときとか、必要なければ DB の接続を切ってる
・質疑応答の Gree の人によると Gree でも ImageMagic のチューニングはしてて
「ソース公開しないんですか?」との質問に、DSAS の人が「検討中」と回答
とりあえず、DSAS のインフラを使う SAP に提供しようか、とかそういう話らしい
というあたり
同じ問題(負荷対策)を違うアプローチでしてる人たちの話を聞くのは面白い。
一見、スレーブ構成がとれる KLab のほうが負荷対策楽そうに見れるけど、 gumi は update の負荷を TokyoTyrant に逃がすというアプローチを取っているのに対して、 KLab は、 update の負荷を下げるのが大変そうな気がする今日この頃。
(追記)
http://lab.klab.org/young/2010/07/%e3%80%90lamp%e3%81%a7%e4%bd%9c%e3%82%8b%e3%82%bd%e3%83%bc%e3%82%b7%e3%83%a3%e3%83%ab%e3%82%a2%e3%83%97%e3%83%aa%e3%81%ae%e8%b2%a0%e8%8d%b7%e5%af%be%e7%ad%96-%ef%bd%9e%e3%82%a2%e3%83%97%e3%83%aa/
コメント 0