mod_deflateによるコンテンツの圧縮転送：実用 Apache 2.0運用・管理術（4）（1/3 ページ）

　前回に引き続き、Apacheのパフォーマンスチューニングについて解説します。今回はナローバンドで効果を上げる、コンテンツ圧縮機能を取り上げます。

回線のボトルネック解消

　ブロードバンドが広く普及したとはいえ、携帯インフラなど依然ナローバンドが主流の分野もあります。そして、Webサーバ自身のパフォーマンスよりも、回線のボトルネックがレスポンスに大きく影響を及ぼすことがあります。例えば、ダイヤルアップで多くのユーザーがApacheに接続した場合、1つの接続が占有するCPU時間が長くなるため、同時接続数が増大する傾向にあります。

　このような場合は、限られた回線帯域を有効に利用するために、送信データの圧縮転送で状況の改善を図ります。Apache 1.xではmod_gzipモジュールがその役割を担っていましたが、Apache 2.0ではmod_deflateを利用します。

mod_deflateモジュールのメリット／デメリット

　mod_deflateモジュールを導入すると、コンテンツの転送量が減少するためネットワークへの負荷が低減できます。

　一方、デフォルトの設定では転送する全コンテンツに圧縮処理を行うため、CPU消費率が高くなります。また、mod_deflateモジュールは一度圧縮したものを圧縮した状態でキャッシュしないため、静的／動的にかかわらず、リクエストが発生するたびにコンテンツの圧縮を行うなど、あまり効率が良くありません。また、クライアントのWebブラウザによっては圧縮コンテンツを処理できず文字化けを起こすなどの不具合が発生することもあります。

　mod_deflateモジュールを導入するかどうかは、主に回線負荷とCPU負荷をてんびんにかけて判断することになります。しかし、CPU負荷以外にも上記のような不具合が発生する可能性があることも理解しておきましょう。本稿では、そうした不具合を発生させないようにWebブラウザの種類や圧縮対象コンテンツを限定する方法も併せて紹介します。

回線ボトルネックの見極め

　パフォーマンス悪化の原因が回線のボトルネックによるものか否か見分けるには、定期的にサーバのステータスを確認する必要があります。

　第3回の「起動プロセス／待機プロセスの状態を調べるには」で、Apacheのmod_statusを使用したプロセス数とその状態の確認方法を解説しました。プロセスの状態欄で「W」が多い場合、コンテンツの転送に時間を要していることが分かります。また、httpd.confを編集して「ExtendedStatus」を有効化することで、1秒当たりのリクエスト処理数を見ることができます。

　以下の画面のように、CPU稼働率に余裕があるなら、mod_deflateの導入効果が期待できます。

画面　「ExtendedStatus On」にしたApacheのステータス

　より詳細に状況を把握するため、リクエストごとにレスポンスを返すまでに要した秒数をログに出力させることもできます。httpd.confのLogFormatで、「%T」を追加するのです。LogFormatが複数ある場合は、CustomLogでどのLogFormatが有効なのかを確認します。

　「%T」の単位は秒です。そのため、転送に1秒かからなければ「0」と表示されます。HTMLのようなテキストコンテンツで0秒より大きな値が出力されるようなら、転送の部分にボトルネックが発生していると見なすことができます。