GIGAZINE最大の挑戦、LoadAverage「86」から「3」へ

というわけで、再び負荷を下げる方法を模索した、戦いの記録。

1.MySQLの設定を変更して高速化
2.Zend Optimizer 3の導入
3.ionCube PHP Acceleratorの導入
4.テンプレートの見直しでクエリーを減らす
5.robots.txtでクロールする間隔を制御する
6.MySQLの設定を負荷を低くする設定に変更
7.キャッシュを有効化する

前回解説した「GIGAZINEのLoadAverageを「27」から「2」へ下げた方法」から約3週間後、6月20日（火）の夜、気がつくと負荷の15分平均は「25」をコンスタントに吐き出すようになり、さらに訪問者は急増、ついに6月28日（水）12時45分、負荷対策の効果がほとんど出ないまま、LoadAverage15分平均は「86」に…。

何か対策が根本的に間違っているのだろうか？それとも、もうGIGAZINEサーバのハードウェアスペックは限界なのだろうか？所詮、付け焼き刃的な負荷対策だけではだめなのか…？

だがしかし、今回は前回と違い、最終的に劇的な改善を成し遂げました。以下、その過程を完全解説。
まず6月20日の夜に行った負荷対策。

1.MySQLの設定を変更して高速化
頻繁にデータベースに接続する原因はページビューのカウントとランダムトラックバックアドレス生成の2つがメイン。ExpressionEngine自体がデータベースの構文とかそのあたりのチューニングはしっかりしているという前提の元、できることといえばそれ以外の点、つまり設定ファイルの変更。調べてみたところ、「my.cnf」という設定ファイルを変更することにしました。参考にしたのは以下の記事。

MySQLのチューニング - ［データベース］All About

これを参考にしながらいろいろと見てみた結果、全メモリの4分の1を割り当てることにしました。

2.Zend Optimizer 3の導入
処理速度を速くするため、導入が恐ろしく簡単でお手軽な「Zend Optimizer 3」を選択。テストサーバでExpressionEngineの動作に支障がないことを確認して、本番環境にも導入。

MySQL設定変更とZend Optimizer 3の導入によって負荷は15分平均で25から15へ。少しましになった。だがしかし、ちょっとだけ安心したのもつかの間、6月22日（木）、衝撃の事実が判明する。「Zend Optimizer 3」が実は動いていなかったのだ…。マニュアルをよく読むと、PHPのコンパイル時に「enableversioning」オプションを付けていると動かないらしい…。

Zend Optimizer 日本語マニュアル（PDFファイル）

ご使用中の PHP がEnable Versioning が無効でコンパイルされていることをご確認ください。－phpinfo() 関数によって出力された上部の “Configure Command section “ 内に"--enableversioning"の存在の有無より、確認することができます。このパラメータが存在している場合は、このコンパイルオプションを無効にして、PHP 再コンパイルする必要があります。

検索するとよく「Zend Optimizer 入れても入れる前と速度が変わらない、効果ないよこれ」というのをよく見かけますが、もしかするとこのあたりでひっかかっているのかもしれません。

それはそうと、ということはつまり、GIGAZINEはMySQLの設定変更だけで軽くなっていたわけです。しくしく。そしてこの間も日々訪問者が増大していく。

3.ionCube PHP Acceleratorの導入
Zend Optimizer 3が動いていないことが確定したのでアンインストールし、米Yahoo！も採用しているという「ionCube PHP Accelerator」を代わりにインストールしてみました。説明マニュアルが懇切丁寧なので、手順自体はかなり簡単。

ionCube PHP Accelerator

きちんとマニュアルを端から端まで読み、中間ファイルもきちんと生成されていることを確認。とりあえずはデフォルト設定で様子見することに。細かく設定が変更できるので、このあたりを調整すればさらに最適化できるかもしれない。なかなかいい感じ。

4.テンプレートの見直しでクエリーを減らす
ブラウザで表示する部分のテンプレートだけでなく、最も多くアクセスされるRSS出力の部分を見直し。RSS出力に関係のないクエリーを削って可能な限り処理を高速化させることに。

Data Caching and Performance - ExpressionEngine Documentation

また、アクセスがピークに達する時間帯の負荷が増えているのであって、1日平均で見るとあまり増えていない、むしろ3程度の負荷に減少していることがこの時点で判明。負荷が頂点に達する時間帯は以下の3パターンのどれか。

A.12時から13時15分

B.17時から18時

C.22時から0時45分

特に重いのが「A」の時間帯である12時から13時15分。GIGAZINEは閲覧者のうち、昼間はかなりの部分が「.co.jp」ドメインあるいは企業からのアクセスとなっており、結果として昼の12時になった途端にみんながランチタイムに突入、おーし、ちょっとGIGAZINEでも見るか～とかいうことになって一斉にアクセス、どんどん負荷が増大してしまうということになっていることが白日の下に晒されました。

「B」の時間帯、17時から18時も同様の理由で、9時-5時みたいな職場の人の場合、帰る前に見ておくか～みたいな感じでアクセスしている模様。そのため、この時間帯も急上昇する。

「C」の22時から0時45分は一斉に増えないものの、今度は会社や企業以外、つまり夜の訪問者で大部分を占める一般ピープルがひっきりなしに訪れるため、コンスタントにある程度の負荷を弾き出していました。

5.robots.txtでクロールする間隔を制御する
先週のログやそれ以前のログを集計してみると、平日の時間帯の中でも特に「A」が恐ろしく跳ね上がるケースにおいて、検索エンジンのボットやクローラーが来訪するのが重なった場合に負荷が急上昇することを発見。Google、MSN、Yahooの3つのボットが同時にそれぞれ1秒から3秒ごとに次々と各ページにアクセスしており、とんでもないことになっていた。特に凄まじいのがMSNで、1秒を切るぐらいの猛スピード、つまり毎秒2ページから3ページずつアクセスしている。そこで、robots.txtでアクセス間隔を制御できないかどうか調べた結果、MSNとYahooは制御できることが判明。

サイト オーナー ヘルプ: MSNBot およびサイトのクロールに関する問題に対処する

Yahoo! ヘルプ - サイト管理者向け　検索エンジン用ロボットからのリクエスト数を減らすには

この時点で負荷は15から12へ。

まだ何か未知の方法があるのかも知れないと思い、先人の知恵を拝見するべく紀伊国屋へ行ったついでにいろいろなパフォーマンス及びチューニング関連の本を片っ端から読んでみる。結果、今のアクセス数と負荷との関係が何かおかしい予感がしてくる。要するに、思ったほどの効果が出ていない理由が別にあるのではないか？という予感。このことが判明するのはさらに後のことになる。

6月24日（金）、ライブドアブログ通信に掲載され、訪問者が一時的に増加後、最終的にRSS2.0へのアクセスが先週と比較して約2000ほど増加。また、それとは関係なくさらに訪問者が急増、負荷は15分平均が最大12から25へ。絶望的気分になる。

6月25日（土）、ExpressionEngine自体をバージョン1.4.2に更新。いろいろな機能が付いたり、バグ修正ができたのでちょっと安心。だが負荷軽減とはあまり関係がない、しょぼん。むしろPHPのファイルサイズが増えてる、大丈夫なのだろうか？機能が増えるということは処理が増えて重くなっているのでは…？と一抹の不安がよぎる。

6月26日（日）、MySQLへのアクセスが発生する設定を片っ端から見直したところ、なぜかRefererを記録するオプションがONになったままになっており、数百件のRefererを記録し続けていることが判明。Apacheのアクセスログ解析で十分なのでこの機能をOFFにする。

6月28日（火）、運命の日。12時からどんどん負荷が急上昇、そして12時45分、負荷対策の効果がほとんど出ないまま、LoadAverage15分平均が「86」に。発狂モードに陥って樹海へ旅に出たくなったでござるの巻。

6.MySQLの設定を負荷を低くする設定に変更

泣いていても仕方がないのでログを見てみると、単純にスワップが発生しただけでした。つまりどこかの設定がダメダメ。いろいろと調べた結果、「MySQLの設定を変更して高速化」が原因であることが判明。この設定はもっとメモリを積んでいるかあるいはパワーのあるマシン向けのチューニングであって、これによって処理速度は上昇するが、CPUの負荷も同様にある程度まで増大するということが判明。つまり、速度をある程度おさえてもいいから負荷を極力小さくしたいのであれば、逆にメモリを使う量は減らすべきだったのです。これは盲点だったというか、MySQL自体のドキュメントをちゃんと読んでいなかったことが原因。猛省。

これにより、同じアクセス数が夕方18時から来たわけですが、負荷は20程度で乗り切ることができました。しかしそれでもまだ重い。なんとかしなくては…。

6月29日（水）の夜、同様のケースでどのような対策が取られたのかを知るため、ExpressionEngineのコミュニティを片っ端から検索して読むことにする。

pMachine Community Forums | Powered By ExpressionEngine
http://www.pmachine.com/forums/

そしてなんと同様のことで悩んでいる人の立てたスレッドを発見。読み進んでいくと、ExpressionEngineの中の人がこんなことを書いている。

「OK、もう一度設定を見直すんだ。それから、キャッシュがちゃんと生成されているか確認するんだ。そのアクセス数でその負荷はどう考えてもおかしい、もっと軽くなるはずだ」

…キャッシュの生成？いやな予感がして、キャッシュのディレクトリを見る。ちゃんとExpressionEngineによってdb_cache、page_cache、sql_cacheという3つのディレクトリが作成されている。sql_cacheの中にはちゃんとキャッシュファイルが存在する。だが、db_cacheとpage_cacheの中に何もない…あるのはからっぽのディレクトリの山。ディレクトリのパーミッションは「777」なのに、なぜ？

7.キャッシュを有効化する
上記コミュニティでのやりとりを読むと、同じようにしてパーミッションが「777」なのにキャッシュが生成されていない人がいることが分かる。さらに読み進んでいくと、ExpressionEngineの中の人がこんなことを書いている。

「OK、PHPはセーフモードか？セーフモードなら今すぐOffにするんだ」

php.iniを見ると、きっちりセーフモードがOnになっていました。これを「Safemode = Off」にして見たところ、ぼこぼこと残りのキャッシュファイルが生成され、あっという間に負荷が減少。今まで閑散とした夜中の4時とかでも負荷が「3」程度になっていたのが「0.1」まで下がりました。つまり、今までのありとあらゆる負荷対策が一気に効果を発揮し始め、負荷が30分の1まで落ちたというわけです。

結果、今までで最大級のアクセスを6月30日（金）の12時から13時に経験したわけですが、LoadAverage15分平均は最大「3」になりました。昨日から突然、GIGAZINEがサクサク見えるようになったのはこういう次第です。

こうやってふたを開けてみると、恥の上塗りみたいな内容なのですが、同様のことでつまづく人がいるかも知れないので、あえて恥をさらしました。さらなる修行が必要のようです。

■今回の結論：
設定を変更したらそれが動作しているかどうかをきちんと確認する