第2回 Tuningathonへ行って来ました。

1ヶ月に1回しかブログ書いてないカニです。先週の土曜日、第2回 Tuningathonが開催され行ってきました。結果、上位3位だったようですが未だに何が決定打になっているのかわからず悩んでいます。

アプリケーションはMediaWikiにWikipediaのコンテンツを導入してあるといういわばWikipediaのミラー的なものです。データ件数は数百万件オーダー。一方で、テストに使用されるURLは同時並列4アクセスで合計100回のアクセスです。URLは各単語に対する記事でランダムに抽出されます。コンテンツの更新はありません。

ルールと自分がとった戦略

戦略と書いたのですが、実は特に戦略と呼べるものもなく… 簡単に考えていたのはこんな事です。

• フロントエンド側のキャッシュは多分できない。百万件のキャッシュとか無理だと思うので考えない。（Wikipediaが快適に表示されているのはキャッシュサーバーのおかげ）
• アプリケーションは実績があるので、例えばDBに変なクエリを投げてたりしてるということもなさそう。
• MediaWikiは重い（という印象があったし、実際重かった）。なのでMediaWikiの公式サイトにチューニングパラメータとか載ってるはず！
• (topで負荷状況を測った結果、)重いのはphp。MySQLにはさほど負荷は掛かってない。

ということです。優先順位的には、

1. phpを軽くしたい
2. DBを軽くしたい
3. Webサーバーを軽くしたい

という順番でした。

実際にやったこと

やったこと一覧です。おおよそ次の順番で作業しています。

• 負荷環境を作るためにhttp_loadのコンパイルとpages.txtからURL一覧の生成
• php 5.4の導入(MediaWikiのサイトのConfigurationでコンパイル)
• APCの導入(Peclから導入)
• MySQLにクエリキャッシュを導入
• NginxとFastCGIの導入(うまく動作せず未検証)

まずhttp_loadのコンパイルとテスト用のURLの生成を使用としたのですが、結構時間かかりました。1時間弱は時間がかかってるような気がします。が、これが無いとパフォーマンスの比較ができないのでがんばりました。

php 5.4ですが、MediaWikiは重いスクリプトです。そのため本気で運用する場合にはそれ専用でサーバーを導入すると思います。とすると公式サイトにconfigureオプションが掲載されているものです。そのURLがこちら。

http://www.mediawiki.org/wiki/PHP_configuration/ja

一つ一つ調べる余裕がなかったのですが、デフォルトで有効になっているモジュールを無効にするともう少しは軽くなるのかもしれません。APCなどのアクセラレータの導入は定石かと思います。他にもチューニングポイントがあったようですが、気づきませんでした。

MySQLのクエリについては同じSQLを何度も呼び出していたためクエリキャッシュが有効だろうと思いクエリキャッシュを有効化しています。但し、topの負荷状況を見てもMySQLよりphpの負荷のほうが深刻だったのでMySQLのバージョンアップでの高速下は考えていませんでした。

ここまで来た段階で既に制限時間もほぼ尽きてました。

もっとphpを早くしたいといつものfastcgi + nginxの導入も試みましたが、MediaWikiが生成するコンテンツ内のリンクのURLが変わってしまう問題に遭遇したためパフォーマンスの検証は行えていませんでした。（但し、後述しますがそもそもmod_phpよりもFastCGIの方が早いという根拠は無いです）

ISUCON と Tuningathon

ところで、先月、ライブドアさんのISUCONに行った時との違いが面白かったです。

参加者の属性自体が結構違っていて、

ISUCON — Webアプリケーションエンジニアが多い（Mac率高い！）
Tuningathon — インフラ系エンジニアが多い(Mac率そんなに高くない！)

という印象でした。それぞれのイベントの目標が違うのでそうだと思います。（なので、自分がTuningathonに本当に参加して大丈夫かな、とびびってました）

チューニングの視点も結構違っている印象があって、比較的多くの方が「キャッシュ」を取りに行こうとしていたのが印象的でした。

自分は今回のイベントでは「キャッシュは無理」と割り切っていました。このあたりはキャッシュに対する「待ちの姿勢」と「攻めの姿勢」があって面白いです。アプリエンジニアは「待ちの姿勢」、インフラ系エンジニアは「攻めの姿勢」だったりするんじゃないかと思います。偏見ですが。

多くの方がApacheのままでNginxを試されたりしてなかったのも印象的でした。ISUCONでは元々FastCGIアプリが稼働していたのでNginxを利用される方が多かったです。今回はphpアプリでしたので、FastCGIよりもmod_phpの方が早いかもしれません。

自分は闇雲にNginxを試そうとしてたタイプの人間です。その点、インフラ系エンジニアって冷静だなと思いました。これも偏見ですが。

 

最後ではありますが、主催していただいたZero Start様、スポンサーのAmazon様、技評様、場所を提供いただいたVOYAGE GROUP様どうもありがとうございました。楽しかったです。