共有ホスティング：コア数が少ないにもかかわらず、高速なCPUが役立つ場合

コア、スレッド、CPU時間の違い

物理コアとは、プロセッサの演算単位のことです。一方、オペレーティングシステムからは 論理プロセッサ 実行単位として：マルチスレッドが同時に実行されている場合、複数の実行単位が1つの物理コアの資源を共有することがあります。そのため、その数だけでは、1つのホスティングアカウントで利用可能な独立したコアの数が直接は分かりません。

共有ホスティングでは、複数のアカウントが1台のサーバーのハードウェアを共有します。プランによっては、一定期間内に1つのアカウントのプロセスが消費できるCPU時間を制限する場合があります。これは CPU時間配分 これは、物理カーネルを排他的に使用するという約束とは異なります。Linuxのcgroupsは、そのような制限を実現するための技術的な基盤の一つではありますが、唯一の実装方法というわけではありません。

料金プランに「1 vCore」や「CPU 100％」などと記載されている場合は、プロバイダーの定義を確認する必要があります。 この表記は、特定のコアを恒久的に予約することなく、計算時間の割り当てを表している可能性があります。また、ホストサーバーの総コア数から、個々のアカウントが実際に同時に利用できる処理能力がどれほどか判断できるわけではありません。

ここでいう「同時実行性」とは、同時に処理できるリクエストやプロセスの数を指します。これは、プロセスの制限、メモリ、利用可能なCPUリソースなどに依存します。CloudLinuxでは、このために独自のリソース制限を設定することができます。各プランでこの技術が採用されているかどうか、またその設定内容については、プロバイダーに確認する必要があります。

リソース制限とセキュリティ隔離は、それぞれ異なる役割を果たします。制限は消費量を制御するものであり、一方、隔離は環境間のアクセスを制限することを目的としています。その CloudLinuxの「Site Isolation」と「CageFS」の位置づけ 対応するセキュリティメカニズムについて説明する。これ自体からは、特定のCPU割り当ては導き出されない。

なぜGHzだけでは決められないのか

クロック周波数は、プロセッサが1秒間に実行するクロックサイクルの数を示します。クロック周波数が高いほど、CPUに依存する処理を高速化できますが、それだけではウェブサイトがどれほどその恩恵を受けるかは分かりません。プロセッサのアーキテクチャによって、1クロックあたりに処理できる作業量は異なり、具体的なプログラムコードも結果に影響を与えます。

宛先 シングルコアの性能 さらに、キャッシュやメモリの動作特性も影響します。プロセスが頻繁にデータを待機しなければならない場合、クロック周波数が高くても、データがすぐに利用可能な計算に比べてその効果は小さくなる可能性があります。GHz だけで比較すると、こうした違いが見落とされてしまい、アプリケーションに特化したベンチマークの代わりにはなりません。

データシートの例として、AMD EPYC 4564Pを挙げることができます。このモデルについて、AMDは16コア、32スレッド、ベースクロック4.5 GHz、最大ブーストクロック5.7 GHzと記載しています。これらの仕様はプロセッサそのものを表すものであり、特定のホスティングプランのパフォーマンスを示すものではありません。

仝 最大ブースト これは、保証された恒常的な値でもなければ、すべてのコアで常に維持される周波数でもありません。同様に、製品データからは、特定の共有ホスティングプランがWordPressやPHPのリクエストをどれほどの速さで処理するかも分かりません。これには、ハードウェアに加え、設定、負荷、プランの制限なども影響します。

プロバイダーが 高周波CPUホスティング 宣伝されている場合は、具体的なプロセッサのモデルと利用可能なリソースの予算を確認してください。 有意義なパフォーマンス比較を行うには、ソフトウェアのバージョン、サーバー構成、ワークロード、およびテスト条件に関する情報も追加で必要です。これらの情報がなければ、宣伝されているGHz値が、より短い応答時間につながるとは確実に言えません。

PHPリクエストと並列処理

典型的な同期リクエストの場合、PHPワーカーはPHP処理の各ステップを主に順次実行します。 実際に計算負荷が高い場合、より高速なCPUを使用することでこの処理時間を短縮できます。一方、ワーカーが主にデータベースや外部サービスの応答を待っている場合、この待ち時間に対して、より高いプロセッサ性能がもたらすメリットは限定的です。

検索語句 PHP シングルコア したがって、ウェブサイト全体が1つのコアしか使用できないという意味ではありません。複数のリクエストは、複数のワーカーによって並行して処理されることがあり、Webサーバーやデータベースも同時に動作することができます。重要なのは、利用可能なリソースとそれぞれの構成が、こうした並行処理をどの程度許容するかという点です。

PHP-FPM では制限されています pm.max_children プールが同時に処理できるリクエストの数。この上限に達すると、そのプールに属する別のワーカーが追加のリクエストを直ちに処理することはできなくなります。ただし、この上限は、ウェブサイトを利用できる訪問者の総数に関する指標ではありません。

仝 プロセス管理 PHP-FPM には 3 つの動作モードがあります： static 一定数のワーカーを確保している。 dynamic 設定に基づいて、その数を需要に合わせて調整します； ondemand 必要に応じてワーカーを起動します。したがって、選択した動作モードによって、プロセスが利用可能になるタイミングや再起動されるタイミングも決まります。

ワーカーを増やしても、必ずしもCPU時間が自動的に増えるわけではありません。また、ワーカーにはメモリも必要であり、並列実行時にはアカウントの制限に共同で達してしまう可能性があります。評価を行うには、 共有ホスティングのCPU したがって、ワーカー数とリソース予算は密接に関連しています。すべての料金プランがPHP-FPMを採用しているわけではなく、また、顧客が設定を自分で変更できるわけでもありません。

並列負荷時のCPUクォータ

A CPUクォータ ある期間内に、プロセスグループが消費できる計算時間を指定します。Linuxのcgroup v2では、以下のように記述されています。 cpu.max この予算およびそれに対応する期間。したがって、この割り当ては自動的に排他的な物理コアを予約するものではなく、グループ全体で利用可能なCPU時間を制限するものです。

説明用の計算例（実測値ではありません）：あるグループは、100ミリ秒の期間ごとに100ミリ秒のCPU時間を割り当てられます。 これは、完全に負荷がかかった論理プロセッサの平均演算時間に相当します。2つのプロセスが、利用可能な2つの論理プロセッサ上で同時に演算を行う場合、理論上、約50ミリ秒の実時間後に共通の割り当て時間を消費し尽くすことになります。

予算が使い切られた場合、次の期間まで処理を抑制することができます。つまり、2つのワーカーがそれぞれ100ミリ秒の独自の予算を持っているわけではありません。実際に並列で実行されるかどうか、またそのタイミングは、スケジューラや利用可能なCPU、それらの動作状況などによって異なります。この例では、具体的な応答時間を予測するものではありません。

この調査では、cgroup v2 を cpu.stat とりわけ、～の計数器など スロットル 準備完了。代表的な負荷時間帯に数値が上昇する場合は、割り当てが上限に達していることを示しています。ただし、単一の計測値だけでは、どのリクエストが影響を受けたのか、あるいは他にボトルネックが存在するかどうかは判断できません。

これらのファイルがプラン内で利用可能であり、ウェブサイトに関連するものかどうかは、プロバイダーに確認する必要があります。共有ホスティングでは、異なる仕組みが採用されている場合があります。例えば、CloudLinuxでは、CPUやその他のリソースに対する独自のLVE制限が規定されています。したがって、このLinuxの例から、個々のホスティングアカウントの具体的な設定や動作を推測することはできません。

CMS、オンラインショップ、バックグラウンドジョブ

キャッシュされていないCMSページの場合、サーバーはリクエストに応じてアプリケーションロジックを実行し、必要なデータを取得します。処理の大部分が CPUの処理、コアあたりの処理能力が高ければ、このセクションの所要時間を短縮できる可能性があります。これは、例えばPHPコード内の複雑な計算などに当てはまりますが、ページが完成するまでの全所要時間に自動的に当てはまるわけではありません。

一方、同じリクエストが主にデータベースへのクエリや外部APIの応答を待っている場合、その間、PHPプロセスが高速なCPUの恩恵を受けられるのは限定的です。したがって、判断の鍵となるのは、サーバー側の応答時間の内訳です。つまり、計算に費やされる時間はどれくらいか、そして他のサービスを待つ時間に費やされる時間はどれくらいか、ということです。

あるショップの例を見ると、この質問に対する答えがサイトによって異なる理由がわかります。公開されている商品ページは、条件が合えば、既成の回答としてキャッシュすることができます。ある キャッシュヒット PHPによる再処理を完全に回避できる。一方、ショッピングカートやチェックアウトは、多くの場合、個別のデータを考慮する必要があり、動的な状態を維持する。

そのため、同時に行われる多数のチェックアウトリクエストは、同じ数のキャッシュ済みページへのアクセスよりも、ワーカーやCPUリソースをより多く消費する可能性があります。訪問者数だけではこの負荷を説明できません。重要なのは、どのエンドポイントが同時にリクエストされているか、そしてキャッシュがどの程度の頻度でヒットするかです。また、PHP-FPMでは、プール設定によって pm.max_children 同時に処理されるリクエストの数。

バックエンドでの計算負荷の高いインポート処理も、個々の処理が高速であればその恩恵を受けることができます。訪問者からのリクエストと並行して実行される場合、各プロセスが同じCPU時間枠を奪い合う可能性があります。 Cronジョブやインポートが実際に同じ限られたリソースグループに割り当てられるかどうかは、料金プランとその設定によって異なります。リソースの割り当てを決定する前に、プロバイダーに確認してください。

有意義な比較を行うためには、これらの作業負荷を個別に検討する必要があります。具体的には、典型的な動的リクエスト、複数のリクエストが同時に発生する局面、そして必要に応じて稼働中のインポート処理などです。 そうすることで、個々の処理ステップの速度と利用可能な総処理能力のどちらがより重要な調整要素であるかを、より明確に把握できるようになります。

観測結果とボトルネックを比較する

レスポンスが遅いからといって、必ずしも原因が特定できるわけではありません。以下の概要では、典型的な現象と検証可能な原因を関連付けています。特に、CPUタイムリミット、PHP-FPMにおけるワーカー数の制限、および保存されたPHPコードと実際に生成されたレスポンスとの違いについて考慮しています。

表の各行は、それぞれ 仮説、確定的な診断ではありません。並列処理中の応答遅延は、例えばCPUのスロットリングと重なることもありますが、ワーカーが占有されている場合やデータベースが待機状態にあることによっても発生する可能性があります。したがって、単一の症状から処理方式の変更を判断するのではなく、可能な限り、同じワークロードに対して複数のシグナルを同時に確認するようにしてください。

評価の際には、 応答時間 スループットに関する問い合わせ：個々の応答が速いからといって、同時アクセス数が多い場合に、1秒あたりの処理リクエスト数が自動的に増えるとは限りません。逆に、システムが良好なスループットを達成していても、個々のリクエストの待ち時間が長くなる場合もあります。

また、ユーザーが感じるページの読み込み時間は、サーバー側の応答時間とは同一視できません。 レスポンスが返った後でも、例えば追加のリソースが読み込まれ、ブラウザ内で処理される場合があります。ホスティング環境でのCPUのアップグレードは、影響を受けるサーバー側の部分のみに対処するものです。公平な比較を行うためには、キャッシュの状態、リクエストされたページ、および並行処理の状況を同一に保つ必要があります。

キャッシュに関しては、概念的な区別も重要です。OPcacheはコンパイル済みのPHPコードを保存し、それによって再コンパイルを回避できます。一方、ページキャッシュは生成されたレスポンスを保持します。したがって、キャッシュヒットが速いからといって、動的なリクエストに十分なCPUリソースが割り当てられているわけでも、OPcacheがアプリケーションロジックに取って代わっているわけでもありません。

帯域制限と待ち時間の把握

診断は、あなたのウェブサイトでよく見られるリクエストから始めましょう。例えば、CMSの公開ページ、検索、そしてオンラインショップの場合はチェックアウトなどです。 それぞれのレスポンスがページキャッシュから返されたものかどうかを記録してください。その後、訪問者総数だけを見るのではなく、個々のアクセスと、プロジェクトを代表する同時リクエスト数を比較してください。

できるだけ CPU時間 アプリケーションの全体的な応答時間や、データベースや外部サービスへの待ち時間は、CPUの使用率に左右されます。CPUの使用率が低い場合、より高速なプロセッサを使用しても、呼び出し時間の短縮できる部分は限られてしまいます。適切な測定値がない場合は、プロバイダーに利用可能なログ、メトリクス、または適切な分析結果について問い合わせてください。

並列負荷がかかっている状態で、利用可能なワーカーがフル稼働しているか、および制限カウンターが増加しているかを確認してください。PHP-FPM では制限が設けられています。 pm.max_children プール内で同時に処理されているリクエストの数。この値や使用率を確認できるかどうかは、料金プランによって異なります。Linux cgroup v2 システムでは、 cpu.stat とりわけ、スロットリングカウンターの値を表示する。カウンターの値が上昇している場合は、CPUバジェットと測定期間をより詳細に確認する必要がある。

SSHおよび当該ファイルにアクセスできる場合、以下のコマンドを実行すると、 cat /proc/self/cgroup 呼び出し元のプロセスのcgroup割り当て。ただし、これをもって、Webリクエストが同じグループで実行されるとは限らない。パス、権限、および解釈についてはプロバイダに確認すること。また、エラーコードも、すべての共有ホスティングシステムの特定の制限に一律に割り当てることはできない。

キャッシュを確認し、料金プランを比較する

まず、どの公開ページが完全な回答として安全にキャッシュできるかを確認してください。1つ ページキャッシュ ヒット時に動的な処理が繰り返し行われるのを防ぐことができます。一方、パーソナライズされたコンテンツ、ショッピングカート、およびチェックアウトについては、訪問者に不適切なデータや古いデータが表示されないよう、適切なキャッシュ戦略が必要です。

もう一つのアプローチは、キャッシュミス時の処理負荷を軽減することです。処理に時間がかかるデータベースクエリを調査し、不要な動的処理を排除してください。 外部サービスを利用している場合、その応答時間が決定的な要因となる可能性があります。その場合は、CPUが原因であると決めつけるのではなく、まずその呼び出しを検証すべきです。どのような変更が有効かは、実際に遅延が発生している処理パスによって異なります。

これとは区別すべきであるのは オペキャッシュ: コンパイル済みのPHPコードを保存しますが、完全なページキャッシュの代わりになるわけでも、アプリケーションロジックの実行に代わるものでもありません。Webランタイム環境での利用可能性と設定を確認してください。 CLIには独自のOPcache設定があるため、コマンドラインを確認しただけでは、Webリクエストの設定が確認できるわけではありません。

料金プランを比較する際は、同じソフトウェアバージョン、同等のデータセット、および記録されたキャッシュ状態を用いて、同一のクエリを比較する必要があります。同じ並列度で比較を繰り返し、それぞれ利用可能なCPU、ワーカー、およびメモリの割り当てを考慮に入れてください。 そうしないと、テスト条件の違いによって差異が生じ、プロセッサ性能について信頼できる結論が得られなくなる可能性があります。

また、個々の応答にかかる時間や、一定期間内に処理されるリクエスト数を個別に記録しておきましょう。ある料金プランは、単発のアクセスでは安価に見えるかもしれませんが、同時アクセスが増えると処理能力の限界に達してしまう可能性があります。比較結果から得られた数値は、まずは調査対象のアプリケーションとその条件にのみ適用されるものです。

より高速なCPUか、それとも予算を増やすか？

代表的な動的クエリが主にCPU処理を行っており、ワーカーやメモリ、時間制限のいずれにも制約がない場合、より高い プロ・カーン・パフォーマンス 妥当な料金プランの選択肢の一つです。これにより、個別の問い合わせにおける計算にかかる時間を短縮できます。ただし、これが回答全体にどの程度影響するかは、依然としてアプリケーションとその待ち時間によって異なります。

一方、複数の同時リクエストが発生した際に、データにスループットの低下やワーカーのリソース枯渇が見られる場合は、より大きな 資源予算. クォータの上限に達している場合は、CPU時間を増やすことが有効な場合があります。ただし、ワーカーを追加するには、十分なメモリと計算時間も必要となります。データベースや外部サービスがボトルネックとなっている場合、CPU予算を増やすだけでは確実な解決策にはなりません。

変更を行う前に、既存の環境を最適化することと比較してみる価値があります。適切なページキャッシュやクエリの改善により、すぐに上位のプランに切り替えることなく、動的な処理を軽減できる場合があります。変更後は、同様の条件下で診断を繰り返し、その効果を他の要因の影響と区別できるようにしてください。

A 共有ホスティングの代替手段としてのVPS 多くの場合、ソフトウェアや設定に対する影響力が大きくなりますが、その分、セキュリティ、アップデート、容量計画に対する責任も増大します。仮想CPUは、プロバイダーから明示的な保証がない限り、専用の物理コアではありません。そのため、具体的なリソース割り当てや契約条件についても確認してください。

決定する前に、プロバイダーにプロセッサのモデル、CPU時間予算の定義、および負荷のピーク時の対応について確認してください。また、適用されるワーカー数やメモリの制限、バックグラウンドジョブが同じ予算を共有するかどうか、そしてどの制限カウンターを確認できるかについても明確にしておきましょう。 これらの情報を把握して初めて、宣伝されているCPU性能を、ご自身の具体的な料金プランに照らして適切に評価できるようになります。