【ハイパフォーマンスモード】

ハイパフォーマンスモードとは(概要)

PHPの同期ランタイムが持つ“状態の一貫性”と、独自IOドライバによるネイティブ級の高速処理。
この 2 つの強みを丁寧に組み合わせ、リアルタイム通信における 高性能と堅牢性 を両立するために設計されたのが ハイパフォーマンスモード です。
  • 最大 90,000 接続を 30 秒で処理する純粋性能(Linux)
  • 30,000 接続を 10 秒で処理する安定したスケール(Windows)
  • 単一スレッド・単一プロセス(スレッドプールなし)での安定動作
  • 10,000 接続維持でも 128MB 内に収まる軽量メモリフットプリント
  • Windowsでも本番運用できるリアルタイム基盤
  • FFI + 独自拡張による高速IO / select互換モード の自動切替
“速さ”だけでも、“堅牢性”だけでもない。
PHPの特性を活かしながら、本来のリアルタイム通信に求められるニーズを追求したフレームワークです。

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

ベンチマーク結果


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

ハイパフォーマンスモードは、独自 IO ドライバと同期ランタイムの特性を組み合わせることで、 WebSocket 接続において 最大 90,000 接続を 30 秒で処理 する性能を実現しました(Linux / メモリ 512MB)。 Windows 環境でも 30,000 接続を 10 秒で処理 しており、OS を問わず安定したスケール特性を示します。

(参考:MDN WebSocket API

この結果は、単なるピーク値ではなく、単一スレッド・単一プロセス(スレッドプールなし)での純粋な処理能力 を示すものです。
  • 総接続数:90,000
  • 処理完了までの時間:30秒
  • 平均レイテンシ:0.35ms(線形スケール)
  • スループット:3,000 connections/sec
  • エラー発生:0件
  • 測定条件:WebSocket の Opening handshake のみを対象とした測定
高負荷下でもレイテンシが安定しており、接続数が増えても処理時間がほぼ線形に伸びることが確認されています。

グラフで見る特性

接続数 処理時間(秒) 90,000 接続 / 30 秒

接続数 レイテンシ(ms) 安定帯(0.3〜0.4ms) 90,000 接続 / 0.35ms

時間 CPU 使用率(%) スパイクの少ない安定したCPU使用率

● 接続数 vs 処理時間

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

● 接続数 vs レイテンシ

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

● CPU 使用率の推移

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


ベンチマーク実測値(表)

以下は、グラフの裏付けとなる 実測値の一覧 です。
すべて エラーなし で測定されています。

■純粋性能

以下の表は単接続での ping/pong フレーム(ペイロード部 100 byte の送受信)を 10,000 回繰り返した状況での測定結果です。
純粋性能(単接続 N=10,000 の ping/pong レイテンシ)※エラーなし
OS avg mid min max p90 p95
Windows 0.4174ms 0.0773ms 0.0475ms 16.0118ms 0.1108ms 0.1983ms
Linux(WSL2) 0.0493ms 0.0450ms 0.0269ms 3.5851ms 0.0649ms 0.0721ms

■耐久テスト(6時間 / 10,000 接続維持)

耐久テストでは、すべての測定を 10,000 接続を維持した状態で、PHP 標準設定の 128MB メモリ制限内で実行 しています。
Windows 環境ではピーク 124.8MB、Linux(WSL2)環境ではピーク 75.95MB にとどまっており、 大量接続・長時間稼働を前提としながらも 「軽量な PHP フレームワーク」として運用しやすい設計 になっています。

以下の表はハンドシェイクの重い処理(opening → header parse → handshake → SHA1Base64 → send())を接続維持しながら同時接続した場合の測定結果です。
つまり、メモリ管理(GC動作)やイベントループが全接続に対して常に実行されている状況での動作です。
耐久テスト(接続時ハンドシェイクのレイテンシ)※エラーなし
OS ピークメモリ avg mid min max p90 p95
Windows 124.8MB 20.9003ms 21.1037ms 0.1537ms 67.9925ms 38.6197ms 43.2785ms
Linux(WSL2) 75.95MB 11.1423ms 10.1285ms 0.0801ms 31.9084ms 22.7463ms 24.7657ms

以下の表は上記ハンドシェイク後、全 10,000 接続に対して ping/pong フレーム(ペイロード部 100 byte の送受信)を 10 秒間隔で同時実行する動作を 6 時間経過するまで繰り返した状況での測定結果です。
耐久テスト(ping/pong ラウンドのレイテンシ)※エラーなし
OS ラウンド数 avg mid min max p90 p95
Windows 2149 0.3779ms 0.3741ms 0.3289ms 1.3451ms 0.3851ms 0.3899ms
Linux(WSL2) 2155 0.2269ms 0.2272ms 0.2039ms 0.2639ms 0.2320ms 0.2361ms

■大量接続ベンチ(最大 90,000 接続 / 30 秒)

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 側)

この数字が示しているもの

Linux / Windows の両方で 1 秒あたり 2,700〜3,000 接続のスループットが得られており、OS に依存しない安定したスケール特性が確認できます。

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

むしろ、アクセス集中時の
  • アクセプト詰まりを防ぐ
  • 同時接続数を素直にスケールさせる
  • 同期ランタイムの一貫性を保つ
といった 堅牢性を守るための要件 を満たす過程で、結果として高い処理性能と安定性が得られています。

測定の透明性


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

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

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

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

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

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

JMeter の測定では、Opening handshake のみを実行する専用の TestPlan を使用しています。
ThreadGroup は 10,000 スレッド × 1 ループで構成され、純粋に WebSocket の接続処理だけを測定しています。

測定環境(概要)

  • ノンスレッドセーフ(NTS)版のPHP
  • Opcacheあり
  • メモリ 128 MB(PHP標準設定)
  • 単一プロセス・単一スレッド(スレッドプールなし)で実行
  • 独自 IO ドライバ(FFI)を使用
  • フレームワーク側のログファイル出力なし
  • 接続維持を保証する専用クライアントツールを使用
  • 複数回測定し、結果が安定していることを確認
※ フレームワーク側のログ出力はファイル I/O の負荷が大きいため、純粋性能を測定する際は無効化しています。

測定結果が示す再現性

自作ツールによる純粋性能の測定値は、JMeter による大量接続時の測定結果とも線形スケールで整合しており、複数回の測定でも大きなブレがありませんでした。
また、測定ツール自体も公開することで、誰でも同じ条件で再測定できるようにしています。

透明性を重視する理由

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

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

アーキテクチャの強みと裏付け


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

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

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

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

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

各接続は独自のステートマシンで管理され、
  • 予期しない状態遷移の防止
  • 不正なデータや異常な切断への耐性
  • 長時間稼働時の安定性
を確保しています。

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

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

実際の耐久テストでは、
  • 10,000 接続 × 6 時間稼働でエラーゼロ
  • メモリリークなし
  • レイテンシの増加なし
といった結果が得られています。

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

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

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

むしろ、
  • 状態破壊を防ぐ
  • 接続ごとの処理を明確に保つ
  • 長時間稼働でも破綻しない構造を作る
といった 堅牢性を守るための設計 が、結果として大量接続時の安定性や性能にもつながっています。

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

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

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

IO ドライバの 2 モード構成


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

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

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

High Performance Mode(FFI + 独自拡張)

FFI が有効な環境では、このモードが自動的に選択されます。
  • OS ごとに最適化されたネイティブ IO 処理
  • 大量接続時でも詰まりにくい構造
  • Windows / Linux 双方で動作
リアルタイム通信で発生しがちな アクセプト詰まりやスケール問題を抑えつつ、安定した処理を維持できる ことが特徴です。

Compatibility Mode(selectベース)

FFI が利用できない環境では、従来の select ベースの IO 処理に自動的に切り替わります。
  • 拡張モジュール不要
  • どんな環境でも確実に動作
  • 開発環境と本番環境の差異を最小化
このモードは「性能を最大化する」ためのものではなく、環境を選ばず動作するための“最後の砦” として機能します。

Windows 環境でも実運用を想定


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

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

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

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


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

ハイパフォーマンスモードでは、
  • FFI が利用可能な場合は高速な独自 IO ドライバ
  • FFI が利用できない場合は select ベースの互換モード
が自動的に選択されます。

これにより、Windows でも Linux と同じように大量接続を安定して処理できる ようになっています。


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

実際の検証では、Windows環境においても
  • 10,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
                            

起動方法(簡易形式)

混雑状態ベンチ

接続数が増えた際のスケール特性を測定します。
> php worker app:concurrent-load-benchmark <サンプル数>
                                    

純粋性能ベンチ

IO ドライバの純粋な処理性能を測定します。
> php worker app:pure-latency-benchmark <サンプル数>
                                    

耐久テスト

長時間稼働時の安定性を測定します。
> php worker app:pure-latency-benchmark <サンプル数>
                                    

フレームワーク本体


リポジトリ

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

インストール

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

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