実際に測定してみた。
動機
そこそこリアルタイム性が求められるWebアプリにおいて、できればFirebaseを使いたいが、パフォーマンスが悪くなるならあきらめてWebSocketを直接つなごうと思った。
例えばシムシティのような協力プレイゲームを作っているとして、
- 自分の操作を他の人に反映させたい
- お金が足りているかバリデーションをサーバーサイドでやりたい
という場合のことを考えた。
Firebaseを使えたら認証やその他諸々をFirebaseだけで完結させることができる。
しかし、パフォーマンス上成り立たないなら、あきらめてWebSocketを別につなぐことになる。
そこで、実際にどの程度差がつくのか調査してみた。
方法
WebSocket
Dartで下記処理をするサーバーを書く
- WebSocketを待ち受ける
- WebSocketから文字が来たら同じ文字を送り返す
Dartで下記処理をするクライアントを書く
- ブラウザ立ち上げ直後は遅そうなので取り合えず10秒まつ
- サーバーにWebSocketをつなぐ
- 100msごとにWebSocketに現在時刻を書き込む
- WebSocketからさっき書き込んだ時刻が返ってくるので現在時刻から引き算しレスポンスタイムを調べる
- 以上を100回繰り返し平均を出す
サーバーは
- GCP asia-northeast1-c
- 1vCPU
- 3.75メモリ
僕が日本に住んでるので日本に建てた。
ただし名古屋市民のため、都民だともうちょっと速いかも。
Firebase
Dartで下記処理をするサーバーを書く
- Firebaseの/requestをListenする
- /requestに書き込みがあったら同じ内容を/responseにpushする
Dartで下記処理をするクライアントを書く
- ブラウザ立ち上げ直後は遅そうなので取り合えず10秒まつ
- Firebaseの/responseをListenする
- 2s（※）ごとに/requestに現在時刻を書き込む
- /responseにさっき書き込んだ時刻が書き込まれるので、現在時刻から引き算しレスポンスタイムを調べる
- 以上を100回繰り返す
（※ 一回100msごとに書き込んで試してみたのだが、イベントが詰まるようで明らかにパフォーマンスが劣化するので間隔を広げた。この点は厳密な比較になっていないので注意）
サーバーは
- GCP us-central1-c
- 1vCPU
- 3.75メモリ
Firebaseがアメリカにあるらしいのでアメリカに建てた。
アメリカのどこにあるのかわからないので、探せばもっと速い場所が見つかるかも。
結果
| 調査の種類 | 平均レスポンスタイム | （参考）自宅PCにサーバーを立てた場合 |
|---|---|---|
| WebSocket | 123.66ms | 0.93ms |
| Firebase | 254.74ms | 440.34ms |
感想
意外とWebSocket自体が遅かった。さくらのVPSを使ってた頃は20ms切ってた覚えがある。
ものすごくはっきりした差が出たわけではないので使い方によると思う。
参考情報
簡単にもっとCPUとメモリの多いサーバーで試してみたが、大して変わらなかった。同時接続数がとても低いのであまり関係ないようだ。