【純粋TCP通信の実運用スケール性能ベンチマーク】
はじめに（CPU割当なしでの測定について）
TCP 実装と実運用に近い測定構成
本ページで紹介するベンチマーク結果は、SOCKET-MANAGER Framework の基盤上に TCP エコー処理を ステートマシン で実装した実運用想定の構成 で測定したものです。単なる「フレームワーク単体の速度測定」ではなく、 プロトコル処理・ UNIT/Queue の状態遷移 ・イベントループ を含む フレームワーク全体の実行パスを通した純粋性能です。
長時間耐久テストでは、TCP ソケットを用いた 10,000 / 50,000 / 100,000 接続を維持しながら実施した CPU 割当なしで実運用想定の 6 時間耐久ベンチマーク の結果をまとめています。
FFI・Sockets を用いた IO と CPU 割当なしの動作
内部処理では PHP の FFI や Sockets 拡張 を活用した IO ドライバが動作しており、CPU 割当なしでも安定した処理が可能です。Union によるゼロコピー設計と軽量コンテキスト管理
SOCKET-MANAGER Framework の共有基盤（Union）は メモリコピーを極力発生させないゼロコピー設計 を採用しており、 セッションコンテキストやフレームデータを 不要なコピーなしで各処理系（UNIT / Queue / EventLoop）へ受け渡せます。 このゼロコピー設計により、10万同時接続規模でも GC 負荷を抑えつつ、 実測でも確認された サブミリ秒帯の安定レイテンシ を維持できる構造になっています。ラウンド間隔なしの連続バーストと高負荷テスト
5万・10万接続の echo テストでは ラウンド間隔なし で数万ラウンド規模の連続バーストを実施しており、 実際のサービス運用よりも厳しい条件での動作確認となっています。エラーなし・128MB メモリでの長時間安定性
すべての測定において エラーは発生せず、PHP のメモリ設定は標準の 128MB のままです。つまりこのページは、「実運用想定の条件で壊れないか」を検証することに主眼を置いた結果です。
>> ベンチマーク結果を見る
FFI の独自 IO ドライバによるネイティブ級の性能を実現する機能については「ハイパフォーマンスモード」で詳しく解説しています。
▶ ハイパフォーマンスモードを見る
WebSocket と TCP のスケール特性を比較したい場合は、以下のページも参照してください。
▶ WebSocket スケール性能を見る
テスト条件
共通条件
- CPU割当：なし（プロセス・スレッドの CPU ピニングなし）
- メモリ設定：PHP 標準の 128MB
- 接続数：10,000 / 50,000 / 100,000
- 処理内容：TCP echo（ペイロード 100バイト）
- OS：Linux（WSL2） / Windows
- テスト時間：6 時間（接続維持）
ラウンド条件
- 10,000 接続時 echo：ラウンド間隔 10秒
- 50,000 / 100,000 接続時 echo：ラウンド間隔なし（完了後すぐ次ラウンド）
- 1ラウンドあたりの同時処理件数：常に 10,000
結果サマリー（性能・堅牢性・軽量性）
性能（Performance）
- 10万同時接続時の echo 平均レイテンシ：0.524ms（Linux）
- 5万同時接続時の echo 平均レイテンシ：0.312ms（Linux）
- ラウンド間隔なしで 1ラウンド 10,000 件を約 5〜6 秒で連続処理
堅牢性（Robustness）
- 全テストで エラー発生ゼロ
- ラウンド間隔なしの連続バーストでも破綻なし
- 10,000 → 100,000 接続でレイテンシは約 2.6 倍に収まり、スケールは線形に近い
軽量性（Lightweight）
- 全テストを通じて PHP のメモリ設定は 128MB のまま
- 接続数増加や長時間運用によるメモリ膨張なし
ハイパフォーマンスモードは、独自 IO ドライバと同期ランタイムの特性を組み合わせることで、 TCP 接続において 最大 100,000 同時接続をバースト状態の高負荷状態でも 0.52（サブミリ秒帯）で処理 する性能を実現しました。 Windows 環境でも 50,000 同時接続を 0.43（サブミリ秒帯）で処理 しており、OS を問わず安定したスケール特性を示します。
この結果は、単なるピーク値ではなく、大量同時接続のバースト状態を維持しながら 6 時間耐久テストをクリアした処理能力 を示すものです。
高負荷下でもレイテンシが安定しており、接続数が増えても エラーなし で処理時間が接続数に対して 線形にスケールする ことが確認されています。
スケール特性が証明した強み
今回の 10,000 / 50,000 / 100,000 接続の耐久ベンチマークにより、
SOCKET-MANAGER Framework のアーキテクチャが持つ以下の特徴が、
実運用スケールでも破綻しないことが明確になりました。
UNIT / Queue モデルの詳細は >> イベントハンドラについて にて解説しています。
10万同時接続・連続バーストという厳しい条件下でも破綻しなかったのは、 このステートマシン構造が正しく機能している証拠です。
ステートマシンの詳細は >> イベント駆動アーキテクチャ を参照してください。
実際、今回のベンチマークでもプロセス構成を変えるだけで スケール戦略を柔軟に組み替えられることが確認できました。
IPC の詳細は >> IPC（プロセス間通信） にて解説しています。
これはマイクロサービス構成との親和性を高め、 実運用でのスケール戦略を大幅に柔軟にします。
マルチサーバー構成の詳細は >> マルチサーバーの構成 を参照してください。
これにより、プロセス単位のスケール戦略と CPU リソース戦略を 一体化して最適化でき、より高いスケーラビリティを実現できます。
CPU 割当の詳細は >> ランチャーのサービス設定 を参照してください。
今回のベンチマークは、 SOCKET-MANAGER Framework が「スケールしやすい構造」を持つだけでなく、 実運用レベルでもその構造が正しく機能することを証明する結果となりました。
1. ステートマシン I/F による「状態破壊のないスケール」
フレームワーク本体にビルトインされた UNIT / Queue モデルは、 非同期処理中でも状態破壊が起きない構造を持っています。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 が「スケールしやすい構造」を持つだけでなく、 実運用レベルでもその構造が正しく機能することを証明する結果となりました。
ベンチマーク結果
純粋性能
以下の表は単接続での TCP echo （ペイロード部 100 byte の送受信）を 10,000 回繰り返した状況での測定結果です。なお、一般的に IPC（プロセス間通信）は TCP よりも低レイヤーで動作するため、 1 桁マイクロ秒帯 の処理性能を発揮できることが知られています。 SOCKET-MANAGER Framework では、この IPC を通常の通信モジュールとして扱えるため、 TCP とは別レイヤーで得られる マイクロ秒級の処理性能をそのまま活かすことができます。
| OS | avg | mid | min | max | p90 | p95 |
|---|---|---|---|---|---|---|
| Linux | 0.0097ms | 0.0083ms | 0.0070ms | 1.9501ms | 0.0088ms | 0.0097ms |
| Windows | 0.0355ms | 0.0185ms | 0.0163ms | 14.1896ms | 0.0196ms | 0.0203ms |
実運用を想定した条件でのスケール特性
CPU割当なしの状態では、OS スケジューラ（参考：Linux Scheduler Documentation）の揺れや IRQ の偏りなど、実運用で発生しうるノイズの影響を受けやすくなります。Linux 環境では、カーネルの TCP/IP スタック （参考：Linux TCP/IP stack） やイベント通知機構である epoll （参考：epoll） の挙動もレイテンシに影響するため、 高負荷時の安定性はフレームワークの設計品質を測る重要な指標となります。
そのような条件下でも、SOCKET-MANAGER Framework は 10,000 → 50,000 → 100,000 接続の増加に対して線形に近いスケール特性 を示し、高負荷時でも破綻しない堅牢性を確認できました。
SOCKET-MANAGER Framework では、OS レベルのスケジューラや TCP/IP スタックの挙動に加えて、 共有基盤（Union）においても ゼロコピーを前提としたコンテキスト管理 を行っています。 フレームデータやセッション情報をコピーせずに各処理系へ受け渡すため、 GC の影響が増幅しにくく、 高負荷時でもレイテンシが滑らかに増加する安定したスケール特性 を示します。
また、ペイロード 100 バイトの TCP echo を用いた連続バーストにおいても、 10万同時接続時で平均 0.52ms 程度 に収まっており、 19,000〜21,500 rps 相当の実効スループット（10,000 接続あたり 1,900〜2,150 rps）を安定して処理できており、10万同時接続でも破綻しない堅牢性を示しています。
グラフで見るスケール特性
- ● Linux：接続数 vs echo レイテンシ
-
→ 10万同時接続・ラウンド間隔なしでも 0.50〜0.55ms 程度に収まっており、連続バースト条件としては非常に安定した値です。
→ 10,000 → 100,000 接続で 10 倍の接続数に対し、平均レイテンシは約 2.6 倍に収まり、CPU割当なしとしては素直なスケールを示しています。
- ● Windows：接続数 vs echo レイテンシ
-
→ スケジューラの重い Windows 環境でも、5万同時接続・ラウンド間隔なしで平均 0.44ms 台に収まっており、OS 特性を踏まえると十分に良好な結果です。
→ 10,000 → 50,000 接続で 5 倍の接続数に対し、平均レイテンシは約 1.4 倍に収まり、CPU割当なしとしては素直なスケールを示しています。
Linux 版 6 時間耐久テスト（TCP echo 100 バイト）
10,000 → 100,000 接続で約 10 倍の接続数に対し、平均レイテンシは約 2.6 倍に収まっています。 CPU 割当なしでこのスケール特性は、実運用を考えると非常に良好な挙動です。以下の表は、各接続数に応じて TCP echo （ペイロード部 100 byte の送受信）で同時実行する動作を 6 時間経過するまで繰り返した状況での測定結果です。
10,000 同時接続（ラウンド間隔 10 秒）
| ラウンド数 | avg | mid | min | max | p90 | p95 |
|---|---|---|---|---|---|---|
| 2,155 | 0.2005 | 0.1987 | 0.1809 | 0.2403 | 0.2090 | 0.2144 |
50,000 同時接続（ラウンド間隔なし）
| ラウンド数 | avg | mid | min | max | p90 | p95 |
|---|---|---|---|---|---|---|
| 34,126 | 0.3121 | 0.3109 | 0.2719 | 0.4205 | 0.3273 | 0.3328 |
100,000 同時接続（ラウンド間隔なし）
| ラウンド数 | avg | mid | min | max | p90 | p95 |
|---|---|---|---|---|---|---|
| 40,521 | 0.5249 | 0.5251 | 0.4649 | 0.6043 | 0.5424 | 0.5474 |
Windows 版 6 時間耐久テスト（TCP echo 100 バイト）
Windows は Linux より scheduler jitter が大きく、 IOCP の wakeup コストも高いため、TCP echo でも Linux より高いレイテンシとなります。それでも 50,000 接続・ラウンド間隔なしで平均 0.44ms 台に収まっており、 OS 特性を踏まえると極めて良好な結果です。
以下の表は、各接続数に応じて TCP echo （ペイロード部 100 byte の送受信）で同時実行する動作を 6 時間経過するまで繰り返した状況での測定結果です。
10,000 同時接続（ラウンド間隔 10 秒）
| ラウンド数 | avg | mid | min | max | p90 | p95 |
|---|---|---|---|---|---|---|
| 2,150 | 0.3140 | 0.3163 | 0.2728 | 0.3670 | 0.3262 | 0.3286 |
50,000 同時接続（ラウンド間隔なし）
| ラウンド数 | avg | mid | min | max | p90 | p95 |
|---|---|---|---|---|---|---|
| 24,225 | 0.4396 | 0.4381 | 0.3627 | 0.5522 | 0.4581 | 0.4644 |
WSAENOBUFS (10055)（参考：Microsoft Docs）が発生するため、本ページでは標準設定で安定動作する範囲（〜50,000 接続）を対象としています。これは OS 側の制約によるもので、サーバーアーキテクチャの限界ではありません。ベンチマークツールと関連情報
ベンチマークツール
ハイパフォーマンスモードの特性を正しく測定するために、SOCKET-MANAGER では 専用のベンチマークツール を提供しています。このツール自体もハイパフォーマンスモードで利用する方がより正確に測定できます。
- リポジトリ
-
https://github.com/socket-manager/launcher
- インストール
-
> composer create-project socket-manager/launcher
- 起動方法（簡易形式）
-
- 純粋性能ベンチ
-
IO ドライバの純粋な処理性能を測定します。> php worker app:tcp-pure-latency-benchmark <サンプル数>
- 耐久テスト
-
長時間稼働時の安定性を測定します。> php worker app:tcp-stress-test <サンプル数>
フレームワーク本体
- リポジトリ
-
https://github.com/socket-manager/library
- インストール
-
通常は WebSocket プロジェクトなどの個別プロジェクトをインストールする際に 自動的に導入されます。
各プロジェクト内で以下を実行することで、ライブラリを最新バージョンへ更新できます。
> composer update socket-manager/library
おわりに
今回の純粋 TCP ベンチマークでは、
SOCKET-MANAGER Framework が持つステートマシン構造・UNIT/Queue モデル・
プロトコル抽象化レイヤといったアーキテクチャ上の特徴が、
10万同時接続・連続バースト・6 時間耐久 という
実運用を想定した厳しい条件下でも破綻しないことが確認できました。
特に、CPU 割当なしの状態であっても 10万同時接続で平均 0.52ms（Linux） という サブミリ秒帯のレイテンシを安定して維持できた点は、 フレームワークのイベントループ設計が正しく機能していることを示す重要な結果です。
また、Windows 環境でも OS 特性を踏まえたうえで 5万同時接続で平均 0.44ms 台 に収まっており、 クロスプラットフォームでの安定性も確認できました。
FFI の独自 IO ドライバによるネイティブ級の性能を実現する機能については「ハイパフォーマンスモード」で詳しく解説しています。
▶ ハイパフォーマンスモードを見る
WebSocket と TCP のスケール特性を比較したい場合は、以下のページも参照してください。
▶ WebSocket スケール性能を見る
フレームワーク全体の構成については「フレームワークのご紹介」をご覧ください。
▶ フレームワークのご紹介を見る
特に、CPU 割当なしの状態であっても 10万同時接続で平均 0.52ms（Linux） という サブミリ秒帯のレイテンシを安定して維持できた点は、 フレームワークのイベントループ設計が正しく機能していることを示す重要な結果です。
また、Windows 環境でも OS 特性を踏まえたうえで 5万同時接続で平均 0.44ms 台 に収まっており、 クロスプラットフォームでの安定性も確認できました。
FFI の独自 IO ドライバによるネイティブ級の性能を実現する機能については「ハイパフォーマンスモード」で詳しく解説しています。
▶ ハイパフォーマンスモードを見る
WebSocket と TCP のスケール特性を比較したい場合は、以下のページも参照してください。
▶ WebSocket スケール性能を見る
フレームワーク全体の構成については「フレームワークのご紹介」をご覧ください。
▶ フレームワークのご紹介を見る