PHP向けサーバーCPUベンチマーク：実際のWebホスティングワークロードを対象としたテスト

PHPベンチマークが明らかにすべきこと

PHPのCPUベンチマークは、まず、システムが特定の計算タスクを完了するのにどれだけの時間を要するかを示すことができます。これは、個々のリクエストがPHPによる計算に多くの時間を費やしている場合に特に役立ちます。高い シングルコアのパフォーマンス このような処理にかかる時間を短縮できるが、CPUの値だけではウェブサイト全体の応答時間を推測することはできない。

2つ目の質問は、同時アクセス時のアプリケーションの挙動に関するものです。1秒あたりにいくつの正しい回答を返すのか、またその際、ユーザーはどれくらい待たされるのか。これについては、 ウェブホスティングのベンチマーク HTTP経由での測定が適切です。この測定では、WebサーバーやPHP、場合によってはデータベース、キャッシュ、ネットワークを経由する経路が把握されます。まさにこの複合的な要素が実用性を高めている一方で、CPU単独に関する孤立した結論を導き出すことはできません。

3つ目の疑問は、ボトルネックに関するものです。例えば、リクエストがデータベースへのクエリを待機している場合、計算処理が高速化されても、そのリクエストの総所要時間についてはほとんど何も示しません。キャッシュも結果に影響を与えます。PHPによる処理が完了する前にページが完全に配信されてしまう場合、その呼び出しでは動的アプリケーションの実行時間は測定されません。

また、並列負荷下では、PHP-FPMプールが同時に処理できるリクエスト数を制限することも可能です。そのステータスページには、使用中のプロセスや待機中のリクエストに関する情報などが表示されます。したがって、キューが長くなっていることは診断のきっかけとなるものであり、CPUの処理速度が遅すぎるという直接的な証拠ではありません。

ホスティングを選ぶ際には、以下の質問を個別に検討すると役立ちます。まず、同等の作業単位について、次に低負荷時と高負荷時の動作状況、そして最後に結果を制限するリソースについてです。CPU、メモリ、ストレージが基本的にどのように連携しているかについては、以下の記事で解説しています。 高性能ウェブホスティング向けハードウェア.

CPUスコアとアプリケーションテストの区別

A マイクロベンチマーク 明確に定義された小さなタスクを繰り返し実行します。例えば、PHPBench を使用すると、所定の条件下でデータ処理関数を検証することができます。この結果は、当該関数とその実行環境を比較する際に役立ちますが、クエリ全体や CMS やオンラインショップのパフォーマンスを自動的に評価するものではありません。

HTTPアプリケーションテストは、別の疑問に答えます。それは、「選択したアプリケーションが、実際に使用されているWebスタックを通じてどのように反応するか」ということです。このテストでは、テスト対象の呼び出しに関与している限り、PHP-FPM、データベース、キャッシュなどが考慮されます。 そのため、ホスティングサービスの評価には適していますが、どのコンポーネントが違いの原因であるかを単独で特定することはできません。

SPEC CPU は、こうしたテストを標準化された計算負荷の高いワークロードで補完しています。SPEC CPU 2026 には、整数および浮動小数点スイートに加え、Speed および Rate の測定結果が含まれています。「Speed」はタスクの所要時間を、「Rate」はスループットを指します。 Speed値は必ずしも純粋なシングルコア値とは限りません。SPECは、2026スイートの整数Speedテストにおいて、追加の並列処理が行われていることを明記しています。

信頼性の高いSPEC比較を行うためには、スイート、メトリクス、および結果の種類が base または peak 一致する。同様に、完全にテストされたシステムも重要である。プロセッサに加え、メモリ、コンパイラ、設定などが結果に影響を与える。したがって、公表されている数値は、そのCPUモデルの単独の特性ではなく、PHPのテストに代わるものではない。

SPEC CPU 2017 と CPU 2026 は異なるテストスイートを使用しており、その数値は同じ尺度で比較することはできません。 したがって、候補を絞り込む際には、簡略化されたランキングではなく、完全な結果レポートを比較すべきです。その候補が自身のアプリケーションに適しているかどうかは、その後、適切に設計されたアプリケーションテストを行って初めて判明します。

同等の試験条件を設定する

公正な比較を行うには、まず同じアプリケーションのバージョンを使用し、同等のデータセットを用意することから始めます。また、選択した処理経路とその期待される応答も一致している必要があります。データベースへのアクセスが多い製品ページは、単純なAPI関数とは異なる質問に答えることになるからです。 したがって、レスポンスが返ってくるかどうかだけでなく、その内容が想定されたタスクに合致しているかどうかも確認してください。

PHPのバージョンや拡張機能に加え、Webサーバー、PHP-FPMの設定、データベースについても記録してください。負荷発生ツールとアプリケーション間のネットワーク経路も、ログに含める必要があります。経路やデータベースの設置場所が異なると、たとえ両システムでのPHPの実行速度が同じであっても、測定される応答時間が変化する可能性があります。

特に重要なのは、以下の区別です。 CLI と PHP-FPM: コマンドラインでのテストでは、HTTPリクエストの場合と同じ実行時設定が自動的に検証されるわけではありません。 両方のコンテキストにおいて、実際に使用されているOPcacheおよびJITの設定を文書化してください。それらの効果やデフォルト設定は、PHPのバージョンなどによって異なります。比較を行うには、一律の仮定だけでは不十分です。

について キャッシュの状態 比較可能でなければならない。コールドキャッシュとすでにウォームアップ済みのキャッシュは、それぞれ異なる問題に対する答えとなる。どちらも関連性がある可能性があるが、別々に評価すべきである。データ量やテストデータについても同様である。処理範囲が変化すると、時間の差をシステムに明確に帰属させることができなくなる。

さらに、CPUモデル、割り当てられたvCPU、表示されているリソース制限、および選択した負荷と反復回数も記録してください。意図的に2つの異なるホスティングプランを比較した場合、その結果はそれぞれの全体的な構成に関する評価となります。 その場合、プロセッサ、制限、データベース、またはキャッシュに関する違いは、さらなる診断なしに、単にCPUの優位性として解釈してはなりません。

適切なワークロードと指標を選択する

どのテストを選ぶかは、あなたが答えたい質問によって決まります。一つは マイクロベンチマーク 限定的な演算タスクを検証する。HTTPテストでは、Webスタックを通る処理経路も考慮される。SPECの結果は、標準化されたCPU負荷の高いシステムテストによる比較を補完するものだが、独自のPHPアプリケーションのテストに代わるものではない。

単一の動的リクエストについては、代表的なページまたはAPIルートを選択し、並列度を低く設定して開始します。そのルートでは実際にPHPが実行される必要があります。上流のページキャッシュから完全に提供されたレスポンスは、有効なキャッシュテストにはなりますが、PHPによる処理についてはほとんど何も示しません。

同時接続ユーザーについては、あらかじめ設定された複数の負荷レベルで同じエンドポイントを検証します。これにより、並列処理が増加するにつれて、応答時間や成功スループットが変化するかどうかを確認できます。データベースを多用するルートの場合、比較実行の間、データセット、データベースの場所、キャッシュの状態は同一に保つ必要があります。

アプリケーション内のCPU負荷の高い機能については、PHPBenchを使用して個別に検証することも可能です。例えば、ネットワークアクセスを行わないデータ処理などが挙げられます。より良い結果が出たとしても、それはあくまで選択された実行条件下におけるその機能だけの利点に過ぎません。それがページ全体にとって実感できるメリットにつながるかどうかは、アプリケーションテストで確認する必要があります。

wrk を使用したステージングテストを実行する

明示的な許可を得た場合のみ、隔離されたステージング環境でテストを行ってください。リスクのない、実環境を反映した読み取り専用ルートを設定し、適切なテストデータを使用してください。開始前に、最大負荷および中止基準（発生するエラー、タイムアウト、他のサービスへの影響など）を定義しておいてください。

以下のコマンドは、この目的のために特別にセットアップされたローカルのステージングインスタンス上のターミナルで使用することを想定しています。ポート8080では、事前に準備されたルートにアクセスできる必要があります。このコマンドは実際に負荷を発生させるため、未知のシステムや本番環境のシステムでは使用しないでください。

wrk -t2 -c4 -d30s --latency http://127.0.0.1:8080/

この呼び出しでは、2つの負荷生成スレッド、4つのオープン接続、および30秒の実行時間が使用されます。オプション --latency 詳細なレイテンシの出力を要求します。この例では、4つの接続を起点としていますが、これはあくまでこの例のための設定であり、訪問者数やサーバーの容量に関する一般的な推奨事項ではありません。

ただし、wrkの通常のパーセンタイル出力にはp95は含まれていません。再現性のあるp95の評価を行うには、以下のLuaスクリプトを負荷発生器に次のように保存してください。 percentiles.lua. レイテンシ統計から、p50とp95がマイクロ秒単位で算出されます。これを1,000で割ると、ミリ秒単位になります。

function done(summary, latency, requests)
  io.write(string.format("p50: %.0f us\n", latency:percentile(50.0)))
  io.write(string.format("p95: %.0f us\n", latency:percentile(95.0)))
end

実際の測定を行うには、スクリプトを使用して同じローカル・ステージング・テストを実行してください。ファイルパスは、スクリプトファイルが置かれているディレクトリ内のターミナルを想定しています。この実行でも負荷が発生します。出力された2つのパーセンタイルを、エラーや別途検証した応答品質とともに記録してください。

wrk -t2 -c4 -d30s --latency -s percentiles.lua http://127.0.0.1:8080/

別のものを計画する ウォームアップ段階 実際の測定実行を記録する前に、この手順を行ってください。その後、設定された各負荷レベルを繰り返し、可能な限り比較対象システムの順序を変えてください。ウォームアップにかかった時間と、測定開始時にキャッシュが所望の状態にあったかどうかを記録してください。

接続数は合意された範囲内でのみ増やし、各段階ごとに中止基準を確認してください。また、負荷発生装置も監視してください。負荷発生装置自体がフル稼働している場合、結果に制限が生じる可能性があります。 さらに、ステータスコードやレスポンスの内容も確認してください。エラーページがすぐに表示されたり、誤ったレスポンスが返されたりした場合は、アプリケーションリクエストが成功したとはみなされません。

負荷段階と結果を記録する

測定記録は、数値とその数値が得られた条件を結びつけるものです。 各実行ごとに、環境、終了時点、キャッシュの状態、負荷レベルを結果とともに記録してください。以下のテンプレートでは、wrkやFPMステータスページが提供する数値などを使用していますが、レスポンスの内容確認については、ご自身で追加してください。

中央値は、観測された応答時間の中央値を表します。その p95 これは、測定された応答の95パーセントが超えない値です。これら2つの指標を併せて見ることで、典型的なリクエストに加え、分布の遅い部分にも変化が生じているかどうかがわかります。これらの指標を解釈する際は、常にエラーやタイムアウトと併せて検討してください。

固定の接続数と、所定のリクエストレートを区別してください。例のような接続ベースのテストでは、応答が遅いと、同じ接続を通じて1秒あたりに生成される新しいリクエストの数が減少する可能性があります。 その場合、測定されたレイテンシは、到着レートが一定に高い状態での挙動をそのまま反映しているとは限らない。

したがって、十分に類似した負荷ポイントのみを比較してください。具体的には、同じルートとレスポンス検証、同等のキャッシュ状態、そして同じ負荷モデルおよび同じ負荷レベルです。 並列度が低い状態での低いp95値は、過負荷状態でのp95値と直接比較することはできません。単一の良好な値を結果として出力するのではなく、複数の実行結果とそのばらつきを報告してください。

FPMとリソース制限の調査

負荷の増加に伴い、キューとp95応答時間の両方が上昇する場合は、PHP-FPMプールを確認してみる価値があります。以下の現在の値を比較してください。 active processes, idle processes そして listen queue 設定された上限値で pm.max_children. 許可されたプロセスがすべて実行中で、空きプロセスがなく、リクエストが待機している場合は、それは プールの境界線 あるいは、長時間稼働しているワーカーが原因である可能性はありますが、必ずしもCPUの処理速度が遅すぎるからというわけではありません。

広告 max children reached 一方、これはプール起動以降、プロセス上限に早期に達したことを示しています。これだけでは、現在キューが存在することや、既存のすべてのプロセスが現在処理中であることを証明するものではありません。同様に、既存のプロセスの最大数が、すべてのプロセスがアクティブであることを意味するわけでもありません。

ワーカーは、データベースへのクエリやその他の外部サービスの応答を待機している場合もあります。そのため、プールのステータスやCPU使用率を、観測された応答時間と照らし合わせて確認してください。CPU使用率が低いにもかかわらずキューが満杯になっている場合は、まず待機時間とワーカーの稼働状況を調査すべきです。 プール数を増やすことが必ずしも解決策になるとは限りません。追加のプロセスもリソースを消費するからです。

FPMのステータス値は各プールに適用されます。再起動時にはカウンターがリセットされます。 したがって、測定ログにはプールと再起動時刻を記録し、適切な期間内のカウント値のみを比較してください。有効化されたステータスページは、プールの運用情報を開示することになるため、不正アクセスから保護してください。

VPS や共有ホスティングの場合、割り当てられた vCPU が必ずしも専用の物理コアを意味するわけではありません。cgroup-v2 のデータにアクセスできる場合、以下のように表示されます。 cpu.max 設定されたCPU帯域幅制限； cpu.stat とりわけ、以下のカウンターなどを設定できます スロットリング が含まれています。実行中にこれらのカウンタを変更することで、有効な制限の診断に役立ちます。

可能であれば、上位のcgroupについても確認してください。そこでの制限設定は、一見すると余裕があるように見える設定であっても、利用可能な計算時間に影響を与える可能性があります。すべてのカウンターが、継承された制限を完全に反映しているわけではありません。 ホスティングプランにこれらの情報が記載されていない場合、可視範囲の制限は評価上の制約として明確に認識される必要があります。

ばらつきや測定誤差を検出する

1回の実行結果だけでは、たまたま好ましい、あるいは好ましくない状況が示されることがあります。記録された時点において同じ負荷レベルを繰り返し実行し、可能であれば比較対象システムの順序を変えてみてください。特にリソースが共有されている場合、利用可能なパフォーマンスは変動する可能性があります。そのため、典型的な結果に加えて、観測された 散乱 および走行回数。

繰り返し処理では、同じキャッシュ状態と同じデータセットが使用されるように注意してください。 ページキャッシュやデータベースキャッシュが温まっている状態での実行は、キャッシュが冷えている状態での実行と直接比較することはできません。一見高速に見える応答が、完全にページキャッシュから得られたものである場合、その応答はPHPが動的な処理をどれほど高速に実行しているかについてはほとんど何も示していません。

CLIのマイクロベンチマークも、FPMの結果とは異なります。これは別の実行コンテキストで実行されるため、異なるOPcacheやJITの設定が使用される可能性があるからです。両ランタイムで実際に有効になっている設定は、PHPのバージョンから推測するのではなく、個別に記録してください。 マイクロベンチマークでの優位性が、アプリケーションのHTTPテストにおいて同程度の差として現れるとは限りません。

成功したスループットには、内容的に正しく、正常に処理されたレスポンスのみをカウントしてください。そうでないと、エラーページがすぐに表示されたりタイムアウトが発生したりすることで、比較結果が大幅に歪んでしまう可能性があります。顕著な乖離が見られる場合は、その差を単にCPUのせいだと決めつける前に、データベースの待ち時間、キャッシュの変更、および明らかなリソース制限についても確認してください。

仝 クロック特性 これもばらつきの一因となり得ます。どの周波数制御が適切かは、プラットフォームや負荷によって異なります。一律の設定では、同じ条件下での比較に代わるものではありません。その寄与については、 ホスティングサーバーにおけるCPUガバナー より詳細な検討のために、その関連性を解説します。

ホスティング選びに検索結果を活用する

主に単一のCPUに負荷がかかるリクエストについては、 作業単位あたりの時間 重要な選定基準の一つです。これについては、ドキュメントに記載された実行時間のもとで代表的なPHP関数を比較し、そのメリットが動的なHTTPルートでも現れるかどうかを確認してください。マイクロベンチマークは、あくまでテスト対象のコードのみを評価するものであり、ホスティングサービス全体を評価するものではありません。

同時接続者が多数見込まれる場合、単一のリクエストに対する処理速度だけでは不十分です。さらに重要なのは、所定の負荷レベルにおいてシステムが1秒あたりに何件の正しい応答を返すか、およびp95レイテンシが許容誤差範囲内でどのように推移するかという点です。 スループットが高いシステムであっても、その応答が遅すぎて要件を超過してしまう場合は、必ずしもあなたのプロジェクトにとって最適とは限りません。

データベースやキャッシュに依存するアプリケーションでは、 アプリケーションテスト CPUスコアよりも重要な指標です。同等のデータセットを用いた典型的なルートは、選択された条件下でスタックがどのように連携して動作するかを示しています。SPECの結果は事前選定を補完することはできますが、それはテスト済みのシステムに関するものであり、PHPウェブホスティングのテストに代わるものではありません。

選択を行う前に、そのアプリケーションにおいて許容可能な応答時間、エラー率、および負荷レベルを明確に定めておいてください。 その後、適切な負荷モデルと類似したキャッシュ状態を持つ結果のみを比較してください。異なるホスティングプランは、全体的な構成として評価してください。それらの差から、さらなる診断なしにCPUの割合を特定することはできません。

この決定は、測定時点の状況に適用されるものであり、その後のアプリケーションのバージョンやアクセスピークには適用されません。PHP、アプリケーション、データベース、キャッシュ、またはリソース制限に大幅な変更を加えた後は、関連するテストを再度実施してください。そうすることで、以前には十分だった余裕が、新しい条件下でも引き続き確保されているかどうかを確認できます。