CentOS 7の標準環境だけですぐできる、WordPress「5.4倍高速化」テクニック 後編：とにかく速いWordPress（4）（1/3 ページ）

エンタープライズ用途での利用が増えている「WordPress」の高速化について解説する本連載。今回はCentOS 7の標準環境でWordPressを「5.4倍まで高速化」するテクニックの後編をお届けします。

[中村けん牛，プライム・ストラテジー]

連載バックナンバー

　前回は、PHPアクセラレータである「OPcache」や「MariaDB」のパラメータ調整、翻訳処理を高速化する「翻訳アクセラレータ」を導入することで、「約4.8倍」までWordPressを高速化できました。

　後編では、それを「5.4倍」まで高速化すべく、チューニングを行っていきます。

前回までのチューニング内容	ページのロード時間 （デフォルト環境比）	1秒当たりの同時アクセス数 （Requests per second）
デフォルト環境	176ms	11.24
APCの導入 　→チューニング方法をおさらい	70ms（約251％）	29.20
OPcache＋APCuを導入 　→チューニング方法をおさらい	66ms（約266％）	30.51
MariaDBの設定を調整 　→チューニング方法をおさらい	64ms（約275％）	31.82
翻訳アクセラレータを導入（キャッシュ） 　→チューニング方法をおさらい	53ms（約332％）	39.29
翻訳アクセラレータを導入（翻訳を停止） 　→チューニング方法をおさらい	36ms（約488％）	56.78

WordPressの日本語ローカルサイト

「gzip圧縮」して通信時間を短縮する

　まずは、Apacheの設定を調整して通信時間を短縮する方法を導入します。

　具体的には、WebサーバからHTTPレスポンスとしてブラウザに送られてくるHTMLとその他のファイルを、「gzip圧縮」して通信させることで、通信時間を短縮させます。WordPressが直接生成するHTMLやXMLなどのファイルの他に、CSSやJavaScriptなどのリソースファイルにも有効です。

　gzip圧縮を用いると、テキスト形式のファイルの多くは4分の1ほどのサイズまで圧縮できます。その分、通信時間を短縮し、帯域も節約できる訳です。

　今回は、同時にWebサーバからブラウザに返されるHTTPレスポンスヘッダのExpireフィールドとCache-Controlフィールドを制御して、ブラウザキャッシュを強めにする設定も適用します。今回の設定では、MIME Typeがtext/htmlの場合は「10秒」、その他の場合は「600秒」を指定します。

　/etc/httpd/conf/httpd.confの末尾に、次の設定を追記してください。

# gzip setting
AddOutputFilterByType DEFLATE text/html text/plain text/css
AddOutputFilterByType DEFLATE text/javascript application/x-javascript application/javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# expire setting
ExpiresActive On
ExpiresDefault "access plus 600 seconds"
ExpiresByType text/html "access plus 10 seconds"

リスト3：/etc/httpd/conf/httpd.conf（追記部分のみ抜粋）

　Apacheを再起動して設定を反映させます。

[root@ip plugins]# systemctl restart httpd

　Webブラウザでトップページにアクセスし、Firebugの「ネット」タブで確認すると、WordPressの生成するHTMLリソースの他に、CSSやJavaScriptなどのテキスト形式のリソースファイルのサイズが4分の1ほどに減少しているのが分かります。また、レスポンスヘッダのContent-Encodingフィールドが「gzip」となっていることも確認できます（画面3）。ページのロード時間もわずかですが向上し、筆者の環境では35ms前後となりました。

画面3　トップページの各リソースのサイズやレスポンスヘッダをFirebugで確認したところ

　さらに、F5キーなどでのリロードではなく、ページ内のリンクをたどりながら何度かトップページやその他のページへアクセスしてから、Firebugで再度確認してみます。幾つかのリソースは通信そのものが発生せず、Expireの設定によってWebブラウザのキャッシュが利用されていることを確認できます。

「Tuned」の設定とApacheの構成を変更し、さらなる最適化を図る

　「Tuned」の設定を行い、さらに高速化チューニングを進めましょう。

　TunedはOSの利用状況に応じたシステム設定を最適化するデーモンです。幾つかのプロファイルが用意されており、適切なプロファイルを選択することで、OSのパフォーマンスを向上させることができます。プロファイルの設定は、tuned-admコマンドで行います。

　tuned-adm listコマンドを実行すると、次のようにプロファイルのリストと現在適用されているプロファイルが表示されます。

[root@ip plugins]# tuned-adm list
Available profiles:
- balanced
- desktop
- latency-performance
- network-latency
- network-throughput
- powersave
- throughput-performance
- virtual-guest
- virtual-host
Current active profile: virtual-guest

　上記では、virtual-guestというプロファイルが適用されていることが確認できます。WordPressのサーバとしては、ディスクおよびネットワークI/Oのスループットパフォーマンスを向上させるプロファイルである「throughput-performance」が適していますので、こちらに切り替えます。

[root@ip plugins]# tuned-adm profile throughput-performance

　筆者の環境では、ページのロード時間が34ms、Requests per secondは58.47となり、さらに数％のパフォーマンス向上を果たせました。

ここまでのチューニング内容	ページのロード時間 （デフォルト環境比）	1秒当たりの同時アクセス数 （Requests per second）
デフォルト環境	176ms	11.24
APCの導入 　→チューニング方法をおさらい	70ms（約251％）	29.20
OPcache＋APCuを導入 　→チューニング方法をおさらい	66ms（約266％）	30.51
MariaDBの設定を調整 　→チューニング方法をおさらい	64ms（約275％）	31.82
翻訳アクセラレータを導入（キャッシュ） 　→チューニング方法をおさらい	53ms（約332％）	39.29
翻訳アクセラレータを導入（翻訳を停止） 　→チューニング方法をおさらい	36ms（約488％）	56.78
gzip圧縮を用いる	35ms（約502％）	─
Tunedの調整	34ms（約517％）	58.47