...
ウェブホスティングのロゴ

WordPress が CPU バウンドになることが多い理由 – 典型的なボトルネックの技術的分析

WordPress CPU 各リクエストが PHP コード、データベースクエリ、および多くのフックを実行し、計算時間を消費するため、すぐにボトルネックになります。具体的に、どこがボトルネックになっているのかを示します。 CPU時間 失われるもの、そしてキャッシュ、クリーンなコード、適切なホスティング設定によってそれを大幅に削減する方法についてご説明します。.

中心点

以下の要点から、主な原因と対策の概要を簡単に確認できます。.

  • ダイナミクス 静的な配信ではなく、リクエストごとにCPU負荷が高くなります。.
  • プラグイン また、ページビルダーはコードパスとクエリを増加させます。.
  • データベース-バラストとインデックスの欠如により、クエリの実行時間が長くなります。.
  • キャッシング 複数のレベルで PHP のワークロードを大幅に削減します。.
  • WP-クーロン, 、ボット、API は、ページビューごとに追加の負荷を生み出します。.

静的対動的：WordPress がより多くの CPU を必要とする理由

静的サイトはファイルを読み込んで直接送信しますが、WordPress は呼び出しごとに ピーエッチピーエス を起動し、クエリを実行し、フックを処理します。監査では、わずかな追加ロジックでもリクエストあたりの CPU 時間が大幅に長くなることを確認しています。各フィルターとアクションはコードパスを拡張し、関数呼び出しの数を増加させるため、 応答時間 リクエストごとに伸びます。ページキャッシュがない場合、各ページはパイプライン全体を処理し、サーバーレベルで回避可能なミリ秒を追加します。そのため、私は早い段階で動的パスと静的パスの分離を優先し、可能な限り PHP の実行を削減しています。.

CPU ドライバーとしてのプラグイン：大量のコード、多数のフック

各プラグインはスタックを拡張し、多くの場合グローバルにロードされ、すべてのページでアクティブになります。これにより、 CPU 負荷がかかります。そのため、部分ページでのみ必要な機能を確認し、必要に応じてロードしています。大量のデータに対するループ、繰り返されるオプションの読み取り、過度なロギングは、リクエストごとに不要な作業を生み出します。特に、ページビルダー、フォームスイート、ショップ、メンバーシップモジュールは、多くの依存関係をもたらし、 実行時間. 実際には、initフック、オートロード、および重複した関数ブロックに焦点を当てた監査を行うことが有効であり、私はこれらを意図的に無効化または置換しています。.

最適化されていないデータベースと高価なクエリ

時間の経過とともに、リビジョン、スパムコメント、孤立したメタデータ、期限切れのトランジェントが データベース. これにより、スキャン時間が長くなり、キャッシュヒットが失われ、ソートや結合の際にCPU負荷が顕著に増加します。私は定期的にリビジョンを制限し、コメントテーブルをクリーンアップし、古いトランジェントを削除しています。また、頻繁な検索のインデックスをチェックし、フィルターなしでテーブル全体を走査するクエリを最適化しています。クリーンなスキーマとターゲットを絞ったインデックスにより、 クエリ時間, 、PHP は結果を待つ時間が少なくなります。.

キャッシュレイヤー：その効果とCPUの節約量

私は段階的なキャッシュを採用しており、PHPの実行頻度を減らし、 CPU 1秒あたりのリクエスト数を増やせるよ。ページキャッシュは完成したHTMLを配信し、オブジェクトキャッシュは頻繁なクエリ結果を保持し、オペコードキャッシュはスクリプトの解析を節約するんだ。ブラウザとCDNのキャッシュは、オリジンへの負荷を軽減し、ファーストバイトまでの時間を改善するよ。 重要なのは、正しい TTL 戦略と、ログインユーザーやショッピングカートは選択的に動的な状態を維持すること。そうすることで、平均 応答時間 ピーク負荷を管理可能な状態に保ちます。.

レベル 例 負担軽減 典型的な利益 ヒント
ページキャッシュ 静的HTML ピーエッチピーエス-実行 非常に高い ログインユーザー向けバイパス
オブジェクト・キャッシュ Redis/Memcached データベース-Reads 高い キャッシュキーの一貫性を維持する
オペコードキャッシュ オペキャッシュ 解析 & コンパイル ミディアム デプロイ後のウォームキャッシュ
ブラウザ/CDN エッジ上の資産 起源-トラフィック 中～高 TTL、バージョン管理に注意

WP-Cron とバックグラウンドジョブ：負荷のピークを緩和する

wp-cron.php はページアクセス時に実行され、公開、メール、バックアップ、インポートなどのタスクを開始します。これにより、 CPU さらに、リクエストによるトリガーを無効にして、固定間隔のシステムクロンに切り替えます。その後、頻度を減らし、古いジョブを削除し、負荷の高いプロセスを静かな時間帯に分散します。多くの場合、プラグインはスケジュールが厳しすぎて、日常的なサイトの動作を遅くしています。より詳しく知りたい方は、以下をお読みください。 WP-CronによるCPU負荷の不均一 そして、ロングランナーを避けるために、意図的に制限を設けています。.

ボットトラフィックと攻撃：不要な PHP 実行からの保護

ブルートフォース攻撃、スクレイパー、悪意のあるボットは、リクエストごとに発火します。 ピーエッチピーエス そして、実際のユーザーには何のメリットもないにもかかわらず、負荷を増大させています。ログインやフォームのルートには WAF、レート制限、キャプチャを設定し、リクエストを早期に阻止しています。Fail2ban ルールと IP フィルターにより、WordPress が読み込まれる前に攻撃的なパターンをブロックします。さらに、404 ページを短期間キャッシュし、xmlrpc.php を保護することで、既知の攻撃ベクトルの機会を減らしています。これにより、 サーバー負荷 予測可能で正当なトラフィックは、より高速に感じられます。.

外部サービスとAPIコール：I/OがPHPワーカーをブロック

マーケティングスクリプト、ソーシャルフィード、または決済統合がリモートで待機しています。 API これにより、ワーカーがブロックされます。私はタイムアウトを短く設定し、結果をキャッシュし、クエリをサーバー側に間隔を置いて移動します。可能な場合は、PHP リクエストの応答を高速化するために、ブラウザで非同期的にデータをロードします。Webhook およびインポート用のキューにより、フロントエンドリクエストが重い作業を引き受けることを防ぎます。その結果、処理時間が短縮されます。 ランタイム リクエストごとに、ピーク時にはより多くのフリーワーカーが利用可能になります。.

PHPバージョン、シングルスレッド特性、ワーカー設定

最新の PHP 8 バージョンは、より多くの機能を提供します。 パフォーマンス コアごとに、古いインタープリタは明らかに動作が遅くなります。リクエストはシングルスレッドで実行されるため、ワーカーあたりの速度が非常に重要になります。また、スワップや I/O 待ち時間に入ることなく、サーバーが同時に処理できるプロセスの数にも注目しています。シングルコアの速度についてより深く理解するには、以下を参照してください。 シングルスレッド性能, これは、WordPress では特に重要なことです。最新のスタックと、よく考え抜かれたワーカー数によって初めて、私はその可能性を最大限に引き出すことができるのです。 CPU 効率的。.

ホスティングアーキテクチャ：キャッシュプロキシ、PHP-FPM、専用データベース

コア数を増やす代わりに、役割を分離しています。リバースプロキシは キャッシュ, 、独立した PHP-FPM レベル、および独自のデータベースサーバー。この分割により、CPU のピークが相互に増幅されるのを防ぎます。CDN は、アセットのオリジンへの負荷を軽減し、ユーザーへの応答を近づけます。ページ全体のエッジキャッシュにより、繰り返しアクセスする場合の PHP 呼び出しを大幅に削減できます。この基盤により、コードの最適化がより効果的に機能します。 インフラストラクチャー 荷重が均等に分散されています。.

ホスティング会社の変更を計画する時期

PHPのバージョンが古い場合、オブジェクトキャッシュがない場合、またはハードリミットが 労働者数に制限を設ける。また、厳格なI/O制限やキャッシュレイヤーの欠如も、最適化されたサイトの速度を不釣り合いに低下させます。このような場合、プラグインやデータベースがすでに整理されているならば、最新のスタックを導入することで即座に顕著な改善が見られます。また、NVMeストレージと、コアあたりの適切なCPUクロック周波数にも注意を払っています。これらの構成要素がそろって初めて、WordPressは リソース 本当に効率的です。.

PHPのボトルネック：推測ではなくプロファイリング

私は直感ではなく、以下の方法でCPUの問題を解決します。 プロファイリング 機能レベルおよびクエリレベルで。クエリモニター、ログファイル、サーバープロファイラーにより、どのフックと機能が最も長く実行されているかを正確に把握できます。その後、重複作業を削除し、コストのかかる結果をキャッシュし、大量のループを削減します。多くの場合、関数内のローカルキャッシュなど、コードのわずかな変更で数ミリ秒の節約になります。これにより、 合計時間 リクエストごとに、機能を犠牲にすることなく。.

モニタリングと対策の順序

まず、メトリクスから始めます。CPU、RAM、I/O、応答時間、リクエストレートが ベース 決定のために。次に、プラグインとテーマを確認し、重複を削除し、重い候補を個別にテストします。次に、ページキャッシュとオブジェクトキャッシュを有効にし、オペコードキャッシュを保護し、キャッシュヒット率と TTL を確認します。その後、データベースをクリーンアップし、インデックスを設定し、wp-cron を実際のシステムサービスに移します。 最後に、PHP-FPM パラメータを最適化し、コードのボトルネックを解消し、テストを行います。 スケーリング 負荷がかかっている

PHPワーカーの適切なサイズ設定

ワーカーが少なすぎると待ち行列が発生し、多すぎると コンテキストの切り替え および I/O 印刷。私は、典型的な並列性、キャッシュヒットの割合、およびリクエストあたりの平均 PHP 時間を測定します。その後、ピークを吸収し、RAM を最大限に活用しないワーカー数を選択します。また、リーキープロセスが定期的に再起動するように、最大リクエスト数とタイムアウトを設定します。詳細については、以下の記事をご覧ください。 PHPワーカーのボトルネック, スループットと安定性のバランスについて詳しく説明している。.

オートロードオプションとトランジェント：wp_options の隠れた CPU コスト

見過ごされがちな障害は、自動ロードされるエントリです。 wp_options. autoload = yes の設定があるものはすべて、必要かどうかに関係なく、リクエストごとに読み込まれます。マーケティング用トランジェント、デバッグフラグ、設定ブロックが数十メガバイトにも膨れ上がった場合、読み込みだけでかなりのコストがかかります。 CPU およびメモリ。大きなデータを autoload = no に設定し、トランジェントを定期的にクリーンアップし、オプショングループを合理的に整列することで、負荷を軽減しています。 get_option() を頻繁に呼び出すプラグインについては、ローカルで短命のインリクエストキャッシュを使用し、複数のアクセスを 1 つの読み取りにまとめます。その結果、関数呼び出しが少なくなり、Serde の負荷が軽減され、処理時間が大幅に短縮されます。 応答時間.

フラグメントおよびエッジキャッシュ：動的要素を意図的にカプセル化

すべてのページを完全にキャッシュできるわけではありませんが、一部はキャッシュできます。私は分離します。 静的 そして 動的な フラグメント：ナビゲーション、フッター、コンテンツはページキャッシュに保存され、カートバッジ、パーソナライズボックス、フォームトークンは Ajax によって再読み込みされます。あるいは、テーマやプラグインでフラグメントキャッシュを使用して、繰り返し使用されるブロックの計算コストを削減することもできます。重要なのは、クリーンな キャッシュの無効化: 関連するクッキー、ユーザーロール、クエリパラメータに応じて変化させますが、不必要にばらつきを大きくすることはありません。機密性の高い領域には短い TTL を、安定したコンテンツには長い TTL を設定することで、高いヒット率を達成し、 CPU PHPの解釈から離れて。.

admin-ajax、REST、ハートビート：静かな持続負荷

多くのサイトは、以下の要素によって安定した基本負荷を発生させています。 admin-ajax.php, 、RESTエンドポイント、およびハートビート。 私は、頻度を減らし、フロントエンドでの使用を制限し、繰り返されるポーリングタスクをまとめています。高価な管理リストは、無差別に大量のデータを配信する代わりに、サーバー側でより効率的にフィルタリングしています。ライブ機能については、厳しいタイムアウト、レスポンスキャッシュ、デバウンスを設定しています。これにより、1 分あたりのリクエスト数が大幅に減少し、残りのリクエストもより少ないリソースで処理できるようになりました。 CPU時間.

メディアパイプライン：CPUのピーク負荷のない画像処理

多くのサムネイルを生成したり、最新のフォーマットに変更したりすると、アップロード時に CPU-ピークを発生させる。同時画像処理を制限し、適切な最大サイズを設定し、不要な画像サイズを削減します。 バッチ処理については、制御された並行性を持つバックグラウンドジョブに作業を移行します。さらに、Imagick などのライブラリがリソースを節約するように設定されていることを確認します。メディアを CDN またはオブジェクトストレージにアウトソースすることで、I/O の負荷を軽減するだけでなく、直接提供される事前圧縮されたアセットによって PHP のワークロードも削減します。.

PHP-FPM の微調整と Web サーバーの連携

仝 CPU効率はプロセスマネージャーに大きく依存します。PHP-FPM には適切な pm モデル（dynamic/ondemand）を選択し、RAM および典型的なリクエスト時間に応じて現実的な pm.max_children を設定し、pm.max_requests を使用してメモリリークに対処します。 Web サーバーと FPM 間のキープアライブは接続のオーバーヘッドを削減し、静的アセット（Web サーバーまたは CDN から配信）を明確に分離することで PHP ワーカーを保護します。圧縮は慎重に計算します。静的事前圧縮は、オンザフライ圧縮に比べてリクエストごとの CPU を削減しますが、Brotli は高レベルでは必要以上にコストがかかる場合があります。目標は、低 TTFB 不必要な計算作業なし。.

インデックスを超えたデータベース：ストレージとプランを管理

インデックスに加えて、InnoDB バッファプールのサイズ、クリーンな照合順序、および大きな一時テーブルの回避も重要です。スロークエリログを有効にし、実行プランを確認し、頻繁な結合が選択的であることを確認します。大きなテキストフィールドに対して不正確な LIKE 検索を実行するクエリは、パフォーマンスを低下させます。 CPU そして、I/O パスを埋めます。私は、より正確なフィルター、キャッシュ、または事前集計されたテーブルに置き換えます。レポート、エクスポート、および複雑なフィルターについては、フロントエンドの要求をスリムに保つために、夜間ジョブまたは個別のレポートインスタンスに移行します。.

WooCommerce およびその他の動的なショップ

ショップは特別なものを提供します ダイナミクス：ショッピングカートの断片、セッション処理、およびパーソナライズされた価格は、多くの場合、ページキャッシュをバイパスします。静的ページでは不要な断片の更新を無効にし、明確な無効化機能を備えた製品リストをキャッシュし、テーブル全体をスキャンする高価な価格フィルターは使用しません。選択的なクエリで製品検索を最適化し、繰り返し表示されるカタログページにはオブジェクトキャッシュを使用します。 在庫調整とエクスポートには、同期プロセスではなくキューを使用します。これにより、リクエストごとの作業と CPU 本物の購入者向けに引き続き販売されます。.

キャッシュの無効化、ウォームアップ、ヒット率

優れたキャッシュは、正しい設定によってその良し悪しが決まります。 無効化. 投稿の更新、分類の変更、メニューの編集時に、キャッシュ全体を空にすることなく、ターゲットを絞ったパージをトリガーします。 デプロイや大規模なコンテンツ更新の後、スタートページ、カテゴリー、トップセラー、エバーグリーン記事などの中心的なページをウォームアップします。ヒット率、バイトヒット率、平均 TTL、ミスチェーンなどの指標から、ルールが有効であるか、あるいは過度に積極的であるかを判断します。目標は、高いヒット率、短いミスパスの、最小限の CPU-ダイナミックなルートを走ろう。.

APM、スローログ、サンプリング：適切な測定設定

測定なしでは、最適化は偶然に頼ることになります。アプリケーションログ、DB スローログ、サンプリングプロファイラーを組み合わせて、時間の経過に伴うホットスポットを特定しています。 重要な指標：PHP 時間の 95 パーセンタイルおよび 99 パーセンタイル、クエリの分布、キャッシュヒットの割合、バックグラウンドジョブの継続時間、エラー率およびタイムアウト率。このデータに基づいて、コードのリファクタリング、キャッシュの追加導入、または インフラストラクチャー また、各施策の効果を文書化し、成功事例を再現可能にし、後退を早期に発見できるようにしています。.

スケーリングテストとキャパシティプランニング

トラフィックのピークが来る前に、現実的な負荷レベルをテストします。まずキャッシュでウォームアップし、次に意図的にレイヤーを空にしてコールドテストを行います。各レベルのスループット（リクエスト/秒）、エラー率、TTFB、CPU 使用率を測定します。結論：重要なのは絶対的なピーク値ではなく、システムが飽和状態に近い状態でどれだけ安定を維持できるかです。 この結果に基づいて、ワーカー、バッファサイズ、タイムアウト、予備容量を計画します。この方法を採用すれば、マーケティングキャンペーン、セール開始、テレビでの紹介などを、システムに負荷をかけることなく、自信を持って吸収することができます。 CPU 崩壊する。.

私がめったに省略しない、実践的なチェックポイント

  • オートロードのクリーンアップ: オプションブロックを autoload = no に設定し、トランジェントを制限します。.
  • 断片化を減らす: 一貫性のあるキャッシュキー、少ない Vary ファクター。.
  • 管理と Ajax の負荷: ハートビートを抑制、ポーリングをバンドル、タイムアウトを設定。.
  • 画像サイズ 整理し、制限付きで背景のサイズ変更を実行する。.
  • FPM 適切なサイズ設定、Slowlogの有効化、PHPによる静的アセットの非使用。.
  • データベース: スロークエリの修正、バッファサイズの確認、一時テーブルの使用回避。.
  • ショップ: 必要な場合にのみカートフラグメント、カタログページのキャッシュ、キューへのエクスポート。.
  • キャッシュのウォームアップ デプロイ/フラッシュ、ヒット率、TTL を定期的に確認してください。.
  • セキュリティ: WAF/レート制限、404 の短期キャッシュ、既知の攻撃対象領域の保護。.
  • APIサーバーサイドのキャッシュ、短いタイムアウト、非同期ロード、キュー内のウェブフック。.

私のまとめ：WordPress を CPU バウンドから高速化するための方法

WordPress は、動的な 論理学, 、多くのフック、データベースの負荷、キャッシュの欠如が、すべてのリクエストを肥大化させています。まず、ページキャッシュとオブジェクトキャッシュに重点を置き、データベースを整理し、WP-Cron を緩和して、PHP パイプラインの作業量を軽減します。その後、プラグインの負荷を軽減し、タイムアウトと非同期ロードによって API コールを緩和し、ボットを早期にブロックします。 シングルコアのパフォーマンスが高く、適切なワーカー数と明確なアーキテクチャを備えた最新の PHP スタックが、残りの部分を担当します。これらの手順を構造的に実行することで、 応答時間 測定可能であり、CPU負荷を常に制御します。.

現在の記事