開催内容は、ISUCON夏期講習のAMIで黙々とチューニング!
前回参加したチューニンガソンとの違いは、APの改修がOKなこと。
13:00から開始で、まずは自己紹介と前回のISUCONに参加された方から、
ISUCONの概要の説明の後、2チームに別れてチューニングを開始。
3人チームで分担を、OS、DB、APと分けて、黙々とチューニングしました。
私はAPはよく分からないので、詳しそうな方におまかせして^^;
DBのチューニング担当になりました。
MySQLは前回のチューニンガソンで1度触っただけですが、
その時の知識を思い出しながら、作業開始。
APはチケット販売サイトで、その性能を競います。
最初に素の状態でベンチマークを実行すると、以下のようになりました。
606 tickets
score:811084
ticketsの値は大きい方が、scoreの値は小さい方が高得点だそうです。
まずは、というかほとんどこれしかやってないんですが、
MySQLTunerを使って計測開始。これは前回のチューニンガソンで
仕入れた知識。
MySQLTunerに言われるがままに、cacheやbufferの値を設定。
それから、slowlogに出てくるqueryをexplainで確認して、
indexを貼ってみたけど、indexはよく理解できていないので、
本番までに勉強しておきます。
最終的に設定した値は、以下のとおり。
query_cache_size = 512M
query_cache_type = 1
query_cache_limit = 8M
table_cache = 256
join_buffer_size = 256
thread_cache_size = 256M
#slow_query_log
#long_query_time = 0.1
indexは忘れましたw
OS担当とAP担当の方も色々調整をされて、最終的なベンチマーク結果は、、、
1161 tickets
score:423350
約2倍のチケットをさばけるようになってました。
優勝チームは
今回は、OS、DB、APと思い思いに黙々とチューニングしたので、
どこの改修が効いたのか解らず・・・
本番では最初の方針と、途中経過を確認しながら進めた方が良さそう。
最後にチーム毎にチューニング内容を発表して、お開きとなりました。
仕事だとApache、Tomcatが多いので、
お進めのAPサーバなど、色々知らない事が聞けて参考になりました。
ISUCONに参加された方の話だと、インフラ周りのチューニングよりも
APのプログラム改修の方が効果が高いようです。
インフラ担当としてはAPを触らずにどこまでチューニング可能かが
興味のあるところです。
長い割に、内容が無いですがこんなところで。
0 件のコメント:
コメントを投稿