12/23日付でW3TCの新版が出ています。すぐにインストールしましたが、今回は小幅な修正だけのリリースです。WEB UIで設定可能な項目が増えたりフレデリックさんが頑張ってくれてます。

とりあえず、現在この0.8.5.1リリースをベースに日本語化を試みています。現状では、WEB UI部分の日本語化にとりかかって何ページかの翻訳が終わっています。WEB UIはphtmlなので、実は結構簡単に日本語化できますね。エラーメッセージとか一部はgettext使って、その他大部分はphtmlだけで行けそうです。親戚で容態が思わしくない人がいるので、場合によっては葬儀とかになりそうで、しばらくは忙しいです。

ここ数日、W3TCの作者のフレデリックさんとメールのやり取りをしています。現状で、日本向けに必要そうなMobile User Agentの追加を、打診したところ。次回バージョンアップ時に反映しますとのことでお返事を頂きました。

追加されるのは、J-PHONE, WILLCOME, DDIPOCKET, PDXGW, emobile.などです。ketai styleのサポート範囲などを考えるともう少し増やしても良いかとも考えましたが、現状でも、DoCoMo、KDDI、SoftBankのUAは存在しますから、WILLCOME関連とemobileが加われば十分だと考えます。その他は、ゲーム機用のブラウザやエミュレータで実用上は大きな必然性もないし、使いたければ自分でも追加できますしね。

また、次回もしくは、その次のリリースになるかと思いますが、とりあえず当サイトで日本語化してみませんか？とフレデリックさんから打診もいただいたので、gettextでPO作ったりからはじめなければなりませんが。来月はある程度は、時間がさけるのでテスト版程度はリリースしたいと考えています。

12月3日にリリースされてたけど忙しくて、バージョンアップが遅れました。

前バージョンとの大きな差異はGUIがかなり整理され、容易に設定を行えるようになった点です。特に前バージョンでは、w3-total-cache-config.phpを手動で編集し、pgcache.mobile.checkをtrueにするなどしなければ携帯電話対応を行うことは出来ませんでしたが、今回の0.8.5からはGUI上から設定可能になり、さらに携帯端末のユーザーエージェント登録などもGUI上で設定可能になりました。

W3TC 0.8.5でデフォルトで登録されている携帯端末UA

‘Android’,
‘2.0 MMP’,
‘240×320′,
‘AvantGo’,
‘BlackBerry’,
‘Blazer’,
‘Cellphone’,
‘Danger’,
‘DoCoMo’,
‘Elaine/3.0′,
‘EudoraWeb’,
‘hiptop’,
‘IEMobile’,
‘iPhone’,
‘iPod’,
‘KYOCERA/WX310K’,
‘LG/U990′,
‘MIDP-2.0′,
‘MMEF20′,
‘MOT-V’,
‘NetFront’,
‘Newt’,
‘Nintendo Wii’,
‘Nitro’,
‘Nokia’,
‘Opera Mini’,
‘Palm’,
‘Playstation Portable’,
‘portalmmm’,
‘Proxinet’,
‘ProxiNet’,
‘SHARP-TQ-GX10′,
‘Small’,
‘SonyEricsson’,
‘Symbian OS’,
‘SymbianOS’,
‘TS21i-10′,
‘UP.Browser’,
‘UP.Link’,
‘Windows CE’,
‘WinWAP’,
‘Ericsson’,
‘htc’,
‘Huawei’,
‘MobilePhone’,
‘Motorola’,
‘nokia’,
‘Novarra’,
‘O2′,
‘Samsung’,
‘Sanyo’,
‘Smartphone’,
‘Symbian’,
‘Toshiba’,
‘Treo’,
‘vodafone’,
‘Xda’,
‘Alcatel’,
‘Amoi’,
‘ASUS’,
‘Audiovox’,
‘AU-MIC’,
‘BenQ’,
‘Bird’,
‘CDM’,
‘dopod’,
‘Fly’,
‘Haier’,
‘HP.iPAQ’,
‘i-mobile’,
‘KDDI’,
‘KONKA’,
‘KWC’,
‘Lenovo’,
‘LG’,
‘NEWGEN’,
‘Panasonic’,
‘PANTECH’,
‘PG’,
‘Philips’,
‘PPC’,
‘PT’,
‘Qtek’,
‘Sagem’,
‘SCH’,
‘SEC’,
‘Sendo’,
‘SGH’,
‘Sharp’,
‘SIE’,
‘SoftBank’,
‘SPH’,
‘UTS’,
‘Vertu’,
‘Opera.Mobi’,
‘Windows.CE’,
‘ZTE’,

ざっと、眺めても国内の主要なキャリアの設定も含まれています。このままでも大きな問題はないでしょう。設定するならエミュレータ関連のUAや、J-PHONE、WILLCO、イー・モバイル関連などです。ドコモ、KDDI、ソフトバンクなどは含まれているので、とりあえず、WILLCOMとイー・モバイルに関しては次のバージョンアップ時に含めてもらえるよう、作者のFrederickさんに提案してみます。

本日 W3TCの0.85がリリースされました。前のバージョンで少し弄ってる部分があるので、様子を見ながら明日あたりバージョンアップしてみます。

W3 Total Cacheの公式サイト

とりあえず、前の記事で書いたとおり（ソースの修正なしで、pgcache.mobile.checkとpgache.mobile.browsersだけ）で正常に動作しているかのように思えます。自宅からPC、i-mode用ブラウザ、jig browserを携帯から、別回線（mopera U）からPC接続で、キャッシュが混じらず、PC用、携帯用それぞれ表示できました。このポストに携帯からでもPCからでも1行で構わないので、コメントで、正常に見えてるか、異常（キャッシュが混じって異なるデバイス用の表示になるか）調査にご協力ください。よろしくお願いいたします。

memcachedのデータを調べてみると、末尾にdocomoとなったハッシュキーが別に生成されているし、データベースへのクエリもdocomo用と標準のキーで分けられてるし自分が希望している動作をしているように見えます。

twitterで指摘してくださった某有名人様のおかげで、判明しました。タイミングによっては、ktai用のコードをPC向けに吐いたり、PC用のコードを携帯に吐いたりしていました。対策前のwp super cacheと同じような感じです。ただ、W3TCはwp super cacheより少しインテリジェントな作りになってるので、ハッシュキーの作り方とかで対応できないか、ソースを少し読んでるところです。PHPは全くド素人なもんで、アレですけど。W3TCのコード自体は個人的に読みづらいとは感じないです。何とか読めてます。

W3TCのコンフィグファイルの中に、pgcache.mobile.checkとか、pgcache.mobile.whitelist, pgache.mobile.browsersなんてのを発見。ソース中にもあるけど、W3TCの設定画面では表示されない。非公開ファンクション扱い？

function _get_mobile_type()は、まず環境変数 HTTP_USER_AGENTを調べてセットされていればpgcache.mobile.whitelistを検索して、pgcache.mobile.whitelistにあるブラウザと一致すれば通常通りの動作を行う。次に、pgcache.mobile.browsersを検索して、HTTP_USER_AGENTと一致すれば、ブラウザ名を返すfunction _get_page_keyで、pgcache.mobile.checkが真かつ、$mobile_type（_get_mobile_type()の戻り値）が空白でなければ、ページキーを返す。キャッシュの管理はページキー毎にやってるから何とかなるかな？まだほんの少ししかソースを読んでないので、何とも言えない感じだが。

設定ファイルの pgcache.mobile.check をtrueにして、pgcache.mobile.browsersにKtai Styleで言及されてるデータをこんな感じで入れてみた。

‘pgcache.mobile.browsers’ => array(
‘DoCoMo’,
‘J-PHONE’,
‘J-EMULATOR’,
‘Vodafone’,
‘MOT(EMULATOR)’,
‘SoftBank’,
‘[VS]emulator’,
‘KDDI-’,
‘UP.Browser’,
‘emobile’,
‘Huawei’,
‘Nokia’,
‘mixi-mobile-converter’,
‘DDIPOCKET’,
‘WILLCOM’,
‘Opera Mini’,
‘Opera Mobi’,
‘PalmOS’,
‘Windows CE’,
‘PDA; SL-’,
‘PlayStation Portable’,
‘SONY/COM’,
‘Nitro’,
‘Nintendo’,
),

もっともW3TCのソースでは、strstr($_SERVER["HTTP_USER_AGENT"], trim($browser))になってるから、これだとOperaとかは困るかな？trim($browser)で空白取っちゃったら、マッチしないしよね？この場合は、$_SERVER["HTTP_USER_AGENT"]もtrimしないとまずいような気もする。ただ、何度も言うけどPHPはド素人なため悲しいかな、PHPの動作とか関数の仕様が良くわからん。trimは戻り値使わない場合は、即値で使えるだけ？それとも引数の変数自体を変えちゃうとかあるのかな？少しPHPを勉強せねば恐ろしくていじれない

今日は、もう寝るから明日以降少しだけPHPのお勉強しながらW3TCのテストします。

W3 Total Cache（W3TCは）Page Cache、Minify Cache、Detabase CacheにDisk、Memcached、APCなどいくつかの設定ができるので、どの組み合わせが最良か、ab（Apache Bench)を用いてテストを行った結果、実はどれでも大差ない事がわかった。

テスト方法は、このサイトに対して、abを用いて次のコマンドを実行し、Time taken for tests:の値に着目してテストを行った。

ab -n 100 -c 10 http://jinkai.macaro.net

まず、APCを有効にしない、Apche単体でテストを3回行うと、27.144824秒、27.836070秒、27.471900秒と概ね27秒程度を要した。

次に、APCのみを有効にしApacheのテストを3回行うと、20.884433秒、21.294718秒、20.516184秒と概ね20秒～21秒前後となった。

W3TCを有効にし（APCも有効）毎回キャッシュをすべて削除しPage Cache｛Disk, Memcached, APC｝、Minify Cache｛Disk, Memcached, APC｝、Database Cache｛Memcached, APC｝の組み合わせ18通りをテストすると1.8秒～3.9秒程度まで結構数字がばらつくが再現性がなく、どの組み合わせでも大差ない事がわかった。但し、どの組み合わせでもキャッシュをクリアせずにキャッシュが有効になっている状態で再度abコマンド（ab -n 100 -c 10 http://jinkai.macaro.net）を実行すると0.372460秒など殆どの組み合わせで、0.36~0.37秒前後に収束した。つまり、1.8秒～3.9秒の大部分は、キャッシュされている状態でありabで求めたTime taken for tests:の時間のばらつきはキャッシュ作成時の最初の数回分のみでしかなく、何回キャッシュにヒットしたかが微妙にばらつく事で発生していることが判明した。

実際にはどの組み合わせでも大差ないが、Diskを使うとディスクアクセスが発生するデメリット（メモリが多ければ実際にはOSが制御するのでそれほど問題はない）、APCを使うとApache再起動時にキャッシュがクリアされてしまうことを勘案すると、私はすべてMemcachedに設定するのが最も効率的であると考えます。

wp super cache 0.9.7（gzip圧縮あり）+APCでテストしてみると、2.515151秒、2.208088秒、2.630919秒（毎回キャッシュクリア）、キャッシュをクリアせずに同じコマンドを発行すと、0.132580秒、0.121404秒、0.131634秒。単純にトップページのみの圧縮であればW3TCも、wp super cacheのもキャッシュ作成にかかる時間は大差なくキャッシュ済みコンテンツへのアクセスに関しては、wp super cacheの方が、W3TCより3倍近く高速で尚且つサーバ負荷低い。これはwp super cacheの方はmod_rewrite分のオーバーヘッドしかないのに対して、W3TCは条件判断が加わるので当然と言えば当然の結果。

wp super cacheに対して、W3TCが大きくアドバンテージを発揮するのは、データベースへのクエリが何パターンも発生する場合などだと思う。cssやjavascriptの圧縮は、自分でYUM compressorなどを使って実行しておくことも可能なわけで、Pageキャッシュは、wp super cacheの方が速いとなれば、その部分でしか、W3TCのメリットは出てこない（もちろん、W3TCはそれを自動でやってのけるので、そのメリットは大きいが、そんなに頻繁にCSSなどは変更するものではない）。

今回のパフォーマンステストはある意味、W3TCのメリットを全く生かしきれないもっとアクセスパターンが多様で、DBへのクエリに多様性が出るケースなどでテストすれば、W3TCの方が早くなる可能性が高いし、W3TCの方がアーキテクチャ的に伸び代が大きい。W3TCへの期待をこめる意味と、もう少し動作を調べたいので当面、このサイトではW3TCを使用していくことにします。

あと、W3TCの大きなメリットとして、wp super cacheのように完全に静的HTMLに落とし込んで、mod_rewriteでURLを書き換える方式ではないので、ktai styleのようなプラグインとバッティングしません。両方ともキャッシュが効いてるようです。（この部分はまだ詳しくテストしてないです）。(現在テストしていますが、タイミングによってはバッティングするようです、何らかのキャッシュ制御しないとだめかな？調査中です。11/10 追記）wp super cacheとktai styleの組み合わせは、ある意味クイックハック的な処置で実現していますよね。wp super cacheと相性の悪いプラグインもいくつか存在しますし、wp super chacheの静的なhtmlに落とし込んで、mod_rewriteでルーティングするやり方はWordpressの大きなメリットである柔軟性を損なう可能性が高いので、相性の悪いプラグインが出るたびにクイックハックでキャッシュ・ルーティング対象から外したり、場合によっては新しいルーチンを組むなど本質的な対応が面倒。その点、W3TCの方がアルゴリズム的に汎用性が高く、影響のでるラグインが少ないはずです。最初はなんでW3TCが旬なXcacheではなくAPCを採用したか、理解に苦しみましたが、結構その辺は難しい部分で、APCの方がよりシンプルで、Xcacheを使う場合は、phpの変数までキャッシュ可能なので、かなり複雑な制御をしないと色々と破綻しやすいんですね。もちろんその部分を煮詰めればXcacheの方が速いでしょうが、一筋縄ではいかないし、相性問題も発生しやすくなるはずです。

W3TCは非常に良くできています、感心します。素晴らしいプラグインを作ってくださった、Frederickさんに感謝。

memcacheがどうやっても動かないため、本当に丸一日費やしてしまった。悲しいです 。さすがにapacheは関係ないから関係あるとすばphpだろうと考えutterramblingsレポジトリからphp-5.2系を導入するもダメ。remiレポジトリから無謀にもphp-5.3系をとってきてもダメ。memcacheを1.4.0から1.4.2に上げてもダメ。peclで取ってきたmemcacheをやめて、自分でコンパイルしたmemcache 3系betaにしてもダメ。ハッキリいって何をやってもダメでした。そもそもphpとmemcached自体の連携はうまくいきます。

memcached -d -m 1024 -u root -l 127.0.0.1 -p 11211 -vv

上記のようにして立ち上げると、デバックと言うか動作が確認できますが、そもそもW3TCとmemcachedが通信している、形跡が微塵も感じられない。iptablesあたりが通信を弾いているのかと思って、ログとったり色々やってもぜんぜんダメ。やれることはやり尽くして、困り果てた。

各種ログを漁ると、/var/log/messageがエライコトニ…。そうですか。ハイ。SELinuxさんが…。SELinuxが悪さしている可能性120%です。

setroubleshoot: SELiux は httpd デーモンによる自身へのまたは中継ポートヘの接続を阻止しています。 For complete SELinux messages. run sealert -l b4c9b4c0-bc60-4d06-9d0f-133502679433

監査メッセージを見てみると

type=AVC msg=audit(1257527181.501:8761): avc:  denied  { name_connect } for  pid=29767 comm=”httpd” dest=11211 scontext=user_u:system_r:httpd_t:s0 tcontext=system_u:object_r:http_cache_port_t:s0 tclass=tcp_socket

type=SYSCALL msg=audit(1257527181.501:8761): arch=c000003e syscall=42 success=no exit=-13 a0=25 a1=2ac1272b9ec8 a2=10 a3=4af4578d items=0 ppid=29762 pid=29767 auid=500 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=1 comm=”httpd” exe=”/usr/sbin/httpd” subj=user_u:system_r:httpd_t:s0 key=(null)

そうとわかれば、SELinuxの設定を変えるしかありません。要はソケット使った通信を許可してない訳だよね？さすがにSELinuxを無効にするってのは楽ですが愚かな行為だと思います。関連するのはこの辺かな？

# getsebool httpd_can_network_connect
httpd_can_network_connect –> off

これを変更します。

#setsebool -P httpd_can_network_connect 1

# getsebool httpd_can_network_connect
httpd_can_network_connect –> on

ちゃんと、動きました。もう少し設定を詰めてからさらに詳しいレポートするかもしれません。これでW3 Total Cacheの戦力大幅UP。SELinuxは気が付きづらいから怖いない。 W3TCの普及に少しでも貢献できればうれしいです。本家のフォーラムにも同様の事で困ってる人がいるので、書き込んでおきます。自分も質問しましたが返事がないです

まず、基本的にインストールしただけだと、ディスクキャッシュを使うので、WP Super Chacheと大差ありません。キャッシュの方法としてそれ以外に、APCか、memcachedを使うことが出来ます。APCはある程度枯れてますね。要はPHPの中間コードのキャッシュの技術です。memcachedは最近王手SNSや、いろいろなサイトで採用されている技術で、メモリをたんまり使って色々なものをキャッシュする技術です。dbのクエリなどをキャッシュすれば非常高速になります。ところがうちのマシンでは、このW3TC’がうまく動きません。CentOS 5.3の標準の環境では問題があるのか、もしくはWordpress 2.8.5に問題があるのか。phpのバージョンを5.2系に上げたらapcを正しく認識したけど、memcachedを認識しない。標準の5.1系ではapcも認識しないし、memcachedも認識しない。memcachedはデバックモードで見てても通信してない感じすらうける。現状ではdiskcacheだけなのでWP Super Cacheと大差ない状況だ。

あと、Javascriptの圧縮はJSminを使って実現していること、CSSはYUI Compressorを使って実現している事がわかった。

他では結構ちゃんと動いているようなので、もう少しいじってみます。

前のエントリーでいきなり、WP Super Cacheをアンインストールした理由がこれ。W3 Total Cache Pluginを導入するためです。dougal.gunters.orgで詳しく紹介されています。実際にこのblog自体はできて1ヶ月も経っていないのでトラフィックは非常に少なく、WP Super Cacheを入れる程でもない状況です。ただでさえ、昨年サーバをリプレイスしてデュアルコアのCPUに、メモリも8GB(ECC)程搭載していますから、サーバは非常に余裕があります。ただし、無駄な演算はできるだけ減らしたほうが、快適です。そのうちW3TCが生きてくる位のトラフィックになるとうれしいですね。

W3TCはかなり新しいWordpress用のプラグインで、WP Super Cacheと同じような事を実現するものですが、それ以外にユニークで先進的な特性を持ち合わせています。HTMLやCSSのキャッシング、Javascriptの縮小（これはどういう動きをするか不明）、GZIP圧縮（すごく有用だと思います）、CDN対応（普通のサイトでは要らないだろうけど、大規模サイトでは嬉しいはず）、APCやmemcached対応などです。WP Super Cacheは一部のページを静的ページとして.htaccessとapacheのとmod_rewriteモジュールを利用してリクエストを書き換えることでキャッシュ機能を実現してしていましたが、W3TCはより広範囲にキャッシュが有効になります。データベースのクエリなどまでキャッシュするのですからだいぶ効率的です。2009 Weblog Tools Collection Plugin Competition.にもエントリーされてますし、期待できるプラグインです。トラフィック自体が少ないので、効果は実感できませんが。