GIGAZINEのLoadAverageを「27」から「2」へ下げた方法

ここ3日間ぐらい超絶な重さだったのはサーバに物理的トラブルが発生したからではなく、単純に閲覧者数が満員御礼となり、各時間で倍増したためです。LoadAverageはひどいときで15分間の平均値「27.1」程度。瞬間最大風速だともっと高いです……明らかにまずい。

というわけで、Apacheのデフォルト設定で今までは大丈夫だったのですが、ついに高負荷サイト用の設定に変更せざるを得なくなりました。

そのため、実際に行った対処方法は以下の通り。1日30万PV近い動的サイトの高負荷を緩和させる方法として参考になれば幸いです。
まず大前提として、既にDNS逆引きや.htaccessの余計な読み込みなどは停止させていました。下記ページに書いてあることは実行済み。

＠IT：Apacheパフォーマンス・チューニングの実践（1/2）

この状態で負荷が15分平均で「27」になっていたわけです。

また、LoadAverageがどういう意味かというのは下記サイトを参照。

人力検索はてな - Linuxのtopコマンドで表示されるload averageについて教えてください
http://q.hatena.ne.jp/1135926670

ボトルネックの見極めに際しては以下の記事を参考にしました。

サーバやPCのボトルネック箇所の簡単な見分け方(Linux編) : ITpro Watcher

では改めて、負荷軽減戦記スタート。

1.MySQLにいちいち接続しないようにキャッシュさせる

初期のキャッシュ保持時間は1分でしたがいろいろ調整して60分まで保持するようにしました。これはGIGAZINEで利用しているExpressionEngine自身の機能です。

Data Caching and Performance - ExpressionEngine Documentation

結果、MySQLの食うサーバリソースがダントツに減り、データベースへ接続できずにエラーを吐くことがほぼなくなりました。LoadAverageは27から17へ。

2.負荷分散のために画像を別サーバへ

いろいろ調査したところ、画像の読み込みが全体のアクセスの半分以上になっており、これを別サーバに移して抑制することで反応速度の上昇と負荷軽減を目指しました。

結果、一番読み込まれる頻度の高いタイトルロゴ画像とRSSアイコン画像を別サーバにしただけで負荷が3分の1に。さらに今は全画像を別の専用サーバ「gigazine.jp」に入れています。これでLoadAverageは17から8へ。

3.テンプレートの軽量化

トップページに一度に表示される記事を減らし、複雑な処理を行うものは外しました。中でもカレンダーは構造が複雑でリソース消費量を飛躍させていたため切りました。これで負荷がさらに半減。LoadAverageは8から4へ。

4.httpd.confの見直し

まず「KeepAliveTimeout」を「1」という極端な値にすることで次々と人がやってくるのをさばくことを優先させることに。というのも、一度つまり始めるとどんどん「待ち行列」が伸びていき、負荷が低くならずにCPUがフル稼働という悪循環に陥っていたため。要するに無駄にサーバのリソースを消費させず、残留しないようにしたというわけ。

また、この変更に合わせてプロセスの設定（prefork MPM）も変更。MySQLへのアクセスを激減させた結果、メモリにかなりの空きがあったため、MaxClientsとServerLimitを引き上げました。使用可能なメモリ量をApacheの1プロセスあたりが使用するメモリ量で割り、最適な数値を決定。これによって高負荷時でもLoadAverageが上がらないようにして、体感速度を上昇させました。

＠IT：httpd.confによるWebサーバの最適化（2/3）

なお、1プロセスあたりの消費リソースがかなり下がっているため、このあたりはまだ改善の余地有りといった感じ。昼の12時から13時台に最もアクセスが現在は集中しており、その際でも負荷がかからずサーバのリソースを有効に活用できるような調整が必要っぽいです。

結果、2番目に負荷のかかる時間帯である22時から1時台はコンスタントにLoadAverageを4から2まで下げることに成功。

今後まだできそうな対策は「Zend Optimizer」による速度の改善やApacheを2.2にバージョンアップさせて動的な結果をすべてキャッシュさせるとか、ロードバランシングさせることでしょうか？

Zend Optimizer 3

Apache 2.2でWebサイトをパフォーマンスアップ！（1/3） － ＠IT

あと、MySQL自体も手を入れる必要があるっぽい。

【MySQLウォッチ】第14回 サーバー設定を見直してMySQLの性能を引き出す：ITpro

一時は「新しいサーバに移動するしかないのか」と絶望的気分になっていたのですが、まだなんとか持ちこたえられそうです。いわゆる「うれしい悲鳴」であるのが救い。それでも一応、新しいサーバへの移動は考え中。