レポート

みんなでバリバリチューニング!第2回チューニンガソン開催

この記事を読むのに必要な時間:およそ 3 分

結果発表

5時間のチューニングは長いようで短く,さまざまな手法が選択できるようでそうでもなく,前回と同じような「もう少しあれば」感でタイムアップしました。計測の間,しばしの歓談をおいて,いよいよ結果発表です。

優勝はhamanoさん。3.7リクエスト/秒という驚くべき数字を叩き出しました。この秘密はほかの参加者とは違ったチューニング手法にありました(詳しくはこの後⁠⁠。

優勝したhamanoさん

優勝したhamanoさん

準優勝には,前回チャンピオンのmethaneさんがさすがの貫禄を見せました。

前回覇者,今回2位となったmethaneさん

前回覇者,今回2位となったmethaneさん

3位のkarakaniさん(顔出しNG)までが3.5を超える高スコア!

3位のkarakaniさん(顔出しNG)までが3.5を超える高スコア!

以下,トップ10の順位は表のとおりです。約40組の参加者のうち4分の一が2.0を超え,トップ3は3.5を超えるという予想外の好成績となりました。

成績発表では10位から順に紹介され,それぞれがどのような手法でチューニングしたかを自らコメントしました。主なチューニングのポイントをまとめてみましょう

 IDスコア(リクエスト/秒)備考
1位hamano3.73128 
2位methane3.62312前回チャンピオン
3位karakani3.51609 
4位jbking3.25615 
5位netmarkjp3.17339 
6位haruta_makoto3.07282 
7位masudaK, mikedaペア2.95559 
8位Kazuho Oku2.32911 
9位n0ts, xcirペア2.04679 
10位ijin2.04330 

チューニング手法1:PHP

今回のお題では,Webの三層モデルのうちアプリケーションの負荷が大きな課題でした。まずMediaWiki自体が重いわけですが,アプリそのものに手を入れることは今回の禁則事項です。となるとチューニングターゲットになるのはPHPです。

対策としては,まずベータ版のPHP 5.4に入れ替えます。あわせて中間コードをキャッシュするアクセラレータ「APC(Alternative PHP Cache⁠⁠」をインストールします。この手法は前回のチューニンガソンで有効だったため,今回は多くのひとがが取り組んだようです。

さらに,MediaWikiのマニュアルにPerformance tuningのページがあり,mbstringをオフにするなどが記載されています。10位のijinさんのコメントで紹介されると,会場から「そんなページあったんだ!?」という声も上がっていましたが,使用するアプリケーションのマニュアルをチェックすることはチューニングにも有用ということでしょうか(3位のkarakaniさんも言及⁠⁠。

そんな中,2位のmethaneさんが紹介したPHPのビルドオプションが注目を集めました。コメントによると「PHPは,VMの命令ディスパッチをビルドオプションで変更できるんです。デフォルトは関数ポインタテーブルなんですが,これを⁠computed goto⁠に変えると若干速くなります」とのこと。詳細は本業の開発者ブログにphpを高速化するcomputed gotoとして紹介済みだそうです。

チューニング手法2:MySQL

データベース層であるMySQLでは,それぞれにさまざまなチューニングがされていたようです。コメントから拾ってみると次のような手法がありました。

Percona Serverを導入(10位のijinさん) ・InnoDB pluginの導入(9位:n0tsさんとxcirさんのペア) ・バッファプールを増やす(7位:masudaKさんとmikedaさんのペア) ・クエリキャッシュを増やす(3位のkarakaniさん)

さらにDB自体をPostgreSQLに入れ替えようと試みたチームもありましたが,MediaWikiのインストールディレクトリ以下は改変禁止というレギュレーションに縛られて設定ファイルが変更できず,実現できませんでした。また,methaneさんはPHP高速化のためにGree Fast Processorの導入も検討したそうですが,これも同ルールによってできませんでした。

一方で,2台のサーバで役割を分担した構成にすることは事前のルール説明でOKとされていましたが,そのためには同じく設定ファイルを書き換えなければならず,この矛盾した扱いをめぐっては最終的に残り2時間という時点で「LocalSettings.phpの$wgDBserverのみ変更可とする」というレギュレーションで決着をみました。

チューニングを競技とする際に公平性を担保するレギュレーションの難しさが課題として残ったと言えるでしょう。

チューニング手法3:Apache

Webサーバ層では,5時間でできることはあまりないと判断されたのか手を加えた参加者は少なかったようですが,1位に輝いたhamanoさんはApacheでコンテンツのキャッシュにチャレンジし,見事に成果を上げました。

アプリケーションが重いわけですから,アプリケーションに仕事をさせず,Webサーバのみで処理を完了できれば大幅な高速化が期待できます。しかし,今回はデータが150万項目のWikipediaで,そのうち100項目だけが計測されるというルールのため,中途半端にキャシュを作成してもまったくヒットしない可能性もあります。

このあたりをhamanoさんは次のように考えました。Apacheのmod_disk_cacheモジュールを使って,キャッシュがどれくらいのるか見積もったところ,ディスクには全部乗らないんじゃないかと予想されました。ですが,削除されたページもたくさん含まれていることに気づいたので,有効なページだけを見つけ出してキャッシュすることにしました⁠⁠。

さらに,⁠キャッシュを集めまくるために,クライアントをGNU Parallelを使って並行に走らせるということに14時ごろに気がついて,間に合いました」ともコメントしていました。詳細は,ご自身が第2回 Tuningathon チューニングメモで公開されています。

おそらく競技時間がさらに長ければ,キャッシュを作成するチームも他にあったことでしょう。そこを5時間という短期間で挑戦し,効果をあげられる手法を考えだしたhamanoさんのジャッジメントは,時間的な制約が課せられるトラブルシューティングに直面しがちなインフラエンジニアにとって必要な技術のひとつといえるのかもしれません。成果発表でも大きな拍手を浴びていました。

まとめ

最後に主催の山崎氏は,今回の結果に対して「2.0を超えればかなり上位かなと思っていたんですけど,それより上に行っているような状況で,予想以上に結果が良くて驚きました」と参加者チューニング力に舌を巻いていました。

また,今後については「3ヵ月に1回くらいは開催していきたいし,内容も1ヵ月半前には発表できるようにしたい。前回に続いて今回もPHPというのは非常に心苦しいのですが,できるだけ一般的に使われていて,普通にOSSとして流通しているアプリケーションを探したためです。どんなアプリケーションをチューニングしたいかも随時募集しますので,ぜひ意見をいただければとおもいます」と語りました。

大会のあとは懇親会がありました。アルコールも入れながら,今回の振り返りや結果についての議論,チューニングのポイントやインフラ技術に関する熱い思いを語りながら,長いチューニングの一日は暮れていきました。

お互いの健闘を讃え合い,情報を交換し,盛り上がった懇親会

お互いの健闘を讃え合い,情報を交換し,盛り上がった懇親会

お互いの健闘を讃え合い,情報を交換し,盛り上がった懇親会

当日の様子は,ゼロスタートの広報ブログにも「⁠⁠レポート】第2弾!いろいろチューニングしてパフォーマンスを競うバトルイベント!Tuningathon2として詳しく紹介されてみますので,合わせてご覧になると当日の雰囲気がよくわかるでしょう。