あえてPHPでリアルタイム通信をやってみる

フロントエンド・PHPカンファレンス北海道2026
#frontend_phpcon_do #vaddy_room

Transcript

1. あえてPHPでリアルタイム通信をやってみる 2026-06-06 フロントエンド・PHPカンファレンス北海道2026 宮本直幸@MSprzk
2. $ cat profile.service [Unit] Description=Self Introduction After=network.target [Profile] Name="Miyamoto Naoyuki" Twitter="@Msprzk" Affiliation="北海道情報大学2年" Interest="Network",”Security”,”WebRTC”
4. 北海道のおすすめのところ
5. 伝えたいこと PHPは、リアルタイム通信ができないわけではない
6. きっかけ
7. ←WebSocket, WebRTCが大好き ←PHPはTODOアプリを作ったことがあるくらい
8. PHPでもリアルタイム通信をできるのかな? 調べてみたらあんまり得意ではなさそう...
9. PHPでもリアルタイム通信をできるのかな? 調べてみたらあんまり得意ではなさそう... やってみなくちゃわからない
10. そもそもリアルタイム通信とは
11. 遅延が少なく、ほぼリアルタイムで通信すること(厳密な定義は不明) 通話、ビデオ会議、オンラインゲームなどで使われることが多い リアルタイム通信技術の例: WebSocket, WebRTC, etc… リアルタイム通信とは
12. 検証の環境 バージョンと環境 - MacBook Air M2 - Memory 8GB - PHP: 8.5.6 - Go: 1.26.3 - Node.js: v26.0.0
13. 検証方法 - PHP / TypeScript / Go でWebSocket relayを実装 - 動画を送信し、20のreceiverにrelayする - 送信は基本的にPlaywrightのheadless(GUI付きとあまり変わらない結果 だったので、全てheadlessで撮り直しました) - 各実装ごとに10回実行 - 実行順による偏りを避けるため、ランダムな順番で実行 - 各実行ごとにp95, p99, max latency, loss, append error を計測 - 比較値は主に10回の実行の median p95, p99 = 遅延分布の95%, 99%地点. 99%地点が悪いほど、まれに大きくつまっているということ
14. UI使ったバージョン
15. 実験結果
16. 単一プロセスの場合 実装 loss append error 受信側p99 遅延 サーバ側 p99遅延 評価 TS 0 0 15.05ms 3.00ms 成立 PHP 0 0 61.95ms 19.50ms 成立 Go 0 0 24.80ms 5.50ms 成立 ※ p99: 遅延分布の99%地点。数値は10回実行した中央値。 ※ 受信側 p99 遅延: 各receiverのp99を平均した値。
17. そんなことあるか? PHPの仕様について調べてみよう
18. PHPの強み →Web向けサーバーサイドスクリプト →短命のHTTP処理が得意 →通常のWeb Page, API処理では強み PHPの仕様
19. リアルタイム通信で必要な性質 →短命ではなく長命のconnection →slow receiverの影響を他receiverから隔離する →receiver ごとの queue を持つ PHPの仕様
20. リアルタイム通信で必要な性質 →短命ではなく長命のconnection →slow receiverの影響を他receiverから隔離する →receiver ごとの queue を持つ PHPの仕様 仮説: PHP(FPM)の強みは、リアルタイム通信では 相性が良くないはず
21. 単一プロセスで動くものは少ないよね... Node.jsのような, PHPの代表的な 実行環境について調べてみよう
22. PHP-FPM: PHPのWeb実行環境 PHP-FPM
23. PHP-FPM: PHPのWeb実行環境 PHP-FPM
24. PHP-FPM
25. 検証内容: 長命WebSocket接続がreadyになるまでの待ち時間 Clients: 6 maxWorkers: 2 Hold: 10秒 ※maxWorkersは、workerの占有をわかりやすくするために意図的に低い上限にしています ※Hold → 接続を張ったあと、その接続を保持し続ける時間 PHP-FPM(風)
26. PHP-FPM(風) 実装 モデル ready p50 ready p99 評価 php-process-pool FPM的worker pool 10112.00ms 20218.50ms 後続接続が待 たされる ts-native Node.js event loop 4.00ms 9.00ms ほぼ同時 go-native Go goroutine 4.00ms 14.00ms ほぼ同時
27. なぜ待たされるのか 長命接続が worker を占有する ↓ worker 数を超えた接続は ready になる前に待たされる
28. 1. 接続を変える場所 - 長命接続をどの実行モデルで持つか - FPM風 worker poolでは、connectionがworkerを占有 2. 接続後に送る場所 - 接続済みreceiverにどう配信するか - 遅いreceiverの影響を他receiverに波及させないか リアルタイム通信で詰まる場所は2つある
29. FPM風 worker poolから外しても、リアルタイム通信の難しさは消 えるわけではない 接続済み receiverに動画を送る時、遅い（回線の悪い)receiverが いると、他receiverに波及する可能性がある →同じPHPの単一常駐プロセス内で、送信設計を変えて比較 単一常駐プロセス内の送信設計
30. FPM風 worker poolから外しても、リアルタイム通信の難しさは消 えるわけではない 接続済み receiverに動画を送る時、遅い（回線の悪い)receiverが いると、他receiverに波及する可能性がある →同じPHPの単一常駐プロセス内で、送信設計を変えて比較 単一常駐プロセス内の送信設計
31. php-ws php-ws-queued 順番に送る 書けるものから 書く
32. 実装 送信設計 受信側p99 サーバー側p99 通常receiver p99 評価 php-ws 全receiverへ同 期write 95.90ms 13.00ms 86.49ms 波及しやすい php-ws-queued receiverごとの write buffer 46.67ms 3.00ms 27.12ms 波及が減る
33. - FPM風 worker poolの問題は、長命接続をどこで抱えるかという 実行モデルの問題 - Queued での問題は、接続後にどう送るかという送信設計の問題 つまり、PHPでリアルタイム通信をやるなら、 - FPM的な request/response モデルから外す - 常駐サーバー内で receiver ごとの queue / backpressure を設計する という2段階の設計が必要になる ここから言えること
34. - PHPでのリアルタイム通信は不可能ではない - 単一の常駐プロセスとしては、普通に動く - ただし、PHP-FPMのようなWeb実行モデルは、長命接続を大量に抱える 設計になっていない - FPMから外しても、 queue, backpressure の設計は必要 - PHPでリアルタイム通信をやるには、常駐サーバと送信制御を明示的に設計 する必要がある 結論
35. 伝えたいこと PHPは、リアルタイム通信ができないわけではない
36. PHP Manual: FastCGI Process Manager (FPM) https://www.php.net/manual/en/install.fpm.php PHP Manual: FPM Configuration https://www.php.net/manual/en/install.fpm.configuratio n.php 参考
37. https://github.com/supurazako/php-realtime
38. UDP版も作ってみましたが、 - protocolの違いは本質ではなかった - 送られる映像がガビガビ & 遅延が酷すぎる - 上記の問題を解決するための実装はあまりにも重すぎる ↑の理由から説明しませんでした おまけ: UDP版も作ってみたが...