【実運用スケールベンチマーク】

本ページでは、CPU割当なし（プロセスの CPU ピニングなし） の状態で、WebSocket（MDN WebSocket API）を用いた 10,000 / 50,000 / 100,000 接続を維持しながら実施した 実運用に近い 6 時間耐久ベンチマーク の結果をまとめています。

5万・10万接続の ping/pong テストでは ラウンド間隔なし の連続バーストを実施しており、実際のサービス運用よりも厳しい条件での動作確認となっています。

すべての測定において エラーは発生せず、PHP のメモリ設定は標準の 128MB のままです。

>> ベンチマーク結果を見る

純粋性能については「ハイパフォーマンスモード」で詳しく解説しています。

>> ハイパフォーマンスモードを見る

別ページで公開している「ハイパフォーマンスモード」のベンチマークは、ラウンド間隔を10秒空けた理想条件での純粋なレイテンシ性能を示すものです。

一方、この「CPU割当なし版」は次のような特徴があります。

• CPU割当なし：OSスケジューラ任せの現実的な環境
• ラウンド間隔なし：5万・10万接続では ping/pong を連続バースト
• 長時間耐久：数万ラウンド規模の連続実行

また、内部処理では PHP の FFI や Sockets 拡張 を活用した IO ドライバが動作しており、CPU 割当なしでも安定した処理が可能です。

つまりこのページは、「実運用に近い条件で壊れないか」を検証することに主眼を置いた結果です。

共通条件

• CPU割当：なし（プロセス・スレッドの CPU ピニングなし）
• メモリ設定：PHP 標準の 128MB
• 接続数：10,000 / 50,000 / 100,000
• フレーム：ping/pong、ペイロード 100バイト
• OS：Linux / Windows
• テスト時間：6 時間（接続維持）

ラウンド条件

• 10,000 接続時 ping/pong：ラウンド間隔 10秒
• 50,000 / 100,000 接続時 ping/pong：ラウンド間隔なし（完了後すぐ次ラウンド）
• 1ラウンドあたりの同時処理件数：常に 10,000

※「アクセス集中時」は、全接続から一斉にリクエストが集中する最悪条件を想定したテストです。

性能（Performance）

• 10万同時接続時の ping/pong 平均レイテンシ：0.553ms（Linux）
• 5万同時接続時の ping/pong 平均レイテンシ：0.348ms（Linux）
• ラウンド間隔なしで 1ラウンド 10,000 件を約 5〜6 秒で連続処理

堅牢性（Robustness）

• 全テストで エラー発生ゼロ
• ラウンド間隔なしの連続バーストでも破綻なし
• 10,000 → 100,000 接続でレイテンシは約 4.6 倍に収まり、スケールは線形に近い

軽量性（Lightweight）

• 全テストを通じて PHP のメモリ設定は 128MB のまま
• 接続数増加や長時間運用によるメモリ膨張なし

今回の 10,000 / 50,000 / 100,000 接続の耐久ベンチマークにより、 SOCKET-MANAGER Framework のアーキテクチャが持つ以下の特徴が、 実運用スケールでも破綻しないことが明確になりました。

1. ステートマシン I/F による「状態破壊のないスケール」

フレームワーク本体にビルトインされた UNIT / Queue モデルは、 非同期処理中でも状態破壊が起きない構造を持っています。
10万同時接続・連続バーストという厳しい条件下でも破綻しなかったのは、 このステートマシン構造が正しく機能している証拠です。

2. 統一 I/F による IPC / マイクロサービス親和性

SOCKET-MANAGER は TCP / UDP / WebSocket / IPC などを 同じステートマシン I/F で扱えるため、 プロセス単位でのスケールアウトが極めて容易です。
実際、今回のベンチマークでもプロセス構成を変えるだけで スケール戦略を柔軟に組み替えられることが確認できました。

IPC の詳細は >> IPC（プロセス間通信） にて解説しています。

3. プロセス単位で自由に組み替えられるスケール戦略

CUEI アーキテクチャの I（IPC）を中心に、 C（Communication）・U（Union）・E（Event）が統合されているため、 サーバー構成をプロセス単位で自由に組み替えることができます。
これはマイクロサービス構成との親和性を高め、 実運用でのスケール戦略を大幅に柔軟にします。

マルチサーバー構成の詳細は >> マルチサーバーの構成 を参照してください。

4. ランチャーによる論理 CPU 割当でスケール戦略を最適化

GUI / CLI ランチャーでは、サービス単位で 任意の論理 CPU を割り当てることができます。
これにより、プロセス単位のスケール戦略と CPU リソース戦略を 一体化して最適化でき、より高いスケーラビリティを実現できます。

CPU 割当の詳細は >> ランチャーのサービス設定 を参照してください。

今回のベンチマークは、 SOCKET-MANAGER Framework が「スケールしやすい構造」を持つだけでなく、 実運用レベルでもその構造が正しく機能することを証明する結果となりました。

実運用に近い条件でのスケール特性

CPU割当なしの状態では、OS スケジューラ（参考：Linux Scheduler Documentation）の揺れや IRQ の偏りなど、実運用で発生しうるノイズの影響を受けやすくなります。

そのような条件下でも、SOCKET-MANAGER Framework は 10,000 → 50,000 → 100,000 接続の増加に対して線形に近いスケール特性 を示し、高負荷時でも破綻しない堅牢性を確認できました。

また、ペイロード 100 バイトの ping/pong フレーム（参考： RFC 6455） を用いた連続バーストにおいても、 10万同時接続時で平均 0.55ms 程度 に収まっており、 18,000〜20,000 rps 相当の実効スループット（10,000 接続あたり 1,800〜2,000 rps）を安定して処理できており、10万同時接続でも破綻しない堅牢性を示しています。

グラフで見るスケール特性

● Linux：接続数 vs アクセス集中時レイテンシ

→ 10,000 → 100,000 接続で 10 倍の接続数に対し、平均レイテンシは約 4.6 倍に収まり、CPU割当なしとしては素直なスケールを示しています。

● Linux：接続数 vs ping/pong レイテンシ

→ 10万同時接続・ラウンド間隔なしでも 0.5〜0.6ms 程度に収まっており、連続バースト条件としては非常に安定した値です。

● Windows：接続数 vs ping/pong レイテンシ

→ スケジューラの重い Windows 環境でも、5万同時接続・ラウンド間隔なしで平均 1ms 程度に収まっており、OS 特性を踏まえると十分に良好な結果です。

Linux 版（アクセス集中時）

アクセス集中時レイテンシ（単位：ms）

接続数	avg	mid	min	max	p90	p95
10,000	11.1423	10.1285	0.0801	31.9084	22.7463	24.7657
50,000	27.0608	25.9533	0.0752	85.1217	50.7054	53.9618
100,000	51.0224	49.8224	0.1773	214.3862	91.4050	100.9020

10,000 → 100,000 接続で約 10 倍の接続数に対し、平均レイテンシは約 4.6 倍に収まっています。CPU 割当なしでこのスケール特性は、実運用を考えると非常に良好な挙動です。

Linux 版 6 時間耐久テスト（ping/pong フレーム 100 バイト）

10,000 同時接続（ラウンド間隔 10 秒）

ラウンド数	avg	mid	min	max	p90	p95
2,155	0.2269	0.2272	0.2039	0.2639	0.2320	0.2361

50,000 同時接続（ラウンド間隔なし）

ラウンド数	avg	mid	min	max	p90	p95
31,769	0.3484	0.3461	0.3090	0.4249	0.3673	0.3728

100,000 同時接続（ラウンド間隔なし）

ラウンド数	avg	mid	min	max	p90	p95
38,739	0.5531	0.5506	0.4930	0.6975	0.5753	0.5847

10,000 接続時はラウンド間隔 10 秒の「余裕のある条件」、50,000 / 100,000 接続時はラウンド間隔なしの「連続バースト条件」です。
それにもかかわらず、10万同時接続でも平均 0.55ms 程度に収まっており、CPU 割当なしとしては非常に安定した値です。

Windows 版（アクセス集中時）

アクセス集中時レイテンシ（単位：ms）

接続数	avg	mid	min	max	p90	p95
10,000	20.9003	21.1037	0.1537	67.9925	38.6197	43.2785
50,000	36.0866	32.3841	0.1449	122.9753	63.8790	73.6337

※ Windows 版については、OS 標準設定のままでは 50,000 接続付近で WSAENOBUFS (10055)（参考：Microsoft Docs）が発生するため、本ページでは標準設定で安定動作する範囲（〜50,000 接続）を対象としています。これは OS 側の制約によるもので、サーバーアーキテクチャの限界ではありません。

Windows 版 6 時間耐久テスト（ping/pong フレーム 100 バイト）

10,000 同時接続（ラウンド間隔 10 秒）

ラウンド数	avg	mid	min	max	p90	p95
2,149	0.3779	0.3741	0.3289	1.3451	0.3851	0.3899

50,000 同時接続（ラウンド間隔なし）

ラウンド数	avg	mid	min	max	p90	p95
11,177	1.0453	1.0515	0.4827	1.2546	1.1178	1.1383

Windows は Linux に比べてスケジューラやタイマのオーバーヘッドが大きくなりがちですが、5万同時接続・ラウンド間隔なしの条件でも平均 1ms 程度に収まっており、Windows 環境としては非常に安定した結果です。

CPU割当なし・ラウンド間隔なしという厳しい条件下でも、SOCKET-MANAGER Framework は以下の特性を示しました。

• 10万同時接続時でも ping/pong 平均 0.55ms 程度
• 18,000〜20,000 rps 相当の実効スループットを維持（10,000 接続あたり 1,800〜2,000 rps）
• 全テストでエラーゼロ
• メモリは PHP 標準設定の 128MB のまま
• 接続数 10倍に対してレイテンシは約 4.6倍に収まる線形スケール

これらの結果は、本フレームワークが 性能・堅牢性・軽量性の3要素を高いレベルで両立している ことを示しています。

純粋性能については「ハイパフォーマンスモード」で詳しく解説しています。

▶ ハイパフォーマンスモード（純粋性能）を見る

フレームワーク全体の構成については「フレームワークのご紹介」をご覧ください。

▶ フレームワークのご紹介を見る