CentOS 7の標準環境だけですぐできる、WordPress「5.4倍高速化」テクニック 前編：とにかく速いWordPress（3）（2/3 ページ）
企業のCMSサイトやオウンドメディアなどエンタープライズ用途での利用が増えている「WordPress」の高速化について解説する連載。今回は、CentOS 7の標準環境でWordPressを「5.4倍まで高速化」するテクニックを解説します。
MariaDBの設定を調整してデータベースの処理を高速化する
さらにチューニングを進めていきましょう。
CentOS 7が標準で採用するMySQL互換のデータベース管理システムである「MariaDB 5.5」は、デフォルトのストレージエンジンとして「InnoDB」を採用しています。今回は、WordPressをInnoDBで運用する場合に効果のある、2つのパラメータを設定します。
/etc/my.cnf.d/server.cnfを編集して、[mysqld]のセクションを以下のように修正して保存してください。
[mysqld] innodb_buffer_pool_size = 512M query_cache_size = 64M
MariaDBを再起動して設定を反映させます。
[root@ip ~]# systemctl restart mariadb
Webブラウザでトップページをリロードします。先ほどと同様に初回は少し時間がかかりますが、二度目以降はページのロード時間が高速になっていることが確認できます。筆者の環境では、64ms前後になりました。同じくabコマンドでのベンチマークでは、Requests per secondが31.82となりました。
5パーセントほどですが、この設定によってパフォーマンスがさらに改善されました。ここでは、主にクエリキャッシュの設定が寄与しています。
クエリキャッシュは、一度発行された参照系クエリ（SELECT文）の実行結果をメモリ上にキャッシュしておいて、同じクエリが発行されたら、その結果を再利用することによってデータベースの実行速度を向上させるものです。PHPアクセラレータと同じく、データベースの更新によってクエリの結果が影響を受ける場合には、キャッシュは破棄されます。クエリキャッシュの有効／無効によってクエリの結果が変わることはありません。
なお、クエリキャッシュはデフォルトでは無効になっています。上記server.cnfのquery_cache_sizeに任意の値を設定することによって有効となります。
もう1つのパラメータであるinnodb_buffer_pool_sizeは、InnoDBのデータやインデックスなどをキャッシュするためのメモリ領域のサイズです。CentOS 7の MariaDB 5.5では、デフォルトで128MBになっていますが、今回は512MBとしました。MyIsamと異なり、InnoDBはOSのディスクキャッシュを利用しない設計になっていますので、この値は大きければ大きいほどクエリの実行で有利に働きます。
この2つのパラメータは、今後1年間のWordPressの運用で見込まれるデータベースサイズの最大値を「X」とした場合、query_cache_sizeはXの10％以上、innodb_buffer_pool_sizeはXの120％以上となる値に設定するのが目安です。今回は運用時のデータベースサイズの最大値を400MBと想定して、query_cache_sizeを64MBに、innodb_buffer_pool_sizeを512MBに設定しています。
なお今回の結果が数％増程度であるのは、インストール直後のWordPressのデータベースサイズが160KBほどと、ほとんどデータがない状況だからです。実際の運用では、コンテンツの追加や更新に伴ってデータベースサイズは増え、プラグインで機能を追加していくことで発行クエリ数も増大していきます。そうなると、パフォーマンスの違いが10倍（10％ではありません。1000％です！）以上になるケースも珍しくはありません。運用が進むにつれて「この2つのパラメータがとても重要になる」ことをぜひ念頭に置いておきましょう。
ちなみに、ストレージエンジンがMyIsamの場合でもクエリキャッシュは大きな効果があります。しかし、その他のパラメータについては、InnoDBとは全く異なる設定が必要です。InnoDBがデフォルトのストレージエンジンである環境にWordPressを新規にインストールすれば、全てのテーブルがInnoDBで作成されますので、今回紹介する手順のままで問題ありません。一方、もし他のWordPress環境から移転などでデータをインポートするような環境の人は注意が必要です。インポートの前後に、実際の各テーブルのストレージエンジンがInnoDBになっているかを確認するようにしてください。
| ここまでのチューニング内容 | ページのロード時間 （デフォルト環境比） |
1秒当たりの同時アクセス数 （Requests per second） |
|---|---|---|
| デフォルト環境 | 176ms | 11.24 |
| APCの導入 →チューニング方法をおさらい |
70ms（約251％） | 29.20 |
| OPcache＋APCuを導入 →チューニング方法をおさらい |
66ms（約266％） | 30.51 |
| MariaDBの設定を調整 →チューニング方法をおさらい |
64ms（約275％） | 31.82 |
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
さっくり理解するPHP 5.5の言語仕様と「いい感じ」の使い方
PHP 5.5.0が公開されました。オペコードキャッシュやジェネレータなど、言語仕様としても実行エンジンとしても挑戦的な内容が含まれています。
WordPress自体のチューニングが必要な理由と高速化の基本的な考え方
企業のCMSサイトやオウンドメディアなどエンタープライズ用途での利用が増加しているWordPressの高速化について解説する連載。初回は、WordPressの高速化が求められる背景や、WordPress高速化の基本的な考え方であるページのロード時間とその構成要素、1秒当たりの同時アクセス数について解説します。
ここが変わったCentOS 7──「新機能の概要とインストール」編
「CentOS 7」を皆さんどれだけ理解していますでしょうか。CentOS 7は、以前のバージョンから使い勝手がかなり変わりました。本連載では、今さら聞けない／おさらいしたいというインフラエンジニアに向け、CentOS 7の概要と基礎から活用Tipsまでを紹介していきます。
安いホスティングに引っ越しって簡単にいうけど 〜リモートアクセスにはSSHを使いましょう〜
安いホスティング先に、メールサーバと社外向けWebサーバが引っ越した。Web画面のリモート設定でいらいらする律子さん。使い慣れたtelnetではアクセスできず……
Webのバグを燃やしまくるFirebugと、そのアドオン7選
httpd.confによるWebサーバの最適化
Webサーバのチューニングには、いくつかの段階がある。今回は、httpd.confの修正によるApacheの最適化について説明する。（編集部）
Apacheパフォーマンス・チューニングのポイント
Apacheをチューニングすることにより、Webサイトのパフォーマンスをより向上させることができる。しかし、その前に何をチューニングすべきなのかを見極める必要がある。
Apacheパフォーマンス・チューニングの実践
前回、ボトルネックになり得るポイントの検討やベンチマークツール「ab」によるパフォーマンス・チェック方法を紹介した。今回はそれらを基に、Apacheのチューニングを行っていく。
MySQLの高度な管理とチューニングテクニック
本連載もついに最終回。今回はMySQLサーバの運用・管理に必要な状態監視、チューニング、バックアップ、セキュリティについて解説する。以下のテクニックを駆使すれば、MySQLをさらに安定稼働させられるだろう。
安全を考えてPHPの実行時設定を調整する
PHPを初期設定のまま使うと、いろいろ問題が起こる可能性があります。今回は、問題の発生を未然に防ぐ設定法をいくつか紹介します。（編集部）