【ハイパフォーマンスモードの概要と設計思想】

PHPの同期ランタイムが持つ“状態の一貫性” と、独自IOドライバによるネイティブ級の高速処理。
この 2 つの強みを丁寧に組み合わせ、リアルタイム通信における 高性能と堅牢性 を両立するために設計されたのが ハイパフォーマンスモード です。

また、SOCKET-MANAGER Framework の内部処理は、 共有基盤（Union） を中心に ゼロコピー設計（Zero-copy Architecture） を採用しており、 UNIT 間でデータをコピーせずに受け渡せる構造になっています。 これにより、大量接続時でもメモリコピーによるオーバーヘッドが発生せず、 サブミリ秒帯のレイテンシを安定して維持できる 点が特徴です。

• バースト状態 100,000 同時接続の 6 時間耐久で 0.52ms のレイテンシを維持
• 19,000〜21,500 rps 相当の実効スループット（10,000 接続あたり 1,900〜2,150 rps）
• 最大 40,521 ラウンド（約 4 億 500 万回の往復通信）でもエラーなし
• プロセス内単一スレッド（スレッドプールなし）での安定動作
• ゼロコピー設計により、10,000 接続維持でも PHP 標準の 128MB 内に収まる軽量メモリフットプリント
• Windowsでも本番運用できるリアルタイム基盤
• FFI + 独自拡張による高速IO / select互換モード の自動切替

また、ハイパフォーマンスモードは IPC（プロセス間通信）とも高い親和性を持ちます。
IPC は通常の通信モジュールとして扱えるため、 ネイティブ IO ドライバをそのまま IPC に適用でき、プロセス間通信でも低レイテンシを維持 できます。

IPC の詳細については IPC（プロセス間通信） をご覧ください。

“速さ”だけでも、“堅牢性”だけでもない。
PHPの特性を活かしながら、本来のリアルタイム通信に求められるニーズを追求したフレームワークです。

>> ベンチマーク結果を見る
>> GitHubでコードを確認する

丁寧に積み上げた設計で圧倒的な処理性能

ハイパフォーマンスモードは、独自 IO ドライバと同期ランタイムの特性を組み合わせることで、 WebSocket / TCP 接続において 最大 100,000 同時接続をバースト状態の高負荷状態でも 0.52～0.55ms（サブミリ秒帯）で処理 する性能を実現しました。 Windows 環境でも 50,000 同時接続を 0.43～0.50ms（サブミリ秒帯）で処理 しており、OS を問わず安定したスケール特性を示します。

この結果は、単なるピーク値ではなく、大量同時接続のバースト状態を維持しながら 6 時間耐久テストをクリアした処理能力 を示すものです。
高負荷下でもレイテンシが安定しており、接続数が増えても エラーなし で処理時間が接続数に対して 線形にスケールする ことが確認されています。

なお、一般的に IPC（プロセス間通信）は TCP よりも低レイヤーで動作するため、 1 桁マイクロ秒帯 の処理性能を発揮できることが知られています。 SOCKET-MANAGER Framework では、この IPC を通常の通信モジュールとして扱えるため、 TCP とは別レイヤーで得られる マイクロ秒級の処理性能をそのまま活かすことができます。

TCP（100 バイトペイロード）

Linux

接続条件	avg (ms)	mid (ms)	min (ms)	max (ms)	p90 (ms)	p95 (ms)	ラウンド数
単接続 N=10000	0.0097	0.0083	0.0070	1.9501	0.0088	0.0097	–
10000（10s）	0.2005	0.1987	0.1809	0.2403	0.2090	0.2144	2,155
50000	0.3121	0.3109	0.2719	0.4205	0.3273	0.3328	34,126
100000	0.5249	0.5251	0.4649	0.6043	0.5424	0.5474	40,521

Windows

接続条件	avg (ms)	mid (ms)	min (ms)	max (ms)	p90 (ms)	p95 (ms)	ラウンド数
単接続 N=10000	0.0355	0.0185	0.0163	14.1896	0.0196	0.0203	–
10000（10s）	0.3140	0.3163	0.2728	0.3670	0.3262	0.3286	2,150
50000	0.4396	0.4381	0.3627	0.5522	0.4581	0.4644	24,225

純粋 TCP 通信の実運用スケール性能ベンチマークの詳細については 純粋 TCP スケール性能 をご覧ください。

WebSocket（100 バイトペイロード）

Linux

接続条件	avg (ms)	mid (ms)	min (ms)	max (ms)	p90 (ms)	p95 (ms)	ラウンド数
単接続 N=10000	0.0249	0.0215	0.0203	3.0309	0.0237	0.0274	–
10000（10s）	0.2269	0.2272	0.2039	0.2639	0.2320	0.2361	2,155
50000	0.3484	0.3461	0.3090	0.4249	0.3673	0.3728	31,769
100000	0.5531	0.5506	0.4930	0.6975	0.5753	0.5847	38,739

Windows

接続条件	avg (ms)	mid (ms)	min (ms)	max (ms)	p90 (ms)	p95 (ms)	ラウンド数
単接続 N=10000	0.0618	0.0415	0.0387	16.0933	0.0438	0.0462	–
10000（10s）	0.3779	0.3741	0.3289	1.3451	0.3851	0.3899	2,149
50000	0.5070	0.5054	0.4525	0.6242	0.5305	0.5380	21,483

WebSocket 通信の実運用スケール性能ベンチマークの詳細については WebSocket スケール性能 をご覧ください。

大量接続時のスケール特性と安定性の分析

ハイパフォーマンスモードは、「速さを追求するために堅牢性を犠牲にした」設計ではありません。

むしろ、アクセス集中時の

• アクセプト詰まりを防ぐ
• 同時接続数を素直にスケールさせる
• 同期ランタイムの一貫性を保つ

といった 堅牢性を守るための要件 を満たす過程で、結果として高い処理性能と安定性が得られています。

さらに、SOCKET-MANAGER Framework の内部処理は、 共有基盤（Union） を中心に ゼロコピー設計 を採用しており、 UNIT 間でデータをコピーせずに受け渡せるため、 大量接続時でもメモリ帯域の圧迫が起きにくく、 スループットとレイテンシの両面で安定性を維持 できます。

JMeter による大量接続ベンチ

JMeter の測定では、Opening handshake のみを実行する専用の TestPlan を使用しています。
ThreadGroup は 10,000 スレッド × 1 ループで構成され、純粋に WebSocket の接続処理だけを測定しています。
自作ツールによる性能の測定値は、JMeter による大量接続時の測定結果とも線形スケールで整合しており、複数回の測定でも大きなブレがありませんでした。

グラフで見る特性

● 接続数 vs 処理時間

→ 直線に近い伸び方を示し、スレッド分割なしでも安定したスケールを確認。

● 接続数 vs レイテンシ

→ 高負荷時でもレイテンシが跳ね上がらず、0.3〜0.4ms 付近で安定。

● CPU 使用率の推移

→ 単一プロセスでの処理にもかかわらず、スパイクが少なく安定した推移。

JMeter / WebSocket Open Connection ※エラーなし

OS	総接続数	処理時間	平均レイテンシ	スループット
Windows	30,000	10 秒	約 0.33ms	3,000 connections/sec
Linux（WSL2）	90,000	30 秒	約 0.33ms	3,000 connections/sec

※ メモリ設定 512MB（JMeter 側）

測定方法と環境をすべて開示し、再現性を重視

ハイパフォーマンスモードのベンチマークは、測定環境・手順・使用ツールをすべて公開することを前提 に実施しています。

一般的な負荷試験ツールでは、大量接続を維持する用途ではクライアント側が先に破綻するケースが多く、正確な測定が困難でした。

そのため、SOCKET-MANAGER ではより実運用に近い本来の 同時接続維持を前提にした専用のベンチマークツールを自作 し、そのツールも含めて公開することで、測定結果の透明性を担保しています。

なお、接続数の基準として 10,000 を採用しているのは、線形スケールを評価する際に「基準点として扱いやすい、十分に大きな整数値」であるためです。
1,000 では負荷が小さく、50,000 以上では測定そのものが重くなるため、10,000 は「スケール特性を確認するための現実的かつ再現性の高い基準値」として最適でした。

さらに、本フレームワークは プロセス内単一スレッド（スレッドプールなし） で動作するため、スケール特性の評価において「スレッド分散による補正」が一切入らず、純粋な処理能力を測定できます。
この値は純粋性能・耐久テストの双方で共通の基準として使用しており、測定条件の一貫性と比較のしやすさを確保するためのものです。

測定環境（概要）

• ノンスレッドセーフ（NTS）版のPHP
• Opcacheあり
• CPU割当なし（unpinned）
• メモリ 128 MB（PHP標準設定）
• 単一プロセス・単一スレッド（スレッドプールなし）で実行
• 独自 IO ドライバ（FFI）を使用
• フレームワーク側のログファイル出力なし
• 接続維持を保証する専用クライアントツールを使用
• 複数回測定し、結果が安定していることを確認

※ フレームワーク側のログ出力はファイル I/O の負荷が大きいため、純粋性能を測定する際は無効化しています。
※ 測定ツール自体も公開することで、誰でも同じ条件で再測定できるようにしています。

透明性を重視する理由

SOCKET-MANAGER Framework は、「数字だけを見せる」のではなく、「数字がどのように得られたか」を含めて公開する という方針を大切にしています。

これは、性能を誇張するためではなく、リアルタイム通信における 堅牢性と再現性を正しく評価してもらうための姿勢 です。

同期ランタイムの特性を活かした、一貫性のある状態管理

SOCKET-MANAGER Framework は、PHP の同期ランタイムが持つ 「処理の流れが明確で、状態が破綻しにくい」 という特性を基盤にしています。

リアルタイム通信では、複数の接続が同時に状態へアクセスする場面が多く、非同期モデルでは意図しないタイミングで状態が書き換わるリスクがあります。

同期ランタイムを前提にした本フレームワークでは、状態の一貫性を保ちながら処理を進められるため、複雑なリアルタイム処理でも破綻しにくい構造 を実現しています。

独自ステートマシンによる破綻しない接続管理

各接続は 独自のステートマシン で管理され、

• 予期しない状態遷移の防止
• 不正なデータや異常な切断への耐性
• 長時間稼働時の安定性

を確保しています。

これにより、接続数が増えても 「どの接続が今どの状態にあるか」 が常に明確で、大量接続時でも破綻しない堅牢な動作が可能になります。

長時間稼働でも安定した動作

実際の耐久テストでは、

• 10,000 / 50,000 / 100,000 の各接続 × 6 時間稼働でエラーゼロ
• メモリリークなし
• レイテンシの増加なし

といった結果が得られています。

これは、同期ランタイムの特性とステートマシン設計が 長時間の安定運用に向いている ことを示しています。

堅牢性を前提にした設計が、結果として性能にもつながる

このアーキテクチャは、「速さを追求するために堅牢性を削った」ものではありません。

むしろ、

• 状態破壊を防ぐ
• 接続ごとの処理を明確に保つ
• 長時間稼働でも破綻しない構造を作る

といった 堅牢性を守るための設計 が、結果として大量接続時の安定性や性能にもつながっています。

外部依存のない IPC とプロトコル非依存設計による拡張性

SOCKET-MANAGER Framework のアーキテクチャは、外部ミドルウェアに依存しない 独自の IPC 機構（例： UNIX domain socket、 Windows Named Pipe） とプロトコル非依存のステートマシンを基盤にしています。
この構造により、単一プロセスでの動作と複数プロセス構成のどちらでも同じインターフェースで扱うことができ、負荷に応じてプロセス数を増やすだけで処理能力を段階的に拡張できます。

また、外部ブローカーや専用キューを必要としないため、 マイクロサービス との連携やサービス分割も容易で、スケールアップ／スケールアウトのどちらにも上限を設けない設計になっています。 結果として、負荷に応じてプロセスやサービスを追加するだけで理論上はいくらでも処理能力を伸ばすことができ、リソース管理もシンプルで運用しやすい構成を実現しています。

環境に応じて最適な IO 処理を選択する仕組み

SOCKET-MANAGER Framework の IO ドライバは、「最大性能を発揮するモード」と「どんな環境でも確実に動くモード」 の 2 つの実行方式を備えています。

これは、利用環境の制約（FFI の有無・拡張の導入可否・OS 差異）を吸収しつつ、常に安定したリアルタイム通信を提供するための設計です。

High Performance Mode（FFI + 独自拡張）

FFI が有効な環境では、このモードが自動的に選択されます。

• OS ごとに最適化されたネイティブ IO 処理
• 大量接続時でも詰まりにくい構造
• Windows / Linux 双方で動作

リアルタイム通信で発生しがちな アクセプト詰まりやスケール問題を抑えつつ、安定した処理を維持できる ことが特徴です。

Compatibility Mode（selectベース）

FFI が利用できない環境では、従来の select ベース（従来型のポーリング方式）の IO 処理に自動的に切り替わります。

• 拡張モジュール不要
• どんな環境でも確実に動作
• 開発環境と本番環境の差異を最小化

このモードは「性能を最大化する」ためのものではなく、環境を選ばず動作するための“最後の砦” として機能します。

開発環境と本番環境の差異を最小化するための設計

SOCKET-MANAGER Framework は、Windows と Linux のどちらでも同じコードで安定して動作する ことを前提に設計されています。

多くのリアルタイムソリューションは Linux 前提で構築されることが多く、Windows では「開発環境としては使えるが、本番運用は想定していない」というケースが一般的です。

本フレームワークでは、開発環境と本番環境の差異を極力なくし、どちらのOSでも同じ挙動を得られること を重視しています。

IOドライバが OS に応じて自動的に最適化

ハイパフォーマンスモードでは、

• FFI が利用可能な場合は高速な独自 IO ドライバ
• FFI が利用できない場合は select ベースの互換モード

が自動的に選択されます。

これにより、Windows でも Linux と同様に大量接続を安定処理できることが、実測値でも確認されています。

Windows 環境での実運用を想定した動作検証

実際の検証では、Windows環境においても

• 10,000 / 50,000 の各接続 × 6 時間稼働でエラーゼロ
• メモリ使用量の安定
• レイテンシの増加なし

といった結果が得られています。

これは、OS 固有の差異を吸収する IO ドライバ構造と、同期ランタイムの一貫性を活かしたアーキテクチャによるものです。

Windows を選択できることが、利用者の自由度につながる

SOCKET-MANAGER Framework は、「Windows を推奨する」わけでも「Linux を前提とする」わけでもありません。

利用者が既存のインフラや運用方針に合わせて自由に選択できること そのものが価値であると考えています。

• 社内システムが Windows サーバー中心
• Azure の Windows VM を利用している
• IIS や .NET と共存させたい
• 開発環境と本番環境を揃えたい

こうしたケースでも、リアルタイム通信を無理なく導入できるようにすることが目的です。

幅広いリアルタイム処理に適した、扱いやすい基盤

SOCKET-MANAGER Framework は、
「大量接続を安定して処理できること」
「状態が破綻しにくいこと」
「Windows / Linux どちらでも同じように動くこと」
といった特徴から、さまざまなリアルタイム用途に適しています。

特別な構成や複雑な非同期処理を前提とせず、PHP の同期ランタイムをそのまま活かせる ため、既存の PHP プロジェクトにも導入しやすい点が特徴です。

チャット・メッセージング

• 多数の接続を安定して維持できる
• 状態管理が明確で、メッセージの整合性を保ちやすい
• 長時間接続が前提のサービスでも破綻しにくい

IoT・デバイス通信

• デバイス数が増えても接続管理が破綻しにくい
• 単一プロセスでの動作が読みやすく、トラブルシュートしやすい
• Windows 環境でも動作するため、工場内システムなどにも導入しやすい

リアルタイム監視・通知

• センサー値やログのストリーミングに向いている
• レイテンシが安定しているため、通知の遅延が発生しにくい
• 状態の一貫性を保てるため、監視ロジックがシンプルに書ける

ゲーム・インタラクティブコンテンツ

• 接続ごとの状態をステートマシンで管理できる
• 同期ランタイムにより、処理の流れが追いやすい
• 大量接続時でも安定したレイテンシを維持

社内システム・業務アプリケーション

• Windows サーバー環境でも本番運用できる
• 既存の PHP ベースの社内システムに組み込みやすい
• 運用チームが PHP に慣れている場合、導入コストが低い

導入メリット

• 既存の PHP 資産を活かしながらリアルタイム通信を追加できる
• 非同期モデル特有の複雑さを避けつつ、大量接続を安定して処理できる
• Windows / Linux どちらでも同じように動作するため、環境差異を気にせず導入できる
• ステートマシンによる明確な状態管理で、トラブルシュートが容易
• 長時間稼働でも破綻しにくい堅牢性

【ご注意】
ハイパフォーマンスモードを利用するには、SOCKET-MANAGER Framework のv1.24 以降が必要です。
プロジェクトのルートディレクトリで php worker を実行すると、Usage 情報とともに現在のバージョンが表示されますので、導入前にご確認ください。

前提条件

• PHP 8.4 以降で動作
• ハイパフォーマンスモードを利用するには FFI の有効化 と

socketsfd 拡張モジュールの導入 が必要です。

※ PHP の ZTS 版でも安全に動作しますが、NTS 版の方がよりパフォーマンスが良くなります。

FFI を有効化する

php.ini に以下を設定します。

ffi.enable = true
        

※ PHP 本体に FFI モジュールが含まれていない場合は、別途 FFI を導入する必要があります（環境により異なります）。

拡張モジュール（socketsfd）の導入

Linux（Ubuntu / Debian）

1. 以下のファイルを PHP の拡張モジュールディレクトリへコピー

vendor/socket-manager/library/prebuild/linux/ubuntu-debian/socketsfd.so
                        

2. php.ini に以下を追加

extension=socketsfd
                        

Windows

1. 以下の DLL を PHP の拡張モジュールディレクトリ（通常は ext）へコピー

vendor/socket-manager/library/prebuild/windows/php_socketsfd.dll
                        

2. php.ini に以下を追加

extension=socketsfd
                        

3. 注意：Windows では sockets 拡張と競合するため、以下を無効化

;extension=sockets
                        

ハイパフォーマンスモードの自動適用

WebSocket サーバープロジェクトでは、通常どおり実行するだけで環境に応じて最適な IO ドライバが自動選択されます。

$ php worker app:websocket-server <接続制限数>
        

ハイパフォーマンスモードが適用されている場合、起動時に以下のメッセージが表示されます。

Boot sequence finished — running in Adaptive IO-Driver Mode.
        

Ubuntu / Debian 以外の Linux でのビルド

プリビルド版が利用できない環境では、socketsfd 拡張モジュール と FFI モジュール をコンパイルする必要があります。

socketsfd 拡張モジュール

• ソースコード
  

  vendor/socket-manager/library/ext/socketsfd/socketsfd.c
                          

  
  
• ビルド手順
  
  vendor/socket-manager/library/ext/socketsfd/README.md に記載

FFI モジュール

1. 以下のディレクトリへ移動
   

   vendor/socket-manager/library/ffi/linux
                           

   
   
2. build.sh を実行
   
   → コンパイル後、自動的に適用されます。

ベンチマークツール

ハイパフォーマンスモードの特性を正しく測定するために、SOCKET-MANAGER では 専用のベンチマークツール を提供しています。
このツール自体もハイパフォーマンスモードで動作させることで、クライアント側のボトルネックを避け、より正確な測定が可能になります。

リポジトリ

https://github.com/socket-manager/launcher

インストール

> composer create-project socket-manager/launcher
                

※ 使用するプロトコルにより起動方法は異なりますので、以下のページを参照してください。

▶ WebSocket スケール性能
▶ 純粋 TCP スケール性能

フレームワーク本体

リポジトリ

https://github.com/socket-manager/library

インストール

通常は WebSocket プロジェクトなどの個別プロジェクトをインストールする際に 自動的に導入されます。

各プロジェクト内で以下を実行することで、ライブラリを最新バージョンへ更新できます。

> composer update socket-manager/library