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の最新バージョンを常にサポートしています。

ワーカープロセスとPHPメモリ制限

ワーカープロセスの数は、PHPメモリ制限とは異なります。ワーカープロセスは、ウェブからのリクエストを処理する個々のプロセスであるのに対し、メモリ制限は単一のPHPスクリプトが実行中に使用できるメモリ（RAM）の最大量を意味します。

ワーカープロセスは、複数のリクエストを同時に処理することで並行性を管理しますが、 PHPのメモリ制限は個々のスクリプトのメモリ使用量を制限することで、リソースの割り当てを管理します。これにより、単一のスクリプトがサーバーで使用可能なすべてのメモリを消費するのを防ぎます。

PHPのメモリ制限は、大規模なデータベースクエリの実行、大規模なファイルアップロードの処理、複雑な計算の実行など、大量のメモリを必要とするスクリプトに重要になります。サイトでメモリ制限エラーが発生した場合、ワーカープロセスの数を増やしてもこの問題は解決されません。メモリ制限を確認し、必要応じて引き上げるか、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サイト、フォーラム、学習サイト、会員制サイトなどの高度に動的なサイトは、静的な（例えば、単に情報を掲載した）サイトよりも、通常、多くのワーカープロセスが求められます。サイトが「多忙を極める」ほど、多くのワーカープロセスが必要ということになります。

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

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

1サイト向けプラン

複数サイト向けプラン

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

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

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

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

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

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

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

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

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

例えば、WP 5プランをご利用の場合、最大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がダウンした場合、弊社シスアドチームが対応できるよう、自動的にログが記録されます。また、これとは別に、MyKinstaからワンクリックでサイトごとにPHPを再起動することができます。

PHPを手動で再起動する

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

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

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

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

PHPの制限

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

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

PHPメモリ制限

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

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

サイトのPHPメモリ制限を引き上げたい場合は、PHPメモリアドオンを購入すると、月額50ドルでメモリ制限を256MBから512MBに増やすことができます。

このアドオンを購入するには、MyKinstaで「WordPressサイト」＞（サイト名）＞「アドオン」画面に移動し、「PHPメモリ」セクションの「変更する」をクリックします。

「チャットを開く」をクリックすると、アカウント管理部門とのやり取りが開始され、アドオンの手続きを行います。

また、MyKinstaのライブチャット、またはアカウント管理部門（[email protected]）にメールでアドオンの追加を依頼することも可能です。

WordPressホスティングプランのご利用開始から、30日以内にPHPメモリアドオンを削除した場合、日割り計算で料金が算出され、翌月のお支払い額に加算されます。WordPressホスティングプランのご利用開始から30日以上経過している場合は、現在の請求サイクルの残りの日数分の料金がアカウント残高にクレジットとして加算されます。このクレジットは、次回のお支払い料金と相殺されます。詳細については、WordPressホスティングの返金保証をご覧ください。。

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

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

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

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

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

エラーが解決せず、原因が特定できない場合は、弊社カスタマーサポートまでお気軽にご相談ください。ログを確認し、サーバー側の問題を解決するお手伝いをさせていただきます。

PHPのバージョン変更

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

MyKinstaでは、「WordPressサイト」画面から、ステージング環境を含む1つまたは複数の環境のPHPバージョンを同時に変更することができます。環境名の横にあるチェックボックスを使用して、PHPバージョンを変更したい環境を選択し、一覧右上の「操作」をクリックして、「PHPバージョンの変更」を選択します。

表示されるウィンドウで変更するバージョンを選択し、「PHPバージョンを変更」をクリックします。

変更が適用されると、その旨を伝えるメッセージが表示されます。

また、「WordPressサイト」＞（サイト名）＞「ツール」画面で、サイトのPHPバージョンを個別に変更することもできます。「PHPエンジン」セクションにある「変更」をクリックし、変更するPHPバージョンを選択します。

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

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

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

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

PHP定数

PHP定数は、プログラム全体で変更できない固定値です。複数の場所からアクセスできるため、異なるファイルや関数の中で同じ定数を使用することができます。

BedrockやTrellisのような非標準的なWordPressのセットアップを使用している場合、DB_PASSWORD変数を検出することができないため、以下の状況でデータベースのパスワードを更新することができません。

• 既存環境の複製によるサイトの追加
• 既存環境の複製によるステージング環境の追加
• 本番環境へのステージング環境の反映
• バックアップの復元
• MyKinstaのデータベースパスワードの変更

これを解決するには、データベースパスワードを保存するためにPHP定数SERVER_SECRET_DB_PASSWORDを使用することができます。config.phpファイル内でこの定数を定義すると、サイトのデータベースパスワードを識別するためにこの定数が使用されます。

define('DB_PASSWORD', defined('SERVER_SECRET_DB_PASSWORD') ? SERVER_SECRET_DB : 'asdijfhkjasdbfkjhbajiksd' );

弊社サーバーで使用する以下のPHP定数を定義することができます。

• SERVER_SECRET_DB_USER
• SERVER_SECRET_DB_PASSWORD
• SERVER_SECRET_DB_HOST
• SERVER_SECRET_DB_NAME

例えば、config.phpファイルで以下のように定数を定義することができます。

define('DB_NAME', defined('SERVER_SECRET_DB_NAME') ? SERVER_SECRET_DB_NAME : 'newsitetest');
define('DB_USER', defined('SERVER_SECRET_DB_USER') ? SERVER_SECRET_DB_USER : 'newsitetest');
define('DB_PASSWORD', defined('SERVER_SECRET_DB_PASSWORD') ? SERVER_SECRET_DB : 'asdijfhkjasdbfkjhbajiksd' );
define('DB_HOST', defined('SERVER_SECRET_DB_HOST') ? SERVER_SECRET_DB_HOST : 'localhost');

あるいは、以下のように定義することも可能です。

define('DB_NAME',SERVER_SECRET_DB_NAME);
define('DB_USER',SERVER_SECRET_DB_USER);
define('DB_PASSWORD',SERVER_SECRET_DB_PASSWORD);
define('DB_HOST',SERVER_SECRET_DB_HOST);

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、8.2、または8.3を実行している場合、MyKinstaで「WordPressサイト」＞（サイト名）＞「ツール」＞「ionCube Loader」で「利用する」をクリックして有効化できます。

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