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

ARMサーバーとx86サーバーでWordPressのパフォーマンスが異なる理由

ワードプレスARM というのも、RISC 命令、キャッシュ階層、エネルギー目標が PHP の実行、I/O、並列性を大きく変えるからです。実際には、これはリクエストあたりのコストの低下や、シングルスレッドとマルチスレッドの特性の違い、管理画面とフロントエンドでの待ち時間の違いなどに反映されます。.

中心点

簡単に分類するために、WordPressの最も重要な違いを簡単にまとめ、各アーキテクチャの主な利点を強調します。.

  • 価格効率ARMはしばしば1ユーロあたりより多くのリクエストを提供し、20-40%の電力を節約する。.
  • 互換性x86は古いソフトウェアで、ARMは最新のスタックでスコアが出る。.
  • パフォーマンスx86はシングルスレッドで強力だが、ARMは多数のコアで幅広くスケールする。.
  • ワードプレスのスコアARMはアドミンで>8に達し、x86に迫る。.
  • ワークロードNginx/PHP-FPMはARMが大好きで、特殊なケースではx86に向かう傾向がある。.

ARMサーバーでWordPressの高速化が異なる理由

ARMの場合は違うようだ。 命令幅 そして、多くの小さなPHP操作を効率的に処理するシンプルなデコードに重点を置いている。WordPressは短いリクエストを数多く生成するため、最大クロックレートだけでなく、リクエストごとのオーバーヘッドが重要になります。ARMは、Nginx、PHP-FPM、Opcacheがうまく連携し、多くのワーカーが並列に動作する場合に恩恵を受ける。x86はピーク周波数が高いことが多く、個々の長いPHPスクリプトをより高速に処理します。しかし、キャッシュを使用する一般的なページリクエストでは、ARMの方が有利です。 エネルギー吸収 は依然として低い。.

ナンバーチェック：コスト、ベンチマーク、効率性

Hetznerの4コア/8GB ARM VPSの価格は約25,000円です。 7,72 € YABSテストでは、64k IOPSで約1.11GB/秒の読み取りを実現しました。Geekbenchでは、シングルコアで約1072点、マルチコアで3439点を記録し、ページキャッシュやPHPワーカーの負荷による日常的な使用で顕著な結果を示した。x86プロセッサの価格は月額約16.18ユーロで、同様の値を示したが、より高いワット数を記録した。管理画面にあるWordPressのミニシナリオでは、ARMのスコアが8を上回ったが、個々のサーバーのサブテストでは8を下回った（例）。 0,7 対8.1)。とはいえ、各リクエストにかかる予算が減り、RAMやキャッシュに余裕ができるため、節約効果は依然として大きい。.

実際には CPUアーキテクチャ とPHPのコンフィギュレーションと一緒にキャッシュの影響を与える。根拠のある CPUアーキテクチャとキャッシュ, ページキャッシュ、オペキャッシュ、オブジェクトキャッシュを調和させる。少ない予算でできるだけ多くのビジターをマッピングしたい場合は、ARMの高密度並列処理を利用する。リクエストごとのロジックが少ないが重いプロジェクトの場合、x86は個々のリクエストを滑らかにすることができる。最終的には、これがTTFBあたりのコストを決定することが多い。 スケーリング ピークスで.

ウェブ・サーバー・スタック：Nginx、PHP-FPM、データベース

ARMにワードプレスを設置した。 Nginx とPHP-FPMを使い、十分なワーカーをセットアップし、opcacheとオブジェクトキャッシュを使う。これによって、エキゾチックなプラグインによって動作が遅くならない限り、多くの小さなPHPタスクをx86よりも有利に実行できるようになった。ファイルシステムとデータベースのテストでは、ARMとx86はほとんど同じように動作した。バイナリーランダム演算では、ARMが若干落ちるケースもあったが、WordPressではほとんど意味がない。決め手となったのは、やはり パイプライン 行列なしで作業できる。.

ARMでの互換性とプラグイン

引っ越しの前に、私は アーチ64-特にアンチウイルススキャナやバックアップツールなど、使用するすべてのプラグインをサポートします。cPanelやPleskなどのコントロールパネルはARM上で動作するが、個々の独自モジュールが欠落している可能性がある。純粋なLinuxスタックの場合、ARMはスムーズに動作するが、x86はWindowsや古いディストリビューションで操作する余地がある。そのため、私はステージング環境をテストして、早い段階で特殊なケースを確認するようにしています。こうすることで、切り替え時の時間を節約し、スピーディーな移行を実現している。 移行フェーズ 嫌な驚きもなく。

WordPressのシングルスレッドとマルチスレッド

WordPressのレンダリングは ピーエッチピーエス また、シングルスレッド・クロックに強く反応し、例えばキャッシュされていない管理ページやWooCommerceの重いアクションに対応します。x86は、5GHz台までの高いブースト周波数で、ピーク実行時間の短縮を実現します。ARMは、多くのリクエストが並列に実行され、キャッシュが有効になるとすぐに得点を獲得する。このため、キャッシュを使用したフロントエンドの負荷はARMの主要なケースとなり、一方、トリッキーな管理タスクはx86の優位性を示すことが多い。もっと詳しく知りたい方は、以下をご覧ください。 PHPシングルスレッド そして、TTFBとバックエンドのキレへの影響を分類する。.

エネルギー消費と価格性能の実際

データセンターでARMをよく見かける 20-40% 負荷がかかった状態での消費電力は、x86と比較して少ない。この節約は請求額を減らすだけでなく、より多くのRAMのための予算も生み出します。WordPressでは、RAMが多いほどページとオブジェクトのキャッシュが高速になり、ピークがスムーズになります。その結果、レイテンシーが大きく跳ね上がることなく、1ユーロあたりの訪問者数を増やすことができる。このようにして、私は、水平方向に拡張する前に、トラフィックの範囲を拡大したり、あるいは、トラフィックの範囲を拡大する前に、トラフィックの範囲を拡大したりしている。 アップグレード が必要だ。.

ワークロードいつARM、いつx86？

私は、ウェブサーバー、マイクロサービス、および コンテナ が優勢で、多くの中規模の PHP タスクが保留中である。ARMは価格性能比が高く、スタックによっては40%まで向上することもある。私は、高いシングルスレッド性能、レガシー・ライブラリ、ゲーム・サーバーのような特殊なケースで高い処理速度が必要な場合にx86を使用する。暗号のテスト（AES-256など）ではx86の方が有利で、圧縮に関してはどちらの分野も拮抗していた。要するに、プロファイルに応じて決めるということだ：I/O重視で広く並列 → ARM、高周波数重視で並列 遺産-閉じる → x86.

Ampere/GravitonとDockerによるスケーリング

Ampere AltraやGraviton3などの現在のARMプラットフォームは、多くの機能を提供している。 コア 消費電力も低い。これは、コンテナ・ネットワークでWordPressを利用する際に有利に働く。なぜなら、1ホストあたり、より多くのPHP-FPMワーカー、Redis、Nginxインスタンスを実行できるからだ。これにより、トラフィックのピーク時に理想的な、1ユーロあたりの1秒あたりのリクエストを増やすことができる。x86は、各プロセスがハードなクロックを要求される場合にも耐えうるし、スレッドピニングは直接的な利点をもたらす。総じて、私はARMの方が高密度を実現できることが多い。 統合 サーバーあたり、フロントエンドでのトラッキングロスがない。.

実践的なセットアップ：WordPress ARMのチューニング・チェックリスト

まずは現在のところから カーネル NginxはアグレッシブなキャッシングとGzip/Brotli、HTTP/2/3を利用している。Nginxはアグレッシブなキャッシング、Gzip/Brotli、HTTP/2/3を受けている。バッファ、スレッド、I/Oの設定でMariaDBやMySQLをコア数に合わせている。Redis/オブジェクトキャッシュはデータベースからの負荷を軽減し、TTFBを顕著に短縮する。ボトルネックを素早く解消するために、リクエストトレースで定期的に効果をチェックしている。 探す.

ホスティングの選択とベンチマークを正しく読む

私はベンチマークを次のように評価している。 ワークロード, 但し、未加工のポイントによる。1000の同時リクエストによるマルチコアテストでは、x86がいくつかのケースでわずかに優勢であることが示された（例：8509対8109 RPS）が、ユーロで計算するとARMは再び同等となった。4C/8GBのARMが7.72ユーロといった価格は、特にIOPSとネットワークレイテンシーが適正であれば、その傾向を示している。決断を下す際には、Geekbenchだけでなく、実際のページテストやクエリのプロファイルを見ることが役に立つ。また、„クロック速度はコアよりも重要“を使用して、単一のリクエストの負荷をよりよく管理する。 レート.

PHP 8.x、ARM上のJITとOpcache

私は、WordPressはJITよりもクリーンなOpcacheセットアップの方がより恩恵を受けることに気づいた。ARMでもx86でも、JITはダイナミックなPHPワークロードで一貫した利益をもたらすことはほとんどなく、メモリを消費するので、私は通常JITを無効にします。その代わりに opcache.memory_consumption, opcache.max_accelerated_files そして opcache.validate_timestamps を、開発環境では低いインターバルで使用し、本番環境では無効化する。ARMでは opcache.file_cache-ウォームスタート時の使用率が向上し、コールドリブート時の痛みが軽減されました。CPUのピークが減り、TTFBパスが安定し、同時リクエストのヘッドルームが増える。.

FPMワーカープランニング：RAMから並列処理へ

の選択である。 ピーエッチピーエフピーエム-WorkerはARMでは特にありがたい。多くのコアが低いクロックレートで利用できるからだ。PHPプロセスあたり60～120MB（プラグインによる）、ディメンションは以下のように考えています。 pm.max_children それに応じて8GBのホストでは、システムサービスを削除し、データベースとキャッシュ用にバッファを確保し、残りをワーカーに分けます。. pm = ダイナミック をもって pm.max_requests 500-1500程度に設定するとメモリリークを防ぐことができる。ソケット通信（Unixソケット） 私はTCPを好むが、以下のように設定する。 バックログ, rlimit_files そして プロセス制御タイムアウト 負荷のピークが直接502に傾かないように、意図的にそうしている。ARMはきれいにスケールアップし、x86は高クロックレートのおかげで個々の重いコールをより速く処理する。.

データベースとI/O要因

MySQL/MariaDBは、CPUよりもWordPressのパフォーマンスを制限することが多い。私は innodb_buffer_pool_size をたっぷりと使う。 やり直しログ-リスクを許容できるなら、不要なストレージ同期を設定し、オフにする。私のテストでは、ARMとx86はI/Oパターンが似ていたので、ここでの主な利点は以下の通りである。 スキーマの最適化, インデックスとオブジェクトキャッシュが決定的な改善点だ。メディア負荷の計算には、ファイルシステムのキャッシングも含めています：大容量のページキャッシュを搭載したNVMeキットは、多くの場合、CPUの違いをI/Oレイテンシの背後に完全に隠します。決定的な要因は、クエリが特に短縮され、キャッシュが90%を超えるヒット率を達成することです。.

ネットワーク、TLS、HTTP/3

フロントエンドでは、小規模で頻繁なリクエストでは、TLSオーバーヘッドが今日の主流である。x86は、暗号ライブラリの幅広いアクセラレーションから一部恩恵を受け、ARMは、多くの同時ハンドシェイクに必要なエネルギーが低いため、効率的に利益を上げている。私は HTTP/2/3 優先順位を厳密に設定し、ハードウェアサポートのある最新の暗号を選択し、セッション再開を有効にします。Nginxでは、キープアライブをあまり強く絞らないようにして、コネクションが十分に長くオープンな状態を保ち、ARMが並列処理で優位に立てるようにしている。アセットについては、x86のシングルスレッドの利点が日常的な使用においてあまり重要でないように、数とサイズを最小限に抑えている。.

ビルド、デプロイ、マルチアーチの実践

コンテナでは、ARMの強みを生かしつつ、以下の点に注意を払う。 マルチアーチ画像, ビルド・パイプラインがクリーンに実行できるようにするためだ。QEMUはレイヤーの速度を低下させ、エラーソースを引き起こすので、私はエミュレーションよりもネイティブビルドを好む。PHP拡張（Imagick、Redis、Sodiumなど）を含むWordPressスタックについては、すべてのaarch64パッケージが利用可能であることを確認しています。プロプライエタリなローダー（エンコーダー/デコーダーやライセンスモジュールなど）が必要な場合は、代替を計画するか、ARMとx86用に別々のイメージを構築します。明確なタグ付け戦略によって、ロールバックがシンプルになり、移行時間が大幅に短縮されます。.

つまずきのない移行

ARMに切り替える前に ステージング 同じテーマ、同じプラグイン、同じPHPマイナーバージョン。CLIツール（WP-CLI）、cronジョブ、画像処理（GD/Imagick）、PDF/ZIP生成をチェックする。セキュリティスタック（マルウェアスキャン、WAFモジュール）でバイナリフィルタが動作している場合は、ARMの対応するものをテストします。ローリングカットオーバーによってダウンタイムを回避している。キャッシュウォーマーがページキャッシュとオブジェクトキャッシュを供給し、データベースが最初にレプリケートされ、DNSの切り替えが低いTTLで行われる。切り替えの前後でTTFB、p95レイテンシー、エラーレートを測定し、その後で古い環境に移行する。.

測定方法とKPI

私は生の数字を単独で評価しない。決定的な要因は p95/p99 現実的な組み合わせ（静的HTML、キャッシュヒット、キャッシュミス、管理者呼び出し）で数分間にわたって行った。私はコールドキャッシュとウォームキャッシュを区別し、負荷がかかっているかどうかをチェックする。 キューの長さ 成長する。クリーンなテストには以下が含まれます：ログインフロー、ショッピングカート/ajax、RESTエンドポイント、cronイベント、メディアアップロード。私はメトリクスをシステム値（ランキュー、ディスク待ち、TCP再送信）と関連付け、同じターゲットRPSの下でARMとx86がどのように反応するかを確認する。これにより、ボトルネックがCPUクロックなのか、PHPワーカーなのか、I/Oなのか、データベースなのかがすぐにわかります。.

実践におけるエラーの原因

パフォーマンスの低下は、アーキテクチャだけが原因であることはほとんどない。ARMではCPUガバナーをコントロールし（あまりアグレッシブなパワーセーブカーブを描かない）、x86では以下の点に注意を払う。 ターボ・ブースト・サーミックス とNUMAの副作用。コンテナでの制限 cgroups CPUとメモリのピークは気づかれないことが多い。透明な巨大ページやスワップ・プレッシャーは、チューニングが不十分だとレイテンシーを悪化させる。VPS環境 うるさい隣人 I/Oがピークに達した場合は、専用のストレージや余裕のあるページキャッシュが役立ちます。私はヘルスチェックを厳しく設定し、過負荷でサイト全体がダウンする前にサーキットブレーカーで介入します。.

キャッシュ戦略の微調整

ARMはキャッシュが整っていれば高い並列性で輝く。私は フルページキャッシュ アノン・トラフィックには積極的なオブジェクト・キャッシュを、ログインしているユーザーには積極的なオブジェクト・キャッシュを、eコマースにはターゲットを絞ったエッジ検証を行っています。セッションやユーザー権限が適用される場合は、フラグメントキャッシュ（ESI、マイクロフラグメント）を計画し、データベースのラウンドトリップを減らします。キャッシュキーを安定させ、散乱を最小限に抑え、明確なTTLプロファイルを確保します。こうすることで、リクエストごとのPHPの作業を減らし、x86のシングルスレッドの利点をARMの並列性によって平準化します。.

リクエストあたりのコストを賢く計算する

予算は月ごとだけでなく、月ごとに計算する。 10,000件のリクエスト をターゲットミックスに含める。私は、ホスティング価格、エネルギーコスト（プロバイダーによって間接的に価格設定される）、暖かい州のRPS、TTFB目標を組み合わせています。より多くの並列ワーカーのおかげで、同じ価格帯でより高い負荷を吸収できるため、ARMの方が良い結果を出すことが多い。x86は、少数の複雑なリクエスト（レポート生成、インポートパイプラインなど）が支配的な場合に、その対極をなす。アプリケーションロジックが最適化されるまでは、特殊な負荷のためにARMフロントエンドとx86バックエンドを組み合わせることがよくあります。.

ホスティング選択の厳格化：サイズとリザーブ

予約は軽い方がいい 経由 ピークが計画できるのであれば、需要不足よりも。RAMが少し多いARMノードは、PHPとデータベース・キャッシュのバッファが明らかに優れている。x86の場合、全負荷時にスロットリングに陥らないように、ブーストフェーズ用のリザーブを計算します。ネットワークのレイテンシ、ストレージの一貫性、アップグレード戦略が透過的であることが重要です。ストレージのジッタによってp95のレイテンシが発生すると、高速なARMホストはその優位性を失います。SLAの詳細、フリートの均質性、アップグレードのウィンドウは、フロントエンドの安定したミリ秒を実質的に決定する。.

比較表：主な数値 ARM対x86

次の表は、WordPressの特徴的な機能をまとめたもので、どこにどの機能があるかを示している。 強さ ご覧ください。.

特徴 ARMサーバー x86サーバー
ユーロあたりのパフォーマンス 高い、部分的に高い +40% 価格性能の優位性 良いが、通常1回のリクエストは高い
エネルギー効率 非常に良い。. 20-40% 消費量の減少 堅実だが需要は高い
互換性 最新のLinuxスタックに強い レガシー／ウィンドウズに最適
ワードプレス管理スコア もっと頻繁に 8 テスト 一部やや高い
暗号（AES-256） やや弱い 通常より速い
4C/8GB 価格 およそ. 7,72 € 月あたり 月額約16ユーロ
リクエスト/秒（1000 conc.） z.B. 8109 z.B. 8509

要約：私はどのように選択するか

私はARMに頼っている。 お問い合わせ キャッシングを使用する場合、予算は厳しく、コンテナのワークロードが基本となる。その場合、有利なコア、低消費電力、高密度の並列処理によって、目に見えて多くの効果が得られる。管理負荷、計算負荷の高い拡張機能、古いバイナリモジュールには、高い周波数と幅広い互換性のおかげでx86が有利だ。何かを決定する前に、私はページキャッシュ、オブジェクトキャッシュ、PHPワーカー、クエリプロファイルなどのステージングをチェックする。このようにして、信頼できる選択をし、TTFBを確保し、次の計画を立てるのです。 スケーリング 将来性がある。.

現在の記事