第一回は参加者としてチューニングに挑みましたが、他の人にもどんどん参加して欲しいので、自分が参加枠を埋めてしまわないよう、お手伝いということで関わりました。
チューニンガソンはインフラエンジニアに焦点をあてているようで、アプリ自体の改造はなし、ミドルウェアやOSのチューニングをしよう、というイベントです。
今回のテーマは「Mediawiki」でした。
あのWikipediaで使用されているソフトウェアです。
サーバはAWSのミディアム2台。
データベースにはWikipedia日本語版の内容が入っており、DB自体は11GBくらいでした。
サーバのメモリが1.7GBなので、DBはメモリに乗りきらず、ページが読まれるとそれなりのIOが発生しています。また、PHP自体も重いのでCPUもガンガン使います。
1位の人は、ページをディスクキャッシュしてApacheから直接返す、ということをやって優勝でした。
全体的な傾向としては、IOをどうにかするのは時間内には出来なかったので、PHP周りのチューニングをした人が上位入賞という感じでした。
計測のルールがMySQLに不利だったので、このへんは次回に向けた検討事項だと思います。
InnodbでDB圧縮したらどうなるか、というのは誰かやらなかったですかね?
最終計測は
・サーバは再起動する
・Mediawikiのキャッシュはクリアする
という条件でしたが、参加者にキャッシュのクリアを含めたベンチマークツールが配布されていませんでしたので、参加者は自分でキャッシュのクリアをする必要がありました。
このためキャッシュをクリアせずにチューニングしていて、自分の計測と最終計測に乖離があった方もいらっしゃったようです。
これは、最終計測と同等のベンチマークを用意すべきだったと思います。
(URLは配布用と最終計測用で別にしておきつつ)
さて、僕は会場のテーブルと椅子の準備や片付けをしたくらいで、あまり手伝いとかはなかったのですが、参加者がチューニングをしている間にチート検出用のスクリプトを書いてました。
チート検出では、運営用のMediawikiと同じキーワードのページを参加者側のサーバから取ってきて
・Content-Lengthがほぼ同じかどうか
・ページ名の単語がページ中に含まれるかどうか
・Mediawiki固有の文字列がページ中に含まれるかどうか
というものをチェックしました。
ソースコード:
https://gist.github.com/1258672
とりあえず、上記のスクリプトではチート検出ゼロでした。
もしロードバランサを使って、自前の別サーバや他の参加者のサーバにリクエストを振り分けていた場合は、上記スクリプトでは検出できませんので、その方面のチートは可能でした。
(ただしスコアが想定以上だったら手作業でチェックする予定でしたが)
なお、次回のお題に関しては、みなさんからのリクエストを募集中だそうなので、リクエストがある方は、ゼロスタさんのブログ記事にコメントするか、Twitterで #tuningathon タグでつぶやくと運営に届くと思います。
また、ほんの少しだけですがお手伝いして思ったのは、競技系イベントの運営は本当に大変だということでした。
今後も、何らかの形でお手伝いできればと思います。
それと、Google App Engineでも競技系のイベントをやってみたいなと思いました。
アプリの要件をお題として、要件を満たすアプリを作ってもらってパフォーマンスを競う、みたいな。と書いてて思いましたが、負荷かけるとスケールアウトしちゃうので難しいですね……。
0 件のコメント:
コメントを投稿