hamano · October 3, 2011 12:40
diff --git a/tuningathon2_memo.txt b/tuningathon2_memo.txt
 # 第2回 Tuningathon チューニングメモ

 このメモは @hamano が [第2回 Tuningathon][1] に参加した際に行ったチュー
 ニングポイントと感想です。

 [1]: http://www.zusaar.com/event/agZ6dXNhYXJyDQsSBUV2ZW50GLmFBgw "第2弾！いろいろチューニングしてパフォーマンスを競うバトルイベント開催！「Tuningathon」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][2] と、
 ファイルシステム上にキャッシュする [mod_disk_cache][3] というapache
 moduleがあります。mod_disk_cache ですべてのページは載らないにしてもある
 程度の高速化が見込めるのではないかというチューニングの一節として考えて
 いました。

 [2]: http://httpd.apache.org/docs/2.2/ja/mod/mod_mem_cache.html
 [3]: http://httpd.apache.org/docs/2.2/ja/mod/mod_disk_cache.html

 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][4] を利用して回避する
 ことが出来ました。

        Header unset Cache-Control

 [4]: http://httpd.apache.org/docs/2.2/ja/mod/mod_headers.html

 キャッシュを温めているうちに多くの 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][5] の出番です。これを利用して1つのURLリストに平行
 アクセスする処理をプログラムを書かず即座に開始する事が出来ました。
 以下はURLリストを読み込んで平行アクセスする One Liner です。

    % parallel -j 10 'curl -s {} >/dev/null' < urls.txt
    # -j が平行数

 [5]: http://www.gnu.org/software/parallel/ "GNU Parallel"

 反省点は、最後にファイルシステム上のキャッシュを2台目にコピーし、2台構
 成にしようとしたのですが、1台目で集めたキャッシュを2台目で利用すること
 が出来ませんでした。これは、キャッシュのキーがFQDNを含めたURLを元にして
 いる事が原因だと解りましたが、mod_disk_cache の修正やキャッシュを集め直
 す時間が無く最終的に1台構成で計測に挑む事になってしまいました。

 結果、優勝が解ったときは本当に嬉しかったです。今回は各自で定量的に計測
 を行う手段が用意されていなかった為、発表の最後までドキムネでした。

 最後に、楽しいイベントを企画してくださった VOYAGE GROUPさん、スポンサー
 のAmazonさん、技評さん、ありがとうございました。またの開催を楽しみにし
 ています。

 最後の最後に、今回 MediaWiki の遅さにウンザリしてしまった人には拙作
 [mod_wiki][6] がオススメです。是非使ってみてね。

 [6]: http://wiki.cuspy.org/mod_wiki "俺の考えた最高のWikiシステム - mod_wiki"

 ## 参加者の皆さんのレポート
 - http://b.hatena.ne.jp/kluklu/tuningathon/

 --
 Tsukasa Hamano
 http://twitter.com/hamano
	# 第2回 Tuningathon チューニングメモ

	このメモは @hamano が [第2回 Tuningathon][1] に参加した際に行ったチュー
	ニングポイントと感想です。

	[1]: http://www.zusaar.com/event/agZ6dXNhYXJyDQsSBUV2ZW50GLmFBgw "第2弾！いろいろチューニングしてパフォーマンスを競うバトルイベント開催！「Tuningathon」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][2] と、
	ファイルシステム上にキャッシュする [mod_disk_cache][3] というapache
	moduleがあります。mod_disk_cache ですべてのページは載らないにしてもある
	程度の高速化が見込めるのではないかというチューニングの一節として考えて
	いました。

	[2]: http://httpd.apache.org/docs/2.2/ja/mod/mod_mem_cache.html
	[3]: http://httpd.apache.org/docs/2.2/ja/mod/mod_disk_cache.html

	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][4] を利用して回避する
	ことが出来ました。

	Header unset Cache-Control

	[4]: http://httpd.apache.org/docs/2.2/ja/mod/mod_headers.html

	キャッシュを温めているうちに多くの 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][5] の出番です。これを利用して1つのURLリストに平行
	アクセスする処理をプログラムを書かず即座に開始する事が出来ました。
	以下はURLリストを読み込んで平行アクセスする One Liner です。

	% parallel -j 10 'curl -s {} >/dev/null' < urls.txt
	# -j が平行数

	[5]: http://www.gnu.org/software/parallel/ "GNU Parallel"

	反省点は、最後にファイルシステム上のキャッシュを2台目にコピーし、2台構
	成にしようとしたのですが、1台目で集めたキャッシュを2台目で利用すること
	が出来ませんでした。これは、キャッシュのキーがFQDNを含めたURLを元にして
	いる事が原因だと解りましたが、mod_disk_cache の修正やキャッシュを集め直
	す時間が無く最終的に1台構成で計測に挑む事になってしまいました。

	結果、優勝が解ったときは本当に嬉しかったです。今回は各自で定量的に計測
	を行う手段が用意されていなかった為、発表の最後までドキムネでした。

	最後に、楽しいイベントを企画してくださった VOYAGE GROUPさん、スポンサー
	のAmazonさん、技評さん、ありがとうございました。またの開催を楽しみにし
	ています。

	最後の最後に、今回 MediaWiki の遅さにウンザリしてしまった人には拙作
	[mod_wiki][6] がオススメです。是非使ってみてね。

	[6]: http://wiki.cuspy.org/mod_wiki "俺の考えた最高のWikiシステム - mod_wiki"

	## 参加者の皆さんのレポート
	- http://b.hatena.ne.jp/kluklu/tuningathon/

	--
	Tsukasa Hamano
	http://twitter.com/hamano