最新のWordPressサーバースタックを見る

ApacheサーバーとPHPだけで「高速な」WordPressWebサイトを実行できる時期を覚えていますか？ ええ、それらはその日でした！ 当時、物事はそれほど複雑ではありませんでした。

今、すべてが超高速でロードする必要があります！ 訪問者は、以前と同じ読み込み時間についての期待を持っていません。 遅いウェブサイトはあなたやあなたのクライアントに深刻な影響を与える可能性があります。

SmashingMagの詳細：

• 適切なWordPressファイルシステムのアクセス許可と所有権
• 手間をかけずにWordPressウェブサイトを移動する
• MAMPを使用してWordPressをローカルで開発する方法
• WordPressを使用した日曜大工のキャッシュ方法

その結果、 WordPressサーバースタックは、このスピードの必要性に追いつくために何年にもわたって進化しなければなりませんでした。 この進化の一環として、エンジンにいくつかのギアを追加する必要がありました。 古いギアのいくつかも同様に変更する必要がありました。

その結果、WordPressサーバースタックは、数年前とはかなり異なって見えます。 それをよりよく理解するために、この新しいスタックを詳細に調べます。 WordPress Webサイトを高速化するために、さまざまな要素がどのように組み合わされているかがわかります。

概要

飛び込む前に、ズームアウトして全体像を見てみましょう。 この新しいWordPressサーバースタックはどのように見えますか？ さて、ここに答えがあります：

上の図は、最新のWordPressサーバースタックがどのように見えるかについての概要を示しています。 大まかに言えば、何が起こっているかを3つの領域に分けることができます。

• ブラウザとWordPress間の要求と応答のサイクル。
• WordPress（PHPランタイムが実行するスクリプト）。
• WordPressとMySQLデータベース間のクエリ結果サイクル。

最新のWordPressサーバースタックの役割は、これら3つの領域を最適化することです。 これらの最適化により、すべての読み込みが速くなります。 そして最良の部分は、それを行うためのいくつかの方法があるということです。 （わーい！）

ほとんどの場合、これらの最適化には、サーバーへの新しいサービスのインストールが含まれます。 これらのサービスは、WordPressと対話するためにプラグインの助けを必要とする場合があります。 プラグインをインストールするだけで解決できる場合もあります。 この記事全体を通して、さまざまなオプションが表示されます。

要求と応答のサイクル

すべてはブラウザから始まります。 modern.wordpress-stack.orgのホームページを表示したいとします。 ブラウザは、それをホストするWebサーバーにHTTPリクエストを送信することから始まります。 もう一方の端では、Webサーバーが要求を受け取り、それをHTTP応答に変換します。

この最初の応答は、常に、 modern.wordpress-stack.orgのホームページのHTMLコンテンツである必要があります（エラーがない限り）。 ただし、ブラウザの機能は完了していません。 いいえ、そのホームページにはさらに多くのファイルが必要です。最も一般的なファイルはCSS、JavaScript、画像ファイルです。

したがって、ブラウザはそれらのファイルのリクエストを送信します。 Webサーバーは、要求されたファイルで応答します（ここでも、エラーがない限り）。 このサイクルは、ブラウザがホームページをレンダリングするのに十分な情報を取得するまで続きます。 このサイクルが速くなるほど、Webサイトの読み込みが速くなります。

さて、これは明らかな単純化ですが、WordPressWebサイトの大部分で物事がどのように機能するかです。

要求/応答サイクルの最適化

さて、これは明らかな質問に私たちをもたらします、どうすればWebサーバーにこのサイクルをより速く実行させることができますか？ これは素晴らしい質問であり、最新のWordPressサーバースタックが存在する理由の一部です。

Webサーバーを高速化することはできないため、スタックが存在します。 Webサーバーはディスパッチャでもあります。 リクエストを受信して​​、他のサービスに転送することができます。

これらの他のサービスは、多くの場合、この要求/応答サイクルのボトルネックです。 WordPressの場合、このボトルネックはPHPです。そのため、要求と応答のサイクルを最適化することは2つになります。 Webサーバーに次のことを実行してもらいます。

• できるだけ少ないリクエストを受け取り、
• できるだけ少ないリクエストをPHPに転送します。

最新のWordPressサーバースタックは、この最後のものに焦点を当てています。 できるだけ少ないリクエストをPHPに転送したいと考えています。 これが、スタックを最適化するための主な目標になります。

スタックは最初の目標について多くを行うことができないため、2番目の目標に焦点を合わせます。 直接的な影響はありません。 2つ目は、Webサーバーの構成または最新の開発手法のいずれかによって対処されます。

要求/応答サイクルのスタック要素

では、PHPに転送されるリクエストを減らすのに役立つスタック要素は何ですか？ 特に、2つのスタック要素がその目標を達成するのに役立ちます。WebサーバーとHTTPキャッシュです。

Webサーバー

私たちはすでにWebサーバーについてかなり話してきました。 Webサーバースペースには3つの大きなプレーヤーがいます。

• Apache
• インターネットインフォメーションサービス（IIS）
• nginx

これらを合わせると、インターネット上のWebサーバーの市場シェアの90％以上を占めています。 Apacheとnginxに焦点を当てます。 IISはWordPressの実行に使用できますが、Windowsでのみ使用可能であり、ほとんどのWordPressサーバーはLinuxを使用しているため、一般的ではありません。

これにより、Apacheとnginxが残ります。 WordPressの生涯を通じて、Apacheが推奨されるWebサーバーでした。 コンピューターとサーバーの両方でWordPressを実行するLAMPスタック（Linux、Apache、MySQL、PHP）がありました。

しかし、舞台裏では状況が変化していました。 町に新しいプレーヤーがいて、その名前はnginxでした。 AutomatticとWordPress.comは2008年から使用しています。トラフィックの多いWebサイト（多くはWordPressを実行しています）の最大の割合を実行しているのはWebサーバーです。 そのため、多くのハイエンドホスティング会社やトップのWordPressエージェンシーがWebサーバーとして使用しています。

Apacheが悪いWebサーバーであるというわけではありません。 多くのトラフィックの下でそれをうまく実行させることができるApacheの専門家がいます。 箱から出して、または標準のWordPress構成ではうまく機能しません。

一方、nginxの唯一の目的は、大量のトラフィックを処理することです。 そのため、イゴール・シソエフはランブラーで働いていたときにプロジェクトを開始しました。

nginxがより多くのトラフィックをより適切に処理する理由の1つは、FastCGIを使用してPHPと通信することです。 FastCGIとは何ですか？ これは、PHPをWebサーバーとは別のサービスとして実行できるようにするプロトコルです。

Apacheはデフォルトではこれを行いません。 Webサーバーがリクエストを受信するたびに、画像、JavaScript、CSSの場合でも、PHPランタイムプロセスを開始する必要があります。 これにより、サーバーが処理できるリクエストの数と、サーバーが処理できる速度が低下します。

これは、前に見た最新のWordPressサーバースタックの目標の1つに反します。 スタックは、要求と応答のサイクル時間をできるだけ短くする必要があります。 リクエストごとにPHPをロードすることは、それが必要ない場合でも、この目標に反します。 したがって、Apacheを使用する場合は、FastCGIを調べてください。

HTTP / 2は、知っておくべきもう1つの重要なWebサーバー機能です。 これはHTTPの次のバージョンであり、要求と応答のサイクル全体を強化するプロトコルです。

HTTP / 2が登場する前は、ブラウザはWebサーバーに6つしか接続できませんでした。 また、各接続は一度に1つのリクエストしか処理できませんでした。 したがって、実際には、要求/応答サイクルは、サイクルごとに6つの要求に制限されていました。

それは本当の問題です。 ほとんどのWebサイトには、サイクル内に数十のリクエストがあります。 開発者とシステム管理者は、この制限を回避するための賢い方法を見つけました。

よく知られている回避策の1つは、CSSファイルとJavaScriptファイルを組み合わせる方法です。 理想的なシナリオでは、これにより、CSSファイルとJavaScriptファイルのリクエストの総数が2つに減ります。1つはJavaScript用、もう1つはCSS用です。

これはHTTP / 2では必要ありません。 HTTP / 2は、接続ごとに無制限の数のリクエストを許可します。 これにより、最初のHTML応答後のすべての追加リクエストを同時に発生させることができます。

これは、パフォーマンスに大きな影響を及ぼします。 サーバースタックを最適化する作業の多くは、要求と応答のサイクルに集中しています。 サイクル数をほんの一握りに減らすことで、HTTP / 2は私たちのために途方もない量の仕事をしてくれました。

HTTPキャッシュ

最新のWordPressサーバースタックの最も重要な部分はHTTPキャッシュです。 WordPressの世界では、このページのキャッシュとも呼ばれます。 HTTPキャッシュの目的は、リクエストへの応答をキャッシュすることです。 これは何を意味するのでしょうか？

さて、前の例に戻りましょう。 ブラウザはmodern.wordpress-stack.orgのホームページへのリクエストを送信し、ウェブサーバーはそのリクエストを受信して​​PHPに転送します。

このシナリオの問題は、Webサーバーがダムであるということです。 ほとんどのリクエストが同じ応答を生成するかどうかに関係なく、受信したすべてのリクエストを常にPHPに転送します。

これは、訪問者がログインしていないときに発生することです。Webサーバーにとって、これらはすべて異なる要求ですが、関係ありません。 それらすべてをPHPに転送し、すべてのPHPに対して同じ応答を生成します。

それはひどい！ 前に見たように、PHPは要求/応答サイクルの本当のボトルネックです。 ブラウザは、最初のホームページ応答を受信するまで、フォローアップ要求を送信できません。 デフォルトでは、WebサーバーにすべてをPHPに転送させることはできません。

そこでHTTPキャッシュが登場します。HTTPキャッシュはWebサーバーとPHPの間にあります。 その仕事は、Webサーバーが受信するすべての要求をチェックし、キャッシュされた応答を探すことです。 存在しない場合は、リクエストをPHPに転送してから、PHPが生成するレスポンスをキャッシュします。

これにより、要求と応答のサイクルタイムが大幅に短縮され、Webサイトの読み込みが速くなります。 また、Webサーバーは、爆発することなく、より多くの同時要求を処理できます。

HTTPキャッシュのさまざまなフレーバー

この時点で、「この赤ちゃんをできるだけ早くサーバーに配置するにはどうすればよいですか？」と疑問に思うはずです。 幸いなことに、WordPressサーバーにHTTPキャッシュをインストールするのは非常に簡単です。 これは、最も幅広いオプションを備えたコンポーネントです。

ページキャッシュプラグインをインストールする

最も簡単な方法は、ページキャッシュプラグインをインストールすることです。 選択できるオプションがいくつかあります。

• Batcache
• ハイパーキャッシュ
• キャッシュイネーブラー
• WPロケット
• WPスーパーキャッシュ
• W3トータルキャッシュ

WP Rocketを除くすべては、WordPressディレクトリで無料のプラグインとして利用できます。 したがって、1つをインストールして、すぐにテストすることができます。 そうは言っても、4つのプラグインの中で、最高のものはWPRocketです。 有料のプラグインですが、HTTPキャッシュを作成するだけではありません。 これらの他の利点は、HTTPキャッシュが実行している作業を拡大します。

ページキャッシュプラグインはどのように機能しますか？

これらのプラグインはすべて、WordPressがキャッシュに利用できるようにしたドロップインを活用しています。 このキャッシングドロップインにより、プラグインはWordPress内にHTTPキャッシュシステムを作成できます。 キャッシングドロップインが機能するには、2つのことが必要です。

まず、 advanced-cache.phpドロップインファイルがwp-contentフォルダーにある必要があります。 それが実際のファイルです。 しかし、ほとんどのWordPressドロップインとは異なり、これはデフォルトでは起動しません。 WordPressは、ドロップインをロードするためにWP_CACHE定数がtrueである必要もあります。 ほとんどの場合、これはwp-config.phpで設定します。

上の図は、キャッシュプラグインを使用してドロップインを有効にした場合に何が起こるかを示しています。 WordPressは、ロードプロセス中にwp-settings.phpのドロップインをロードします。 これはプロセスの初期段階であるため、WordPressはまだ時間のかかる作業を行っていません。

次に、キャッシングプラグインは、リクエストへの応答をすでにキャッシュしているかどうかを確認します。 ある場合は、キャッシュされた応答を返します。 そうでない場合は、PHP出力バッファリングがオンになり、WordPressはロードを続行します。

さて、出力バッファリングは興味深いシステムです。 次の2つのいずれかが発生するまで、PHPスクリプトからのすべての出力を文字列変数にキャプチャします。

• 組み込み関数の1つを使用して、出力のバッファリングを停止するようにPHPに指示します。
• PHPスクリプトが終了し、ブラウザに応答を返す必要があります。

キャッシングプラグインは後者のシナリオを頼りにしています。 それは、WordPressがそのことを実行し、PHPがブラウザに送り返す前に出力全体をキャッシュすることを望んでいます。 次の図でプロセスを確認できます。

Webサーバーに実行させる

次のオプションは、WebサーバーレベルでHTTPキャッシュを追加することです。 それが機能する方法は、WebサーバーがPHPに転送される要求へのすべての応答をキャッシュすることです。 このソリューションは、PHPにまったく触れる必要がないため、キャッシュプラグインよりも優れています。

上の図は、Webサーバーで何が起こっているかの概要を示しています。 Webサーバーはリクエストを受信し、HTTPキャッシュをチェックします。 応答がすでにキャッシュされている場合、HTTPキャッシュはそれを送り返します。

それ以外の場合は、リクエストをPHPモジュール（通常はFastCGI）に転送します。 リクエストをWordPressに渡し、レスポンスを生成できるようにします。 HTTPキャッシュモジュールは、帰りにその応答をキャッシュします。

Apacheとnginxの両方に、HTTPキャッシュシステムを追加する機能があります。 nginxのものが組み込まれています。Apacheのものは、Apacheインストールに追加する必要がある別個のモジュールです。

PHPまたはWordPressでApacheモジュールを使用する方法については多くの情報がありません。 これは、Apacheの群集に人気がないためか、問題があるためである可能性があります。 まだ未解決の問題が少なくとも1つあります。

一方、nginx HTTPキャッシュシステムは堅牢で、十分に文書化されています。 通常のHTTPキャッシュとして、またはより小さくても効果的なマイクロキャッシュとして使用できます。 これが、nginxが最近推奨されるWebサーバーであるもう1つの理由です。

ワニスをスタックに追加します

ワニスとは何ですか？ これは専用のHTTPキャッシュサーバーです（または、開発者が呼んでいるように、HTTPアクセラレーターです）。 ほとんどのトラフィックの多いWebサイトとプレミアムホスティング会社は、HTTPキャッシュソリューションとしてそれを使用しています。

それが強力で最も柔軟性があるので、彼らはそれを使用します。 Varnishには、VCLと呼ばれる独自の構成言語があります。 キャッシュプロセスのすべての要素を制御できます。 Varnishには、キャッシュの動作とパフォーマンスを分析するためのツールも多数付属しています。

これらは、それを使用することと、組み込みのWebサーバーのHTTPキャッシュを使用することの主な違いです。 組み込みのWebサーバーのHTTPキャッシュは非常に高性能ですが、非常に基本的でもあります。 いくつかの構成オプションを超えて、多くの制御を行うことはできません。

それにもかかわらず、このパワーと柔軟性には代償が伴います。 ワニスは、最も複雑なHTTPキャッシュオプションでもあります。 HTTP応答をキャッシュするだけです。 ほとんどのWordPress開発者が望んでいる（または望んでいるはずの）SSLターミネーションを処理しません。 これは、最新のWordPressサーバースタックを使用すると、より複雑になることを意味します。

上の図は、この余分な複雑さを示しています。 これで、WordPressサーバースタックにさらに2つのコンポーネントがあります。Varnishとリバースプロキシです。

リバースプロキシは、VarnishがSSLで持つ制限を克服するためにあります。 Varnishの前に配置され、サーバーが受信するリクエストを復号化します。 このタイプのリバースプロキシをSSLターミネーションプロキシと呼ぶこともできます。 次に、プロキシはこれらの復号化された要求をVarnishに送信して処理します。

リクエストがVarnishにヒットすると、VCL構成ファイルが起動します。これらはVarnishの頭脳です。 たとえば、次の方法を教えてくれます。

• 着信要求を分析、クリーンアップ、および変更します。
• キャッシュされた応答を探します。
• WordPressから返される応答を分析、クリーンアップ、変更します。
• これらの返される応答をキャッシュします。
• キャッシュから1つ以上の応答を削除する要求を処理します。

この最後のものは特に重要です。 それ自体に任せて、VarnishはWordPressがいつページをキャッシュから削除したいかを知る方法がありません。 したがって、デフォルトでは、投稿に変更を加えて更新すると、訪問者には同じキャッシュページが表示され続けます。 幸いなことに、Varnishキャッシュからページを削除するプラグインが存在します。

WordPress

modern.wordpress-stack.orgのホームページに対するリクエストがWordPressにヒットしました。 これは、先ほど説明した要求と応答のサイクルを経ました。 HTTPキャッシュは、返送するHTTP応答を見つけるためにできる限りのことを行いました。

しかし、ブラウザに送り返すためのキャッシュされたHTTP応答はありませんでした。 その時点で、HTTPキャッシュには他の選択肢がありませんでした。 HTTPリクエストをWordPressに転送する必要がありました。

今ではすべてWordPressの手に渡っています。 WordPressは、HTTPリクエストをHTTPレスポンスに変換し、HTTPキャッシュに送り返す必要があります。 前に見たように、これは私たちの現代のWordPressサーバースタック全体の主なボトルネックです。

このボトルネックの原因は2つあります。 WordPressには実行するPHPコードがたくさんあります。 これには時間がかかり、PHPの処理速度が遅いほど、時間がかかります。

もう1つのボトルネックは、WordPressが実行する必要のあるデータベースクエリです。 データベースクエリはコストのかかる操作です。 存在するほど、WordPressの速度は遅くなります。 これは、クエリと結果のサイクルに関する最後のセクションの焦点になります。

PHPランタイムの最適化

PHPに戻りましょう。 現時点では、WordPressの最小要件はPHP5.2です。 このバージョンのPHPは、ほぼ10年前のものです。 （PHPチームは2011年にサポートを停止しました。）

PHPチームは、その間ずっとアイドル状態になっているわけではありません。 特に過去数年間で、パフォーマンスが大幅に向上しました。 今日それを最適化するためにあなたができることを見てみましょう。

PHPの最新バージョンを使用する

あなたができる最も簡単なことは、PHPのバージョンをアップグレードすることです。 バージョン5.4、5.5、および5.6はすべて、パフォーマンスが向上しました。 最大の改善は5.3から5.4でした。 これに切り替えると、WordPressのパフォーマンスがかなり向上しました。

オペコードキャッシングをインストールする

オペコードキャッシングは、PHPを高速化するもう1つの方法です。 サーバーサイドスクリプト言語として、PHPには大きな欠点があります。実行するたびにPHPスクリプトをコンパイルする必要があります。

この問題の解決策は、コンパイルされたPHPコードをキャッシュすることです。 そうすれば、PHPは実行するたびにコンパイルする必要がありません。 これはオペコードキャッシュの仕事です。

PHP 5.5より前は、PHPにはオペコードキャッシュがバンドルされていませんでした。 サーバーに自分でインストールする必要がありました。 これが、より新しいバージョンのPHPを使用する方がよいもう1つの理由です。

次世代コンパイラに切り替える

最後にできることは、FacebookのHHVMまたはPHPの最新バージョンであるPHP7の2つの次世代コンパイラーのいずれかに切り替えることです。 （なぜPHP 7なのか？長い話です。）

FacebookとPHPチームは、これら2つのコンパイラをゼロから構築しました。 彼らは、より現代的なコンパイル戦略を活用したいと考えていました。 HHVMはジャストインタイムコンパイルを使用しますが、PHP7は事前コンパイルを使用します。 どちらも、古き良きPHP5よりもパフォーマンスが大幅に向上しています。

HHVMは、数年前に現場に到着した最初のものでした。 多くのトップティアホストがこれで多くの成功を収めており、プライマリPHPコンパイラとして提供しています。

ただし、HHVMは公式のPHPコンパイラではないことを強調する価値があります。 PHPと100％互換性があるわけではありません。 その理由は、HHVMがPHPをサポートするように設計されているだけではないためです。 FacebookのHackプログラミング言語用のコンパイラでもあります。

PHP7は公式のPHPコンパイラです。 それは長い間存在していません。 PHPチームは2015年12月にリリースしました。これにより、一部のWordPressホスティング会社がすでにサポートしていることを妨げていません。

良いニュースは、WordPress自体が両方のコンパイラと100％互換性があることです！ 悪いニュースは、WordPressの最小PHPバージョンがまだ5.2であるため、すべてのプラグインとテーマがそうであるとは限らないということです。

作者にプラグインやテーマをこれらのコンパイラで動作させることを強制するものは何もありません。 だから、あなたはそれらの1つでオールインすることはできません。 スタックは常にPHP5にフォールバックする必要があります。

クエリ-結果サイクル

この時点で、PHPランタイムはすべてのWordPressPHPファイルを調べて実行しています。 ただし、これらのWordPressPHPファイルにはデータが含まれていません。 WordPressコードのみが含まれています。

問題は、WordPressがすべてのデータをMySQLデータベースに保存することです。 したがって、それに到達するには、PHPランタイムがそのデータベースにクエリを実行する必要があります。 MySQLサーバーはそのクエリの結果を返し、PHPランタイムはWordPress PHPファイルを実行し続けます…つまり、データが再び必要になるまでです。

これは、数十回から数百回まで発生する可能性があります。 （後者の場合は、開発者と話し合うことをお勧めします！）それが大きなボトルネックである理由です。

クエリ結果サイクルの最適化

ここでの最適化の目標は、PHPによるWordPressファイルの実行時間を高速化することです。 これは、データベースクエリが問題となる場所です。 単純なPHPコードを実行するよりも時間がかかる傾向があります（コードがとんでもないことをしている場合を除く）。

この問題を解決する明らかな方法は、WordPressが実行する必要のあるクエリの数を減らすことです。 そして、それは常に価値があります！ しかし、それは現代のWordPressサーバースタックが役立つものではありません。

WordPressが行うクエリの数を減らすことはできないかもしれませんが、選択肢もあります。 スタックがクエリと結果のサイクルを最適化するのに役立つ方法はまだ2つあります。 そもそもデータベースに対して行われるクエリの数を減らすことができます。 また、データベースに到達するクエリの場合、実行にかかる時間を短縮できます。

これらの2つのオプションは、どちらも同じことを行うことを目的としています。データベースからの結果をPHPができるだけ待たないようにすることで、WordPress自体が高速になります。

クエリ結果サイクルのスタック要素

クエリと結果のサイクルに関係するさまざまなスタック要素を見てみましょう。 スタックのこの部分はそれほど複雑ではありません。 ただし、それでも複数のコンポーネント、つまりMySQLデータベースサーバーとオブジェクトキャッシュが含まれます。

MySQLデータベースサーバー

数年前、MySQLデータベースサーバーは誰にとっても同じことを意味していました。 MySQLサーバーがインストールされたサーバーでした。 しかし、近年、状況は大きく変化しています。

さまざまなグループが、OracleがMySQLプロジェクトをどのように管理しているかに満足していませんでした。 そのため、各グループはそれをフォークし、代わりに「ドロップイン」できる独自のバージョンを作成しました。 その結果、複数のMySQLデータベースサーバーが存在するようになりました。

新しい「公式」MySQLサーバーはMariaDBサーバーです。 これは、コミュニティで開発されたバージョンのMySQLサーバーです。 コミュニティは、MySQLサーバープロジェクトとの完全な互換性を維持することを計画しています。

MySQLのもう1つの一般的な代替手段は、Perconaサーバーです。 MariaDBとは異なり、PerconaはMySQLのブランチです。 その開発者はMySQLプロジェクト自体に反対していません。 彼らはMySQLのパフォーマンスの向上に集中したいだけです。 その後、MariaDBチームは、これらのパフォーマンスの向上の一部をMariaDBプロジェクトに統合しました。

一日の終わりに、あなたはあなたが好きなものを選ぶことができます。 PerconaサーバーとMariaDBサーバーのパフォーマンスに違いはありません（とにかく私たちのほとんどにとって）。 どちらもMySQLよりもパフォーマンスが優れています。 ただし、PerconaはOracleプロジェクトとのより緊密な互換性を維持しています。

パフォーマンスに影響を与えるのは、WordPressデータベースが使用するストレージエンジンです。 ストレージエンジンは、データベースサーバーが格納するデータを管理する方法を制御します。 データベーステーブルごとに異なるストレージエンジンを設定することもできます。 データベース全体に同じものを使用する必要はありません。

データベースサーバーには、いくつかのストレージエンジンがあります。 それらすべてを見るつもりはありません。 InnoDBとMyISAMの2つだけが私たちに興味を持っています。

デフォルトでは、WordPressはデフォルトのMySQLデータベースエンジンを使用します。 MySQL 5.5より前は、そのエンジンはMyISAMでした。 小さなWordPressWebサイトを運営している場合は、MyISAMで問題ありません。 Webサイトのサイズが大きくなると、MyISAMでパフォーマンスの問題が発生します。 その時点で、InnoDBがデータベースエンジンの唯一の選択肢です。

InnoDBの唯一の問題は、最高のパフォーマンスを発揮するために調整が必要なことです。 大規模なデータベースサーバーを実行している場合は、調整が必要になる場合があります。 私たちにとって幸運なことに、それを支援するツールがあります。

MySQLTunerは、データベースサーバーを分析する小さなスクリプトです。 レポートを生成し、チューニングの推奨事項を提供します。

オブジェクトキャッシュ

クエリと結果のサイクルを最適化する作業の要は、オブジェクトキャッシュにあります。 オブジェクトキャッシュの役割は、取得または生成に時間がかかるデータを格納することです。 ご想像のとおり、データベースクエリは最適な候補です。

WordPressはオブジェクトキャッシュを頻繁に使用します。 get_optionを使用してデータベースからオプションを取得するとします。 WordPressは、そのオプションについてデータベースに1回だけクエリを実行します。 次回誰かがそれを必要とするときに、それは再びそれを照会しません。

代わりに、WordPressはオブジェクトキャッシュからクエリ結果をフェッチします。 これは、WordPressが実行する必要のあるデータベースクエリの数を減らすために実行するプロアクティブな手順です。 しかし、それは絶対確実な解決策ではありません。

WordPressはオブジェクトキャッシュを活用するために最善を尽くしますが、プラグインやテーマはそうする必要はありません。 プラグインまたはテーマが多くのデータベースクエリを実行し、結果をキャッシュしない場合、スタックはそれについて何もできません。

このような場合、データベースクエリのほとんどはWordPress自体から送信されます。 そのため、WordPressの組み込みのオブジェクトキャッシュの使用から大きなマイレージを得ることができます。 それが現代のWordPressサーバースタックの重要な要素である理由です。

現在、オブジェクトキャッシュの問題は、デフォルトで保存されているデータを永続化しないことです。 PHPがすべてのWordPressファイルを実行している間、データをメモリに保存するだけです。 ただし、PHPプロセスが終了すると、メモリに保存されているすべてのデータがクリアされます。

これはまったく理想的ではありません。 オブジェクトキャッシュは長期間有効である可能性があるため、単一のリクエストに制限する必要はありません。 解決策は、永続オブジェクトキャッシュを使用することです。

永続オブジェクトキャッシュは、多くの場合、プラグインの形式で提供されます。 そのプラグインは、 object-cache.phpドロップインを利用してその仕事をします。 このドロップインにより、プラグインの作成者はオブジェクトキャッシュのデフォルトの動作を変更できます。

次に、プラグインはオブジェクトキャッシュを永続データストアに接続します。 これは、デフォルトのオブジェクトキャッシュのフェッチおよび保存機能を置き換えることによって行われます。 データをメモリに保存してフェッチする代わりに、オブジェクトキャッシュはそのストアからデータを取得します。

永続オブジェクトキャッシュプラグイン

現在、永続オブジェクトのキャッシュには2つの一般的なデータストアオプションがあります。

• Memcached（プラグイン）
• Redis（プラグイン）

これらのデータストアはどちらもストレージにRAMを使用しているため、非常に高速です。 実際、それらのパフォーマンスはデフォルトのオブジェクトキャッシュのパフォーマンスに匹敵します。

唯一の問題は、サーバーにプリインストールされていないことです。 また、PHP拡張機能（Redisではオプション）もありません。 対応するWordPressプラグインを使用する前に、プラグインをインストールする必要があります。

どちらをインストールする必要がありますか？ 実際には、オブジェクトのキャッシュに関しては、この2つに大きな違いはありません。 以前は、人気のあるオプションはMemcachedでした。 これは過去数年間で変化しました。 Redisには多くの機能が追加されており、オブジェクトキャッシングの頼れるオプションとなっています。

独自の最新のWordPressサーバーを入手する

では、どのようにして独自のサーバーを入手しますか？ 明らかな方法は、一流のWordPressホスティング会社から入手することです。 これらの企業は、WordPressホスティングビジネスの最前線にとどまりたいと考えています。これにより、最新のブレークスルーとテクノロジーを採用するようになります。

しかし、銀行を壊さずに1つが必要な場合はどうなりますか？ いくつかのツールは、自分でそれを行い、ホスティングの費用を抑えたい人なら誰でも利用できます。 それらを見てみましょう。

WordPressのDebOps

DebOps for WordPressは、誰もが最新のWordPressサーバーを構築できるように私が構築したツールです。 その使命は、コミュニティの誰もが最新のWordPressサーバースタックを利用できるようにすることです。 だから私はできるだけ使いやすくしようとしています。 使用するのにシステム管理の知識は必要ありません。

DebOps for WordPressは、次のようにサーバーを構成します。

• HHVM（PHP 7が公式のLinuxリポジトリになるまで）
• MariaDB
• nginx
• Redis
• ワニス

このツールは、最新のテクノロジーを使用してサーバーを構成するだけではありません。 また、サーバーの保護も行います。 これは、自分のサーバーを管理するときに見落とされがちなことです。

EasyEngine

EasyEngineは、サーバー上にWordPressWebサイトをセットアップするのに役立つように設計されたコマンドラインツールです。 EasyEngineの優れている点は、その柔軟性です。これまで見てきたサーバーテクノロジのほぼすべての組み合わせをセットアップして使用できます。

たとえば、HHVMまたはPHP 7のいずれかを使用してサーバーをセットアップできます。永続データストアとして、MemcachedとRedisのどちらかを選択できます。 また、phpMyAdminなどの管理者ツールをインストールできます。

また、WordPressWebサイトを作成するときに多数のオプションを提供します。 プラグインまたはnginxを使用して、HTTPキャッシュを使用してWebサイトをセットアップするように指示できます。 この柔軟性のすべてが、EasyEngineが非常に人気のあるツールである理由です。

トレリス

TrellisはRootsによって開発されたツールです。 DebOpsと同様に、特定のサーバーテクノロジーのセットを使用してサーバーを構成します。

• MariaDB
• Memcached
• nginx
• nginx HTTPキャッシュ（オプション）
• PHP 7

Trellisについて知っておくべきことの1つは、Rootsによって構築された別のツールであるBedrockとの関係です。 Bedrockは、「12ファクターアプリ」の原則に基づいてWordPressWebサイトを構築するための定型文です。

Rootsチームは、人々がBedrock構造のWordPressWebサイトを使用するサーバーを構成できるようにするためにTrellisを作成しました。 通常のWordPressインストールでは使用できないので、注意してください。

時が変わった

ご覧のとおり、WordPressサーバーには今日より多くの可動部分があります！ しかし、これが絶望の原因である必要はありません。 必ずしもすべての部品を使用する必要はないので、見た目ほど悪くはありません。

そのため、この記事の多くで、これらの部分がどのように連携するかについて説明しています。 重要なのは、自分で決定を下せるようにすることです。 この知識を使用して、使用する必要のあるパーツと時期を決定します。 このようにして、あなたも高速なWordPressWebサイトを利用できるようになります。