RPSの観点から見るGoとPHPのリクエスト処理の違い

CA.go#16 LT大会で使用したスライドです。

Transcript

1. RPSの観点から見る GoとPHPのリクエスト処理の違い 株式会社サムザップ　SRE 友利 拓誠
2. 友利 拓誠（ともり たくま） 所属：株式会社サムザップ 職種：SRE 入社：2023年新卒 Go歴：2年 + 約1年ほどのブランク @tksx1227 @tksx1227
3. 言語によって如実に差が出るRPS性能 １
4. 言語によって如実に差が出るRPS性能 とある日の同期との会話中、自分が担当しているプロダクトでは ECSタスク１台あたり同時に捌けるリクエスト数がかなり少ないということを知る → CPUとメモリは結構なスペック積んでるはずなのになぜ！ → ゲームという特性上、単純に処理が重い？ → 同じくゲームという特性上、データ量が膨大だから？ → GoではなくPHPだから？ → 前任者の方は「Goだったら多分５倍くらいリクエスト捌けるんじゃないかなぁ」と話していた
5. 言語によって如実に差が出るRPS性能 しばらくして左のツイートが流れてくる １０倍差！？ ほんとにこんな差出るのか？？ → そうだこれを機に検証してみよう！ https://x.com/naoya_ito/status/1902215593048367280
6. 検証内容 ２
7. 検証内容　概要 • GoとPHPで処理内容を統一したAPIサーバーをそれぞれ実装する • 各APIサーバーに負荷をかける • RPSとサーバーのパフォーマンスの変化を比較し、それぞれの特性を確認する ※簡易的に実施するために、環境はローカルで Docker Compose を使って用意する
8. 検証内容　サーバー構成 【PHP】 • 構成：Nginx + php-fpm • フレームワーク：Laravel 12 【Go】 • 構成：Go APIサーバー • フレームワーク：chi Container vCPU Memory [GB] Nginx 0.5 0.5 php-fpm 1 2 MySQL 6 4 Container vCPU Memory [GB] Go 1 2 MySQL 6 4
9. 検証内容　実装エンドポイント 1. CPUバウンドな処理を行うエンドポイント（POST: /api/battle/resolve） • バトル演算を想定したエンドポイント • 内部で重ためな計算処理を実行する • DB通信などのIO処理は含まない 2. IOバウンドな処理を行うエンドポイント（POST: /api/gacha/draw10） • ガチャを想定したエンドポイント • 複数回のDB通信を中心とした処理を行う • その他の演算処理は最小限に抑えている
10. 検証内容　負荷シナリオ 1. CPUバウンド処理のエンドポイントに継続的にリクエストを送信 • １RPSから始めて徐々に値を大きくしていく • 次のスライドにある性能限界の条件を満たした時点でシナリオを停止する 2. IOバウンド処理のエンドポイントに継続的にリクエストを送信 • １と同様の方法で負荷をかける
11. 検証内容　性能限界の定義 今回の検証では下記２点のいずれかを満たした時点でのRPS値を ユーザーが性能劣化を体感し始める ”コンテナの性能限界” として定義する • 一定時間中にレイテンシの p95 の値が 200ms を超え続けた場合 • レスポンスのエラー割合が 0.1% を超えた場合
12. 検証結果 ３
13. 検証結果　CPUバウンド処理 PHP Go
14. 検証結果　CPUバウンド処理 PHP Go 50 RPS ほどで性能劣化 500 RPS ほどで性能劣化
15. 検証結果　CPUバウンド処理 PHP Go 50 RPS ほどで性能劣化 500 RPS ほどで性能劣化 10倍差
16. 検証結果　IOバウンド処理 PHP Go
17. 検証結果　IOバウンド処理 PHP Go 130 RPS ほどで性能劣化 2,100 RPS ほどで性能劣化
18. 検証結果　IOバウンド処理 PHP Go 130 RPS ほどで性能劣化 2,100 RPS ほどで性能劣化 16倍差
19. 検証結果 性能比較結果 (1vCPU環境) 　処理タイプ 　PHP (RPS) 　Go (RPS) 　性能差 　CPUバウンド処理 　50 　500 　約10倍 　IOバウンド処理 　130 　2,100 　約16倍
20. 検証結果から見えてくること ４
21. 検証結果から見えてくること 今回の検証で確認できた2つの性能差 1. PHPとGoでRPS性能に10倍以上の差が生じる • CPUバウンド：10倍差 • IOバウンド：16倍差 2. 処理タイプによってさらに性能差が拡大する • CPUバウンド（10倍）< IOバウンド（16倍）
22. 検証結果から見えてくること 今回の検証で確認できた2つの性能差 1. PHPとGoでRPS性能に10倍以上の差が生じる → ランタイムの差によるもの 2. 処理タイプによってさらに性能差が拡大する → 同時実行モデルの差によるもの
23. 検証結果から見えてくること 1. PHPとGoでRPS性能に10倍以上の差が生じる → ランタイムの差によるもの Go（コンパイル言語） • 事前にマシンコードに変換済み • 複雑なアーキテクチャもコンパイル時に最 適化され実行時は高速 PHP（インタープリター） • リクエストのたびにスクリプトを 読み込み・解析・実行 • DDD/クリーンアーキテクチャなど複雑 な構造ほど解析コストが増大 リクエスト処理に関するオーバーヘッドが削減されるため 効率よくリクエストを処理できる
24. 検証結果から見えてくること 2. 処理タイプによってさらに性能差が拡大する → 同時実行モデルの差によるもの Go • 1リクエスト = 1goroutine（軽い） • DB待機中は他の処理に CPU を譲る PHP • 1リクエスト = 1プロセス（重い） • DB待機中もプロセスを占有し続ける IOの待機時間でもリソースを効率よく活用できるため より多くのリクエストを同時に処理できる
25. まとめ ５
26. まとめ • CPUバウンド処理において、GoはPHPの約10倍のRPSを達成 • IOバウンド処理において、GoはPHPの約16倍のRPSを達成 • ランタイムの差や同時実行モデルの違いが掛け合わさり、十数倍の差が発生 • IO処理が多いシステムではよりGoの強みが活きる • インフラリソースの観点から、高負荷APIではGoが圧倒的に有利 • 開発速度・人材確保の観点ではPHPも有効な選択肢 • システムの特性と要件に応じた言語選択が重要 （本当はプロファイラとかいれてもう少し詳細まで追いたかったけど力及ばず間に合いませんでした😣）
27. ありがとうございました
28. 補足 反応をみての補足です • 検証結果のグラフが線形ではなく段差のある形状になっているのはなぜか ➔ RPSを手動で段階的に上げたため、このような段差のある形になりました ➔ 10→11→12 ではなく、10→20→30 のように変更して確認 • PHPのチューニング次第ではここまでの差は生じないのではないか ➔ 今回は簡易的な設定のみで検証したためその可能性は大いにあると思っています ➔ GitHubにソースを上げているので興味のある方は覗いてみてください 建設的なフィードバック・議論は大歓迎です https://github.com/tksx1227/php-golang-rps/tree/2025-07-01