ホスティングプラン選択の際には、WordPressサイトの状態に最も合致するものを検討することが重要です。
たとえば、1か月あたり50,000人の訪問者がいるECサイトでは、通常、同じ量のトラフィックが流入する普通のブログよりも多くのリソースが必要になります。
というのも、ECサイトはその性質上、動的であり、PHPとデータベースクエリのためにより多くのリソースを必要とする傾向にあります。
ここで大事になるのがワーカープロセスです。ワーカープロセスとは何か、サイトでのリクエスト処理高速化のためにどのように使用されるかについては、以下をお読みください。
ワーカープロセスとは
WordPressサイトにおいては、ワーカープロセスはページの作成、スケジュールされたバックグラウンドタスクの処理などを行います。ワーカープロセスは、サイトの訪問者に表示するHTMLページの生成に直接関わるため、これにより、サイトが同時に処理できるキャッシュされていないリクエストの数が決まります。
たとえば、あるWordPressサイト向けに2つのワーカープロセスが利用でき、 ページキャッシュの設定がされていないとします。4つのリクエストがまったく同時にサイトに到着した場合、それらのうち2つはすぐに処理されますが、他の2つは最初の2つが処理を完了するまでキューで待機する必要があります。
Kinstaでは、プランごとに、ワーカープロセスの数が異なります。たとえば、WP 5プランでは各サイトに4つ、WP 60プランでは各サイトに8のワーカープロセスが付属します。
Kinstaではサーバーレベルのキャッシュを実装していますが、キャッシュがバイパスされるリクエスト、または、キャッシュミスとなったリクエストについては、個別に処理を行う必要があるため、ワーカープロセスが非常に重要になります。
通常、ECサイトやフォーラムサイトでは、キャッシュされていないリクエストが数多く発生します。したがって、そのようなサイトでは、遅延やタイムアウトなしにすべてのリクエストが処理されるように、通常よりも多くのワーカープロセスが必要になります。
ただし、サイトが高度に最適化されていれば、またはPHPコードが多く（例：複雑なテーマまたは多数のWordPressプラグイン）なければ、各リクエストの処理はほぼ瞬時に行われるものです。2つのワーカープロセスに対して4つのリクエストであっても、4つすべてが迅速に処理されます。
簡単に言うと、ワーカープロセスとは、PHPコードを実行するサーバー上のバックグラウンドプロセスです。
WordPressサイトでのワーカープロセスの動作
WordPressサイトにおけるワーカープロセス最適化の方法へと進む前に、まずはWordPressがワーカープロセスをどのように使用しているのか理解を深めましょう。
キャッシュの設定されていない環境での一般的なリクエストは次のようになります。
- ウェブサーバー（NginxまたはApache）が訪問者からリクエストを受信する
- NginxがリクエストをPHPに渡す
- PHPは必要に応じてMySQLデータベースにクエリを実行し、テーマのPHPテンプレートを使用してHTMLページを生成
- PHPが、レンダリングされたHTMLページをウェブサーバーに返す
- そのページが訪問者に表示される
上記の手順の中で、ステップ3が最も時間とリソースを消費します（CPUとRAM）。データベースクエリを最小限に抑えた、効率的なPHPコードを持つ高度に最適化されたサイトであれば、比較的素早く3番目のステップをこなすことができます。
逆に、不必要なデータベースクエリを大量に実行する、最適化されていないPHPコードのあるサイトは、ステップ3の実行に多くの時間を費やします。この場合、リクエストがワーカープロセスを長時間占有することになります。
ワーカープロセスとCPUの関係
WordPressのパフォーマンスとなると、ワーカープロセスと利用できるCPUの関係性を考えることが重要です。
CPUリソースの不足が、あなたのサイトの懸念事項となっている場合、ワーカープロセス数を増やしても、サイトのパフォーマンスは向上しません。サイトで同時に処理できるリクエストの数が増える一方で、リクエストごとのパフォーマンスが低下するだけです。
1本のホースが取り付けられた消火栓を想像してみてください。ホースが1本だけの時、消火栓からは十分な水圧で水が放出されます。では、この消火栓に10本のホースを取り付けたらどうでしょうか？
限られた水圧が、10本のホースに分散されます。そして、個々のホースにおける水圧は弱く、使い物にならないでしょう。この例では、消火栓そのものはCPUを意味し、ホースはワーカープロセスを意味します。
この例を念頭に置いて、もし、ご利用のレンタルサーバーから（CPUについては触れることなく）ただワーカープロセスを増やすようにアドバイスされた場合には注意が必要です。
KinstaのカスタムLXDコンテナは、十分なCPUとRAMリソースを備えています。また、Google Cloudの最速CPUを搭載したC2およびC3D仮想マシンを使用して、サイトのワーカープロセスがより効率的に実行できるように配慮されています。このスケーラブルなインフラストラクチャにより、WordPressサイトのワーカープロセスは、ピークパフォーマンスで動作するのに十分なCPUリソースを確保できます。
それでは、先ほどの消火栓の例に戻りましょう。
5本のホースで10箇所の火を消す必要がある状況を想像してください。5本のホースすべてを接続した後に、消火栓にはまだ十分な水圧があることに気付きます。
この状況では、消火栓の水圧がボトルネックではないため、さらに数本のホースを接続するという判断は、理にかなっています。
これと同様に、CPUとRAMのオーバーヘッドが十分にあってもサイトのパフォーマンスが低下している場合は、 パフォーマンスを改善するためのオプションとして、ワーカープロセス数を増やすことを検討する必要があります。
サイトにおけるワーカープロセス使用を最適化する方法
ワーカープロセスは、PHPコードを使用してHTMLページを生成するバックグラウンドプロセスであることは、前にご説明した通りです。そして、ワーカープロセスの使用量を減らして最適化する最も明白な方法は、サイトへの要求を満たすために必要なCPU、PHPリソースの量を減らすことです。
この方法は以下の通りです。
1. WordPressサイトのキャッシュを設定する
ワーカープロセスの使用を減らすための最初のステップは、WordPressサイトにキャッシュを設定することです。デフォルトでは、WordPressは動的CMSであり、すべてのページリクエストを要求があった時点で実行します。
ブログ、オンラインマガジン、ポートフォリオなど、多くのサイトでは、PHPを使用してすべてのリクエストに対して動的にページを生成する必要はありません。
ページキャッシュ
現在読んでいるこの記事は、動的に生成する必要のないページの典型例です。他の多くの記事と同様に、ここにあるコンテンツは静的であるように設計されているため、同一のページを継続的に生成するためにCPUリソースを費やす必要はありません。
そこで、PHPでページを一度生成したら、その後はキャッシュをしてしまうことをお勧めします。ページのキャッシュには、PHPを使用してページを動的に生成するよりも明らかに多くの利点があります。
たとえば、サイトの記事が口コミで広がり、公開後数時間で10万ページビューを記録したとします。ページキャッシュを設定していないと、ワーカープロセスに負荷がかかり、サーバーがクラッシュする可能性があります。
ページキャッシュを使用すると、初回のページビューのみが動的に生成されます。そして、他の99,999回のリクエストは、比較的少ないCPUリソースを使用するページキャッシュから提供されます。
WordPressサイトでページキャッシュを設定するには、2つの方法があります。
- Nginxなどのウェブサーバーによるサーバーレベルでのページキャッシュ
- WP-RocketなどのWordPressプラグインを用いたプラグインベースのページキャッシュ
最大のパフォーマンスを確保するためには、可能な限りサーバーレベルのページキャッシュを使用することをお勧めします。Kinstaでは、ホスティングしているすべてのサイトでNginxのFastCGIキャッシュモジュールを使用して、超高速のパフォーマンスを実現しています。
ご利用のレンタルサーバーでサーバーレベルのページキャッシュオプションが提供されていない場合、次善の策として、 WordPressキャッシュプラグインを使用して、アプリケーションレベルでページキャッシュを実装できます。
オブジェクトキャッシュ
WooCommerceストア、フォーラム、その他ページキャッシュを効率的に使用できないWordPressサイトの場合、MySQLデータベースに全てを任せることなく、Redisなどオブジェクトキャッシュの永続化が可能なシステムを追加すると、パフォーマンスが向上し、ワーカープロセスの負荷が軽減できます。
永続的なオブジェクトキャッシュがないと、結果が前のクエリと同じであっても、MySQLデータベースクエリはリクエストごとに実行されます。
たとえば、ページキャッシュをバイパスするフォーラムサイトは、ページを作成するために、データベースに対して複数の同一のクエリを実行して、投稿データを取得します。
トラフィックが多く、データベースの負荷が大きいサイトの場合でも、ワーカープロセスを使用して、多数のリクエストに対して同一のクエリ結果が生成されるため、このようなデータベースのクエリ実行方法は非効率的だと言えます。そこで登場するのがRedisです。
Redisはデータベースクエリの結果をRAMに保存します。これにより、PHPはすでに実行されたクエリの結果をここから取得できるようになります。このオブジェクトキャッシュにより、繰り返しデータベースクエリを行う必要がなくなるため、ワーカープロセスはCPUリソースを節約でき、リクエストの処理に費やす時間を短縮できます。
2. PHPコードを最適化する
ページキャッシュの設定に加え、ワーカープロセスの使用量を減らす別の戦略に、PHPコードの最適化があります。WordPressでは「PHPコードの最適化」は実際には、様々な事柄を意味し得るため、詳しく見ていきましょう。
WordPressの最も愛され、同時に最も嫌われている（尋ねる人次第）特徴の1つが、プラグインとコードスニペットによる拡張性です。
WordPressサイトに株価ティッカーシンボル表示ウィジェットを追加したければ、そのためのプラグインがあります。同様に、カスタムフォントを追加する場合は、そのためのfunctions.phpコードスニペットが存在します。
追加機能でWordPressコアを拡張することは非常に簡単。そのせいで、サイトのパフォーマンスへの潜在的な影響を考慮せずに、やり過ぎてしまうことが多々あります。
というわけで、PHPコード最適化の最初のステップは、サイト全体にわたる監査を実行して、本当に必要なプラグインとコードスニペットだけを厳選することです。
質の高いプラグインを選ぶ
多くの場合、WordPressサイトのプラグインの数そのものは、プラグインの質ほど重要ではありません。プラグインが過去6か月更新されていない場合は、要件に合う別のプラグインを選択することをお勧めします。
というのも、WordPressは常に改善され続けています。プラグインが何年も更新されていないと、そのプラグインが最新のWordPress開発とセキュリティのベストプラクティスを利用していない可能性が考えられます。
逆に、プラグインが数週間ごとに絶えず更新されている場合、開発者が質を真剣に考えている可能性が高いため、よい選択肢だと言えるでしょう。
必要なときにだけプラグインを使用する
JavaScriptやCSSの追加など、サイトで簡単なタスクを実行する時、必ずしもそのためのプラグインが必要なわけではありません。代わりに、テーマのPHPテンプレートまたは子テーマのstyle.cssファイルに直接コードを追加することができます。
プラグインのインストールを検討する際には、少し時間をかけて、そのプラグインが100％必要かどうかを調べてください。プラグインのインストール以外に方法がない場合もありますが、それはそれで問題ありません。また、不要なプラグインをインストールしないことで、コードの肥大化を回避することもできます。
軽量のテーマを選ぶ
何千ものWordPressサイトを監査してきた経験がありますが、テーマがPHPのパフォーマンス低下の原因となるケースがあります。 汎用CMSとしてのWordPressの多様性に対応するために、一部の開発者は、さまざまな用途で機能するようにテーマをコーディングしています。
多くの場合、これにより、PHPとデータベースクエリを効率的に使用しない、コードだけが肥大化したテーマが作成されます。
WordPressサイトを構築する際に最も重要なのは、パフォーマンスが高くカスタマイズ可能なテーマを選択することです。GeneratePress、OceanWP、Astraなどがおすすめです。
3. パフォーマンス重視のWordPressサーバーを選択する
信じられないかもしれませんが、 適切なWordPressレンタルサーバーを選択するだけで、サイトのパフォーマンスに大きな違いで出ることがあります。ワーカープロセスの効率はCPUとRAMに直接関係しているため、最新のハードウェアを備えた最新のサーバーでサイトをホストすると、ワーカープロセスの使用を最適化できます。
WordPressサイトでパフォーマンス重視のレンタルサーバーを選択することが重要である理由として、2つの例をご紹介します。
高性能CPU
PHPはコードの実行にCPUリソースを使用します。これは、CPUが高速であるほど、よりコードが迅速に実行されることを意味します。Kinstaでは、Google Cloudの最速サーバーであるコンピューティグ最適化（C2）およびCompute Engine 汎用マシン（C3D）VMを使用しています。
追記）これらのVMは、3.8 GHzオールコアターボで動作する最新のIntel Xeonプロセッサが搭載されています。独自に実施したベンチマークテストでは、C2マシンが従来のN1マシンを2〜4倍上回り、C3Dマシンの応答時間はさらに20～50％向上しました。
高速SSDストレージ
ディスクI/O速度も、コード実行とデータベースクエリに直接影響を与え得る要素です。データベースが十分なIOPS（1秒あたりの入出力操作）のないクラウドベースのSSDまたは低速のハードディスクに保存されている場合、ワーカープロセスはリクエストの処理により多くの時間を費やすことになります。
Kinstaでは、Google Cloud Platformの高性能SSDストレージを採用し、WordPressサイトが高速ディスクI/Oを利用できるようにしています。
4. パフォーマンス改善のプロに協力を求める（任意）
サイトにおけるパフォーマンスの問題に対処する方法がわからない場合は、資格のあるパフォーマンスのプロに協力を依頼し、問題を診断してもらうことをお勧めします。
プロにお願いして、New RelicやWordPressプラグインQuery Monitorなどの高度なモニタリングツールを使用して、コード内のボトルネックの特定をサポートしてもらいましょう。
個々のPHPプロセスとデータベースクエリを精査することにより、サイトのワーカープロセスに高い負荷をかけているコードブロックやそれに関連する機能を特定することができます。
ワーカープロセス最適化についてまとめておきます。以下のヒントが参考になるはずです。
- ワーカープロセスとともに、CPUとRAMもスケールアップする必要があります。CPU使用率が100％に達している状態でPHPワーカーを追加してもパフォーマンスは向上しません。
- パフォーマンス重視のレンタルサーバーを利用すると、数々のパフォーマンスの問題を解決できます。
- ページキャッシュとオブジェクトキャッシュにより、ワーカープロセスの負荷を大幅に削減できます。
- 質の高いWordPressプラグインとテーマを使用すると、サイトにおける不要なコードの膨張を減らすことができます。
- 必要に応じて、パフォーマンスに精通するプロと協力して、複雑な問題を特定、解決しましょう。
ワーカープロセスが不十分だとどうなるのか
WordPressサイトの高速かつ信頼性の高いパフォーマンス を実現するために、十分なワーカープロセスがあることを確認することが重要です。ワーカープロセスが処理しきれないでいると、処理待ちの仕事がどんどんたまります。
ワーカープロセスの制限に達すると、キューから古いリクエストが押し出され、504エラーやリクエスト処理の失敗が発生する可能性があります。
ワーカープロセスの不足が原因で発生するもう1つの一般的なエラーが、502 Bad Gatewayです。ワーカープロセスのキューでの待機時間が60秒のタイムアウトを超えたときにこのエラーが発生するため、504エラーとは少し異なります。
このようなエラーは、訪問者のユーザーエクスペリエンスを低下させるだけでなく、サイトのSEOにも悪影響を及ぼすことがあります。
ページの読み込み低下やエラー発生の原因には、さまざまな要因が関係しています。たとえば、キャッシュされていないリクエストがデータベースから大量のデータを取得する必要がある場合、結果としてクエリが完了するまでに20〜30秒かかることがあります。
そんな状況では、ワーカープロセスは少なくとも30秒間これにかかりっきりになります。サイトにワーカープロセスが2つしかない場合、このような非常に時間のかかるリクエストが2〜3あるだけで十分にエラーが発生し得ます。
これを解決するには、MySQLデータベースを最適化し、さらに、CPUが使い果たされていない状況ではワーカープロセスの数を増やすとパフォーマンスが向上します。
必要なワーカープロセスの数を見積もる
Kinstaのプランには、一定数のワーカープロセスが含まれています。それぞれに設定されるワーカープロセスの数は、過去数年間をかけて収集したリソース使用状況データに基づいています。一般的に、記事、静的ページ、ポートフォリオなど、主に静的なコンテンツを持つサイトでは、多くのワーカープロセスは必要ありません。
オンラインストアやディスカッションフォーラムなどの動的な機能を備えた大規模なWordPressサイトの場合、4つのワーカープロセスが出発点として妥当であると思われます。ただし、サイトごとに独自のテーマ、プラグイン、データベースクエリ、そしてキャッシュできるコンテンツとできないコンテンツの比率の違いがあるため、サイトごとに状況は異なります。
場合によっては、高速かつ安定したパフォーマンスのために、普通よりも多くのワーカープロセスが必要になることがあります。Kinstaを利用する上でサイトに必要なワーカープロセスの数がわからない場合は、Kinstaのセールスおよびサポートスタッフが調査をお手伝い致します。
ワーカープロセスチャート
MyKinsta分析画面にはワーカープロセスチャート（「ワーカープロセスの制限」と表示されている項目）があります。ここでは、PHPエンジンが、予め割り当てられた最大ワーカープロセス数に達した回数がエラーログとして確認できます。パフォーマンス最適化の施策がワーカープロセス使用状況に影響を与えているか確認するのに便利です。
たとえば、サイトのPHPバージョンを5.6から7.4に切り替えた場合、PHP 7.4は5.6よりはるかに高速であるため、ワーカープロセスの上限到達回数が低下する可能性があります。
同様に、パフォーマンスの専門家に協力を依頼することで長いデータベースクエリを修正し、より軽量なテーマに切り替えた場合、ワーカープロセスチャートを使用して、最適化の前後の違いを確認できます。
キャッシュ分析チャート
MyKinstaのキャッシュ分析レポートを使用して、キャッシュヒット、バイパス、キャッシュミス、有効期限を確認することもできます。ここから得られるデータは、サイトのワーカープロセスの使用状況を最適化するときに特に便利です。
クエリ文字列とキャッシュバイパス
デフォルトでは、 https://kinstalife.com/?query=123のようなクエリ文字列を含むURLは、ページキャッシュをバイパスします。場合によっては、このクエリ文字列により、PHPとCPUの使用量が大幅に増えることがあります。
たとえば、Facebookからリンクにアクセスすると、URLの末尾に?fbclid=というクエリ文字列が表示されることがよくあります。同様に、メールニュースレターのリンクをクリックすると、UTMパラメータが表示される場合があります。
サイトの記事が口コミで広まり、クエリ文字列を伴った状態でアクセスされると、キャッシュ分析レポートで特定のURLを識別できます。
この情報を確認した上で、Kinstaスタッフまでお問い合わせ頂ければ、特定のURLを強制的にキャッシュして、ワーカープロセスの負荷を軽減することができます。
リソースを多く消費するプラグインを特定する
場合によっては、キャッシュ分析チャートを使用して、リソースを多く消費するプラグインやプロセスを特定することも可能です。
たとえば、上位のキャッシュバイパスURLが特定のプラグインのディレクトリ内にあるファイルを指していることがわかった場合、そのプラグインがワーカープロセスの高い使用率に関与している可能性が高いでしょう。
キャッシュバイパスリストにプラグイン関連のリクエストが多数見られる場合には、開発者と協力して問題に対処するか、使用するリソースが少ないプラグインに切り替えることができます。
まとめ
高速なWordPressサイト維持のためには、バックエンドの効率を最大化する必要があります。ワーカープロセス数、CPU使用率、コード最適化のバランスを取り、ワーカープロセスを適切に利用すれば、WordPressは非常にパフォーマンスの高いCMSとなり得ます。
必要なワーカープロセスの数についてご質問がございましたら、また、ワーカープロセスの不足が原因でエラーが発生していると思われる場合は、スタッフまでサポートチケットを使ってお問い合わせください。
次はあなたの番です。WordPressサイトをスムーズに稼働させるためにどのような最適化戦略を使用していますか？コメント欄から教えてください！
コメントを残す