メインコンテンツにスキップ
Kinsta.comコミュニティ新しいタブで開くMyKinsta新しいタブで開く

PHP

ワーカープロセス

サイトのPHPコードは、ワーカープロセスによって処理されます。これには、ページの構築、バックグラウンドタスクの処理、データベースへのクエリなどが含まれます。

ワーカープロセスは、スーパーのレジに例えることができます。各ワーカープロセスは一度に1名の買い物客（リクエスト）にしか対応することができません。買い物客の数がレジ数よりも多ければ、買い物客は列に並んで、順次処理が行われるのを待つことになります。

ワーカープロセスは、サイトがコンテンツのほとんどをキャッシュしていない、あるいはキャッシュできない場合に特に効果を発揮します。サイトが動的であればあるほど、より多くのワーカープロセスが求められます。通常キャッシュされたコンテンツにはワーカープロセスは不要で、サイトが情報を取得したり変更したりするためにデータベースにクエリを実行する際にのみ必要になります。

WordPressサイトでは、ワーカープロセスを増やすことで自動的にパフォーマンスが改善されるというわけではありません。以下のような考慮すべき点が多数あります。

  • キャッシュ─効果的なキャッシュは、リクエストごとに動的にコンテンツを生成するのではなく、 キャッシュされたコンテンツを提供することで、ワーカープロセスの負荷を軽減します。これにより、特に頻繁にアクセスされるリソースのパフォーマンスが大幅に改善されます。
  • ハードウェア─CPUやメモリ（RAM）、ディスクの速度など、サーバー上で使用可能なハードウェアリソースは、ワーカープロセスのパフォーマンスに直接影響します。リソースが不足すると、処理時間が遅くなったり、パフォーマンスが低下したりします。
  • ウェブサーバーの設定─ウェブサーバーの設定とPHPとの相互作用は、ワーカープロセスのパフォーマンスに影響します。
  • データベースの速度─PHPアプリケーションは、動的コンテンツをレンダリングするため、MySQLデータベースからデータを頻繁に取得します。データの取得速度は、データベースの構成やクエリの最適化、 データベースサーバーの性能などによって決まります。これは、アプリのパフォーマンスに直接影響を与えます。
  • PHPバージョン─PHPのバージョンが新しくなると、通常パフォーマンスの向上、バグの修正、 セキュリティの更新により、ワーカープロセスのパフォーマンスが向上します。

弊社は、お客様のサイトパフォーマンスを常に重要視しています。ワーカープロセスのパフォーマンスを最大化し、PHPリクエストを最小化するため、以下のような技術を採用しています。

  • CDNとサーバーの両方のレベルでページキャッシュを提供し、カスタマイズ可能なルールでキャッシュ効率を最大化します。
  • Google Cloudの最速CPUを搭載したGCPのプレミアムサーバー（C2およびC3D仮想マシン）を使用し、ワーカープロセスを効率的な実行を後押しします。
  • スケーラブルなインフラストラクチャで、WordPressサイトのワーカープロセスのパフォーマンス最大化に十分なCPUリソースを確保しています。
  • Google Cloud Platform（GCP）のプレミアムネットワークインフラストラクチャを活用し、レイテンシを最小限に抑えます。これにより、MySQLサーバーやウェブサーバーなど、インフラストラクチャのさまざまなコンポーネント間のデータ転送にかかる時間が大幅に短縮されます。
  • 高度に最適化されたMySQLサーバーをローカルにホスティングすることで、ネットワークレイテンシが短縮され、データの検索および処理速度が向上します。
  • MySQLサーバーには、ディスクI/O操作を減らすことでデータベースのパフォーマンスを向上させるInnoDBバッファプールがあります。ディスクからではなくメモリから高速にデータにアクセスすることができるため、読み取りおよび書き込み操作の効率が向上し、MySQLデータベースの全体的なパフォーマンスも改善されます。
  • パフォーマンス向上を考慮し、PHPの最新バージョンを常にサポートしています。

WordPressとワーカープロセス

WordPressサイトのキャッシュされていないリクエストは、通常以下のように処理されます。

  1. 訪問者がページにアクセスする、またはページ上でアクションを実行する（かごに商品を追加する、フォームを送信するなど）。
  2. ウェブサーバー（弊社の場合はNginx）がそのリクエストを受け取る。
  3. ウェブサーバーがリクエストをPHPに渡す。
  4. PHPがMySQLデータベースに問い合わせ、必要な情報を取得したり、必要な更新を行ったりする。
  5. PHPがテーマのPHPファイル（および該当する場合はプラグインファイル）を使ってHTMLページを生成する。
  6. PHPがレンダリングされたHTMLページをウェブサーバーに返す。
  7. ページが訪問者に提供される。

上記のプロセスでは、4つ目の手順が最も時間とリソース（CPUとRAM）を消費します。効率的なPHPコードとデータベースクエリで最適化されたサイトでは、高速に処理することができます。

一方、最適化されていないPHPコードや、非効率的なデータベースクエリの多くは、4つ目の手順に多くの時間を要します。処理に時間がかかるリクエストは、長時間ワーカープロセスを独占することになります。

必要なワーカープロセス数の見積もり

サイトにどのくらいのワーカープロセスが必要になるかは、サイトがいかに動的であるか、コードの最適化（リクエストの処理速度）の度合い、サイトのトラフィックの種類など、いくつかの要因によって異なります。最適化されたサイトでは、リクエストが素早く処理され、ワーカープロセスが次々に解放されていきます。

ECサイト、フォーラム、学習サイト、会員制サイトなどの高度に動的なサイトは、静的な（例えば、単に情報を掲載した）サイトよりも、通常、多くのワーカープロセスが求められます。サイトが「多忙を極める」ほど、多くのワーカープロセスが必要ということになります。

各プランのワーカープロセス

各プランに付帯するワーカープロセス数は以下のとおりです。

プランワーカープロセス
スターター2
プロ2 / サイト
ビジネス14 / サイト
ビジネス24 / サイト
ビジネス36 / サイト
ビジネス46 / サイト
エンタープライズ8以上 / サイト
シングルサイトプラン6
エージェンシープラン6 / サイト

また、ワーカープロセス数を指定できるカスタムプランもご案内しています。ご希望の方は、営業部門までお気軽にお問い合わせください。

ワーカープロセス、CPU、RAM

ワーカープロセスの調整の際には、CPUとRAMといったリソースを考慮する必要があります。ワーカープロセスを増やしても、ワーカープロセスを支えるためにサーバーが多くのCPUとRAMを必要とする場合は、 リクエストを効率的に処理することができず、パフォーマンスのボトルネックになります。

弊社独自のLXDコンテナは、十分なCPUとRAMリソースで構成されています。さらに、Google Cloudの最速CPUを搭載したC2仮想マシンおよびC2D仮想マシンを使用することで、サイトのワーカープロセスがより一層効率的に機能します。スケーラブルなインフラストラクチャで、WordPressサイトのワーカープロセスが最高のパフォーマンスを発揮できるよう十分なCPUが確保されます。

ワーカープロセスに関連するパフォーマンスの問題を特定する

大量のリクエストの流入、長時間のプロセス稼働、またはその両方により、キューに多くのリクエストが蓄積すると、サイトのパフォーマンスに問題が生じ、502または504エラーが発生する可能性があります。

弊社のAPMツールやQuery Monitorプラグインを使用することで、パフォーマンスの問題や遅いクエリを特定することができます。また、問題を診断する際には、パフォーマンスの改善に精通した開発者の力を借りることをお勧めします。

MyKinstaでAPMツールを利用
MyKinstaでAPMツールを利用

ワーカープロセス数上限到達回数

MyKinstaで「WordPressサイト」＞（サイト名）＞「分析」＞「パフォーマンス」タブを開くと、「ワーカープロセス数上限到達回数」を確認することができます。ワーカープロセスは、10秒間稼働していない状態が続くと自動的に終了し、再び必要時には即座に再作成されます。「ワーカープロセス数上限到達回数」のグラフは、サイトに割り当てられたワーカープロセスの最大数に何度達したかを示します。

例えば、ビジネス1プランをご利用の場合、最大4つのワーカープロセスをご利用いただけます。3つのワーカープロセスが使用されている状態で、さらにワーカープロセスを必要する別のリクエストが発生した場合は最大数に到達することになり、ワーカープロセスの上限に達したインシデントとしてログに記録されます。

このグラフは、ワーカープロセスが上限に達した回数を記録しているだけで、どれだけの時間使用されていたかを記録するわけではありません。このため、ワーカープロセスの動作を完全に把握できない可能性があります。

例えば、サイトのトラフィックが急増し、すべてのワーカープロセスが一度もアイドル状態になることなく、1時間稼働したとします。この場合、ワーカープロセスはずっと稼働していたにもかかわらず、「ワーカープロセスが上限に達した1つの例」として記録されます。30分後にトラフィックが減少し、1つのワーカープロセスが10秒間アイドル状態になると、自動的に終了します。しかし、そのワーカープロセスが1分後に再度必要になると、最大値に再び達することになり、上限に達した例としてログに記録されます。

サイトのパフォーマンスを調査し、サイトが継続的にワーカープロセスを使用しているかどうかを判断するには、SSH接続でツールを使用して、動作を監視することができます。例えば、以下は、0.3秒ごとに稼働しているワーカープロセスを監視するコマンド例です。

watch -n 0.3 “ps aux | awk ‘\$(NF-2) ~ /php-fpm/ && \$(NF-1) ~ /pool/ && \$8 ~ /R/ { print \$0 }’ | wc -l"

このコマンドを終了するには、CMD + CまたはCTRL + Cを押し、離してください。

ワーカープロセス数上限到達回数
ワーカープロセス数上限到達回数

キャッシュ分析

MyKinstaの分析画面の「キャッシュ」タブでは、サイトでのキャッシュ比率やリクエスト数上位のキャッシュバイパスなどを確認することができます。

キャッシュ比率チャート
キャッシュ比率チャート
リクエスト数上位のキャッシュバイパス一覧
リクエスト数上位のキャッシュバイパス一覧

ワーカープロセス使用量の削減と最適化

キャッシュ

キャッシュを使い、サイトを最適化し、必要なワーカープロセスの数を減らすことができます。キャッシュされたコンテンツにはワーカープロセスは必要ないので、できる限りキャッシュを行うことが推奨されます。

ページキャッシュ

すべてのサイトでNginxのFastCGIキャッシュモジュールを使用し、超高速パフォーマンスを実現します。

オブジェクトキャッシュ

データベースのためにRedisのような永続的オブジェクトキャッシュを用意することで、パフォーマンスが向上し、ワーカープロセスの必要性が減ります。オブジェクトキャッシュがなければ、MySQLデータベースのクエリは、同じクエリと結果であっても、リクエストごとに実行されることになります。

Redisはデータベースクエリの結果をRAMに保存します。これにより、PHPはクエリを何度も実行することなく、その結果を取得可能です。データベースへのクエリを繰り返す必要がなくなることで、リソース削減につながり、ワーカープロセスはより効率的にリクエストを処理することができます。

Redisキャッシュのサイトへの追加方法はこちらをご覧ください。

コードの最適化

サイトのコードを最適化し、可能な限りの効率性を追求することも重要です。これは、独自のコード、テーマおよびプラグインのコードなど、すべてに該当します。確信が持てない場合は、開発者にサイトのコードの見直しを依頼することをお勧めします。

カスタムコード

プラグインやテーマにカスタムコードスニペットが含まれている場合、それが本当に必要なものか、きちんと書かれているかを確認してください。

プラグイン

サイトで使用しているプラグインをよく見て、本当に必要なものか、機能が重複していないか、必要な機能に対して最適な選択肢であるかどうかを確認しましょう。WordPressやPHPの最新版と互換性のないプラグインがある場合は、他の選択肢を検討する必要があるかもしれません。使用していないプラグインがある場合は、削除することをお勧めします。

テーマ

可能な限り、軽量でパフォーマンスの高いテーマを選択してください。別のプラグインで実装するのが好ましい機能（SEO、検索フィルタリング、カスタムフィールド、画像スライダー/スライドショーなど）が組み込まれたテーマや、必要のない機能により煩雑になっているテーマは避けましょう。

PHPのバージョンアップ

最新バージョンのPHPを使用することで、パフォーマンスの向上が期待できます。PHPベンチマークからわかるように、各PHPバージョンは前のバージョンよりも高速である傾向にあります。

KinstaのCDNを有効にする

弊社CDNを有効にすると、サイトの効率と最適化がさらに進みます。弊社CDNは、Cloudflareを土台としたHTTP/3対応の高性能CDNで、すべてのお客様に追加料金なしでご利用いただけます。有効化することで、世界各地から静的アセットを高速配信することができます。

パフォーマンスに精通した開発者への相談

サイトの最適化に精通している方には必須ではありませんが、検討に値する選択肢です。信頼できる開発者にサイトのあらゆる側面の分析、ボトルネックの特定、解決策の実行を一任することもできます。

PHPの再起動

弊社では、自己修復PHPというシステムを採用しています。これは、不意に502エラーが発生した時、またはその他の何らかの問題が発生した時に効果を発揮します。PHPがダウンすると、弊社システムにより自動で再起動が試みられます。多くの場合、この処理により問題が解決できます。

まれに、上記では対応できない大きな問題が発生することがあります。そのような状況では、弊社シスアドチームが対応できるよう、自動的にログが記録されます。また、これとは別に、MyKinstaからワンクリックでサイトごとにPHPを再起動することができます。

PHPを手動で再起動する

WordPressサイトのPHPを再起動するには、以下の手順に従ってください。

  1. MyKinstaにログインします。
  2. 「WordPressサイト」をクリックし、PHPを再起動するサイトを選択します。
  3. 「ツール」タブに移動し、「PHPの再起動」セクションを見つけます。
  4. 「PHPの再起動」ボタンをクリックします。
MyKinstaでPHPを再起動
MyKinstaでPHPを再起動

PHPの再起動には5～10秒程度かかります。完了すると、画面下に通知が表示されます。

注）変更を確認するには、サイトキャッシュのクリアも必要になります。

KinstaのPHP制限

マネージドWordPressホスティングを提供する企業として、弊社ではWordPressサイトに最適化されたPHP設定を行っています。特定のPHP要件をお持ちのお客様は、弊社カスタマーサポートまでお気軽にご相談ください。

弊社では、PHP8.0, 8.1, 8.2 , 8.3をサポートしています。PHPのデフォルト設定は以下の通りです。

  • memory_limit = 256M
  • post_max_size = 128M
  • upload_max_filesize = 128M
  • max_input_vars = 10000
  • max_execution_time = 300

WordPressプランによっては、必要に応じて上記の値を引き上げることができます。弊社カスタマーサポートまでお気軽にご相談ください。

KinstaのPHPメモリ制限

弊社デフォルトのPHPメモリ制限は256MBに設定しています。これは、ほとんどのWordPressプラグインとサイトには十分なサイズです。この制限は、PHPスクリプトがメモリを過剰に消費するのを回避するために設定されています。制限を高く設定しすぎると、誤った設定や壊れたスクリプトがメモリを消費しすぎて深刻な問題を引き起こす可能性があります。

弊社でサイトを正しく設定している場合は、メモリ制限エラーが発生することはありません。メモリ制限エラーに遭遇した場合は、WordPresの設定を確認し、誤ってメモリ制限が低く設定されていないかを確認してみてください。

ビジネスプランをご利用で、サイトのPHPメモリ制限を引き上げたい場合は、アドオンを購入すると、メモリ制限を256MBから512MBに増やすことができます。ご希望の方は、MyKinstaのライブチャット、またはメール（[email protected]宛）にてご連絡ください。スターターまたはプロプランの場合は、ビジネスプランへのアップグレードが必要です。

PHPメモリ制限の確認と変更

WordPressの現在のPHPメモリ制限を確認するには、WordPressの管理画面にログインし、「ツール」＞「サイトヘルス」に移動します。

「情報」タブを開き、「サーバー」セクションの横にある矢印アイコンをクリックします。セクションが展開され、PHPのメモリ上限が表示されます。

メモリ制限が256Mより低い場合は、wp-config.phpファイルのWP_MEMORY_LIMITが変更されていないか確認し、必要であれば調整してください。

メモリ制限が256Mであるにもかかわらず、PHPのメモリに問題がある場合は、プラグインとテーマをチェックしテストすることをお勧めします。ステージング環境を使用して、安全にプラグインとテーマを無効化および再有効化し、メモリ使用量の原因を特定することができます。

エラーが解決せず、原因が特定できない場合は、弊社カスタマーサポートまでお気軽にご相談ください。

PHPのバージョン変更

MyKinstaから簡単にサイトのPHPバージョンを変更することができます。

PHPを切り替える準備が整ったら、MyKinstaにログインして「WordPressサイト」＞（サイト名）＞「ツール」に移動します。

「PHPエンジン」の下にあるドロップダウンをクリックし、サイトに使用したいPHPのバージョンを選択します。

MyKinstaでPHPバージョンを変更
MyKinstaでPHPバージョンを変更

表示されるポップアップ画面で、右下の「PHPバージョン間の切り替え」をクリックして変更します。

PHPバージョンの変更を確認
PHPバージョンの変更を確認

変更が完了すると、PHPエンジンの再起動が実行されます。サイトのバックエンド（WordPress管理画面）が数秒間ダウンすることがありますが、サイトのフロントエンドは稼働しているため、訪問者側でサイトがダウンすることはありません。

変更処理中にMyKinsta内の他のページに移動することは可能ですが、PHPエンジンが再起動するまでは、キャッシュ管理などの一部の操作は行えません。

変更が完了したら（通常3分以内に完了します）、MyKinsta上に通知が表示されます。

PHPモジュール

弊社でホストするWordPressサイトには、以下のPHPモジュールがデフォルトでインストールされています。

  • bcmath
  • bz2
  • calendar
  • Core
  • ctype
  • curl
  • date
  • dom
  • exif
  • FFI
  • fileinfo
  • filter
  • ftp
  • gd
  • gettext
  • hash
  • iconv
  • igbinary
  • imagick
  • imap
  • intl
  • json
  • libxml
  • mbstring
  • mysqli
  • mysqlnd
  • openssl
  • pcntl
  • pcre
  • PDO
  • pdo_mysql
  • Phar
  • posix
  • readline
  • redis
  • Reflection
  • session
  • shmop
  • SimpleXML
  • soap
  • sockets
  • sodium
  • SPL
  • standard
  • sysvmsg
  • sysvsem
  • sysvshm
  • tokenizer
  • xml
  • xmlreader
  • xmlwriter
  • xsl
  • Zend OPcache
  • zip zlib

ionCubeはデフォルトではインストールされていませんが、サイトでPHP 8.1を実行している場合、MyKinstaで有効にすることができます（「WordPressサイト」＞（サイト名）＞「ツール」＞「ionCube Loader」で「利用する」をクリック）。

上記にない特定のPHPモジュールについてご質問がございましたら、弊社カスタマーサポートまでお気軽にお問い合わせください。

この記事は役に立ちましたか？