ここから転載(このメモを書いた頃はgistをブログにしてた) https://gist.github.com/1259011
このメモは @hamano が 第2回 Tuningathon に参加した際に行ったチューニングポイントと感想です。
今回のお題は MediaWiki への参照性能という事でまたPHPか! とは思いましたが2台構成可、Web Serverの入れ替え可、という条件でしたのでチューニングの範囲が大きく広がった様に感じました。
ただ、この程度の平行数ではapacheをその他実装に置き換えた所で大した差は出ないだろうと考え、ひとまずApache HTTPD Server 2.2.21 + PHP 5.4 + APCをビルドしました。
http_load もビルドして計測環境が整った所で最初に悩んだ事は、単一ページリクエストをabで行うと容易に 7-8 req/sec を越えるのに対し、http_loadではどうしても 1 req/sec以下になってしまい、何処もボトルネックになっていないという状況でした。
原因はバトル条件に書かれていた http_load の –rate 1 による制限であることに気がつきましたが、皆にも同じように悩んでほしかったので黙っていました。(その後、計測条件は –parallel 4 に変更されました。)
しかし、page.txt から生成したURLリストでランダムにアクセスしてみると、ひどいありさまです。2 req/sec程度しか出ません。原因はPHPの遅さにある事が解ったのでPHPを迂回する事の検討を始めました。
apache にはコンテンツをメモリ上にキャッシュする mod_mem_cache と、ファイルシステム上にキャッシュする mod_disk_cache というapache moduleがあります。mod_disk_cache ですべてのページは載らないにしてもある程度の高速化が見込めるのではないかというチューニングの一節として考えていました。
mod_disk_cache の設定は以下の通りです。
CacheDefaultExpire 86400
CacheMaxExpire 86400
CacheIgnoreCacheControl On
CacheIgnoreNoLastMod On
CacheEnable disk
CacheRoot /var/www/cache
ただし、この設定だけでは MediaWiki のレスポンスをキャッシュすることは出来ませんでした、CacheIgnoreCacheControl On を設定しているにもかかわらず、MediaWikiが付与する Cache-Control ヘッダが機能し、キャッシュ出来ません。この問題は、同じく apache module の mod_headers を利用して回避することが出来ました。
Header unset Cache-Control
キャッシュを温めているうちに多くの URLで 404 や 301 のレスポンスコードが返ってくることに気がつきました。page.txt を眺めているとDBには削除されたページも含んでおり、正確な数字は覚えていませんが、有効なページは100万件程度である事が解りました。
追記: page.txt の2列目はネームスペースで「会話ページ」や「ユーザーページ」が含まれていたみたい。[Defines.php][7] のNS_MAIN以外の定義を参照 [7]: http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/Defines.php?view=markup
ディスクの空き容量から10%程度のキャッシュを保存できると試算し、その後は制限時間内で如何にしてキャッシュを多く集めるかという課題に注力しました。問題は時間が足りない事でした。シリアルにアクセスすると 1 req/sec程度しか出ない為、制限時間内にはとても終わりません。
そこで GNU Parallel の出番です。これを利用して1つのURLリストに平行アクセスする処理をプログラムを書かず即座に開始する事が出来ました。以下はURLリストを読み込んで平行アクセスする One Liner です。
% parallel -j 10 'curl -s {} >/dev/null' < urls.txt
# -j が平行数
反省点は、最後にファイルシステム上のキャッシュを2台目にコピーし、2台構成にしようとしたのですが、1台目で集めたキャッシュを2台目で利用することが出来ませんでした。これは、キャッシュのキーがFQDNを含めたURLを元にしている事が原因だと解りましたが、mod_disk_cache の修正やキャッシュを集め直す時間が無く最終的に1台構成で計測に挑む事になってしまいました。
結果、優勝が解ったときは本当に嬉しかったです。今回は各自で定量的に計測を行う手段が用意されていなかった為、発表の最後までドキムネでした。
最後に、楽しいイベントを企画してくださった VOYAGE GROUPさん、スポンサーのAmazonさん、技評さん、ありがとうございました。またの開催を楽しみにしています。
最後の最後に、今回 MediaWiki の遅さにウンザリしてしまった人には拙作mod_wiki がオススメです。是非使ってみてね。