リアルタイムゲームサーバーの ベンチマークをとる方法
•
5 likes•9,427 views
『リアルタイムゲームサーバーの ベンチマークをとる方法』をスライド化致しました。 ネットワークゲームを製作する際にご参考頂けますと幸いです。
Recommended
More Related Content
What's hot
What's hot (20)
Similar to リアルタイムゲームサーバーの ベンチマークをとる方法
Similar to リアルタイムゲームサーバーの ベンチマークをとる方法 (20)
More from モノビット エンジン
More from モノビット エンジン (20)
Recently uploaded
Recently uploaded (15)
リアルタイムゲームサーバーの ベンチマークをとる方法
- 4. 性能の指標 • スループット速度 : ビット/秒 または メッセージ/秒 • 応答速度 : 秒 • 同時接続数 : 本
- 5. 用意するマシンのタイプ • 2または4コア、4または8GBRAMの汎用マシンがMRSに最適 • AWS • 日本ではm4/c4.largeまたはxlarge • 日本以外ではm5/c5 のlargeまたはxlarge • IDCFクラウド • M4,M8,L8など • GCE • n1-standard-2または standard-4など
- 7. AWSにおける通信帯域制限(実測) • 各インスタンスにおいて • m4,c4シリーズ(xlarge) : 1.2Gbps • m5,c5シリーズ(xlarge) : 8Gbps iperf3などの標準ツールおよび 独自開発した libuv_bench, mrs_room_bench等のプログラムを使用。 m5,c5シリーズは東京ではまだ使用不可(2017)
- 8. AWSにおけるパケット数制限(実測) • 各インスタンスにおいて • m4,c4シリーズ(xlarge) • 送受信合計15万 packets/sec • m5,c5シリーズ(xlarge) • 送受信合計92万、片道55万 packets/sec iperf3などの標準ツールおよび 独自開発した libuv_bench, mrs_room_bench等のプログラムを使用 m5,c5シリーズは東京ではまだ使用不可(2017)
- 9. AWS以外における制限 • Google Compute • 7~8Gbpsらしい • IDCFクラウド • 1.9Gbps (実測), 40万パケット/sec • 他 • 環境や条件によりさまざま 多くのクラウドでは物理的に10Gbps Ethernetが使われているが、 そのワイヤスピードよりも低い制限がかかっている。
- 10. ハードウェアの性能を測定(iperf3) サーバー用 インスタンス m4.xlarge 10.6.0.199 クライアント用 インスタンス1 m4.xlarge 10.6.0.135 sudo yum install iperf3 インストール サーバーを起動 iperf3 -s クライアントを起動 iperf3 -c 10.6.0.199 NICが複数ある場合は、LAN通信用のIPアドレスを指定する必要がある。 172. や10. ではじまるアドレスはだいたいLAN用 クライアントから サーバに負荷をかける
- 11. iperf3の結果 (TCP) @IDCFクラウド IDCFクラウド L8での測定結果 (以下同様) サーバー。だいたい2Gbps受信 クライアント だいたい2Gbps送信 TCPはLinuxの輻輳制御アルゴリズムが使われるので、 特にオプションを設定しなくても自動的に可能な最高速度で送信される
- 12. iperf3の結果 (UDP、安定) iperf3 -s 2>&1 | grep -v ORDER -u -b 2000M 受信側(サーバー)でUDPのOUT OF ORDERログメッセージが 大量に出力されるため、それ以外だけを表示。 OUT OF ORDERが全く出ないならそれがのぞましい。 AWSなら少ない。時間帯によっても異なる サーバー。だいたい2Gbps受信 クライアント だいたい2Gbps送信 -uでUDPを選択。 UDPは輻輳制御が働かないので、 どれだけの量を送信するかオプションで設定する。 上図では 2000Mbps ※IDCFクラウド L8での測定結果
- 13. iperf3の結果 (UDP、不安定) サーバー。受信量が4000Mbps(4Gbps)より小さいうえ、 一定していない。 Lostパケットも数千個づつ発生 クライアント -b 4000Mで 4Gbps送信するよう設定したが、 実際送信できた量はそれよりだいぶん小さい ※IDCFクラウド L8での測定結果
- 14. iperf3の結果 (TCP、小パケット) TCPで1バイトづつ書き込み (-l 1オプション)した場合、 7Mbpsしか出ていないが これで正常(良好)な結果だと言える。 TCPで32バイトづつ書き込み。200Mbps程度に向上 ※IDCFクラウド L8での測定結果
- 15. TCPパケットのサイズを確認する ※IDCFクラウド L8での測定結果 tcpdump -i ens160 tcp port 5201 -c 100 • サーバ側においてtcpdumpコマンドを使い、iperf3が 使うTCP5201番のポートについて、100パケット分の 記録を取る。
- 16. TCPパケットのサイズ ※IDCFクラウド L8での測定結果 iperf3は、writeシステムコールでTCPソケットに1バイトづつ書き込む。 Linux OSは、1バイトづつ書き込まれても、 一定時間以内の書き込みについては1つのパケットにまとめてしまう。 iperf3 -c 10.6.0.199 -l 1 iperf3 -c 10.6.0.199 -l 1 —no-delay —no-delayオプションを付けると、パケットサイズがかなり小さくなっているのがわかる
- 17. iperf3の結果 (UDP、小パケット) -l 1で1バイトづつ送信。 UDPのサーバ側の出力。 1バイトづつの送信では、 2Mbps程度しか出ない ※IDCFクラウド L8での測定結果 -l 32 -b 100M で32バイトづつ送信。 100Mbps近いが、 ロス率が10%越えて不安定になっている。 これ以上速くは送れない
- 18. UDPパケットのサイズ ※IDCFクラウド L8での測定結果 UDPでは、1バイトのペイロードをもつUDPデータグラムだけが送られている iperf3 -c 10.6.0.199 -u -l 1
- 19. パケットサイズとスループットの関係 • アプリケーションデータの前後にヘッダなどが大量に付いているため、Ethernetおよ びIPネットワークでは、パケットサイズが小さいとスループットは大幅に落ちる • 参考: • http://blogs.itmedia.co.jp/komata/2011/04/udp-8fa9.html • IPv4における最大パケットサイズ(MTU)は1500バイトのことが多い • OSの設定による
- 20. ジャンボフレーム • 1500より大きいMTU設定をジャンボフレームと呼ぶ • 典型的には9000または9001バイト • AWS • Amazon Linux : デフォルトでJumboフレーム有効(9001) • CentOS 7: t2シリーズでは自動的に9001になる • IDCFクラウド • CentOS 7 • デフォルトでJumboフレーム無効 (1500) • 上記以外 • 未調査
- 21. MTUをifconfigで確認 Linode CentOS 7.3 デフォルトインストール AWS CentOS 7.4 または AmazonLinux 2017.9 デフォルトインストール
- 22. ゲームサーバーではジャンボフレームは不要 • ほとんどのパケットは、20バイト〜300バイト程度のちいさなパケット • ただし、たまにキャラのJSONデータが50KBとかまとめて送ることはある • 通信相手は、インターネットに散らばる何千という異なるホスト • 上記のような用途ではジャンボフレームは必要ない
- 23. パケットが小さいとCPU消費が大幅に大きい iperf3 -c 10.6.0.199 TCPで、2Gbps送信中(MTU=1500)。 CPU消費は全部で0.3%と非常に小さい iperf3 -c 10.6.0.199 -l 1 —no-delay TCPで、1バイトづつ、 10Mbps程度を送信中。 CPU消費は全部で25%を越えている。 パケット数が多いと、 80倍以上負荷がかかっている。 原因はパケットの数が多いため 大パケットの場合 小パケットの場合 ※IDCFクラウド L8での測定結果
- 24. 毎秒のパケット数を調査する • pktcnt.rb という簡単なスクリプトを使う • https://gist.github.com/kengonakajima/5a898c926ea5d6fd12428800f4718a1a 送信パケット数 受信パケット数 合計パケット数 送信バイト数 受信バイト数 合計バイト数 現在時刻 unixtime 平均パケット サイズ UDPで200バイトのデータで負荷をかけてみた場合。 ヘッダの分少し大きくなっている nethogsやdstatなどを併用してもOK
- 26. MRSの性能を測定する2つのツール • mrs_bench : MRSのエコー性能を測定 • mrs_room_bench : ルームサーバー性能を測定
- 27. mrs_bench サーバー用 インスタンス m4.xlarge 10.6.0.199 クライアント用 インスタンス1 m4.xlarge 10.6.0.135 サーバーを起動 ./sv クライアントを起動 ./cl 10.6.0.199 5 10 NICが複数ある場合は、LAN通信用のIPアドレスを指定する必要がある。 172. や10. ではじまるアドレスはだいたいLAN用 クライアントから 送ったデータが おうむ返し(ECHO)される
- 28. mrs_bench の使い方 • 配布物はサーバとクライアントの両方を含む • ビルド方法と起動方法 • 詳細は mrs_bench/README.md を参照 • 重要なクライアント起動時引数 • ./cl 10.6.0.199 10 1000 —size=40 —udp 10.6.0.199のサーバに対して同時10接続、1000ミリ秒に1回40バイトをUDPで送 信。 • サーバは引数なしで起動 (iperf3と同様) • 評価版の注意点 • 最大接続数が100に制限されている
- 29. mrs_bench の出力凡例 • ログに小文字の”c”が連続するのは、接続に成功したしるし dは切断 eはエラー • 性能評価 • 受信バイト数 : recvBのカッコ内、例の(0.3)が通信スループット Mbytes/secを示す。 Mbit/sは単純にこの値の8倍 • 受信メッセージ数: recvNの (9532)などが1秒間のメッセージ数を示す • RTTが通信遅延を示す 現在時刻 unixtime ループ回数 送信回数 受信回数(過去1秒) 同時接続数 切断数 エラー数 受信Miバイト数 (過去1秒) 往復時間 平均ms 最大ms 最小ms 最新ms
- 30. mrs_benchのスループット(TCP) コマンドライン recvN recvB (MiB) スループット Mbit/sec ipv4 pkts/sec send+recv ./cl 10.6.0.199 10 1 約9500 0.3 2.4Mbps 19100 ./cl 10.6.0.199 100 1 約95000 2.9 19.2Mbps 190000 ./cl 10.6.0.199 100 1 —size=100 約94000 10.1 80.8Mbps 190000 ./cl 10.6.0.199 100 1 —size=500 約94000 45 360Mbps 190000 ./cl 10.6.0.199 100 1 —size=1000 約93000 90 720Mbps 190000 ./cl 10.6.0.199 100 1 —size=2000 約89000 177 1.4Gbps 375000 ./cl 10.6.0.199 100 1 —size=3000 約89000 247 1.97Gbps 400000 ./cl 10.6.0.199 100 1 —size=4000 不定 不定 不定 400000 ※IDCFクラウド L8での測定結果 size=3000より大きくするとエラーが増えて、結果が不安定になる。 1.97Gbpsで、かつ40万パケット/秒 という出力は iperf3で測定したハードウェア限界に一致。 MRSがこのマシン環境での制限速度いっぱいまで使い切った
- 31. mrs_benchのスループット(UDP) コマンドライン recvN recvB (MiB) スループット Mbit/sec ipv4 pkt/sec クライアント プロセス数 サーバ プロセス数 ./cl 10.6.0.199 10 1 —udp 約9400 0.3 2.4Mbps 36900 1 1 ./cl 10.6.0.199 100 1 —udp 約95000 2.9 19.2Mbps 263000 1 1 ./cl 10.6.0.199 10 1 —udp —size=1000 約9400 9.1 72.8Mbps 59000 1 1 ./cl 10.6.0.199 10 1 —udp —size=2000 約9300 18 144Mbps 96000 1 1 ./cl 10.6.0.199 10 1 —udp —size=3000 約9300 27 236Mbps 135000 1 1 ./cl 10.6.0.199 10 1 —udp —size=4000 約9300 35 280Mbps 177000 1 1 ./cl 10.6.0.199 50 1 —udp —size=100 —port=xxx 約44000 4.8x2 38.4x2 合計335000 2 2 ./cl 10.6.0.199 50 1 —udp —size=100 —port=xxx 不定 不定 不定 約380000 3 3 ※IDCFクラウド L8での測定結果 UDPはCPU消費が多いので、 --port設定を使って プロセスの数を増やして測定する。 iperf3で測定した40万パケット/secに近づくと不安定になり測定できなくなる。
- 32. パケット数とメッセージサイズ • MTU=1500で2KB送る時 (TCP) 送信側 受信側 seq=0 1500bytes seq=1 500bytes seq=0 ACK seq=1 ACK データを2個送信し、ACKを2個受信する。 合計4つのパケット処理が行われる。 送信と受信両方の合計数によって 制限されることに注意!
- 33. パケット数とメッセージサイズ • MTU=1500で2KB送る時 (TCP, piggy back) 送信側 受信側 seq=0 1500bytes seq=1 500bytes seq=1 ACK TCPには、一定時間以内のデータパケットと ACKパケットをひとつにまとめて、 全体のパケット数を減らす機能が搭載されている。 そのため、合計パケット数は、 送信したデータパケットの2倍に単純にはならない。 seq=x 1500bytes seq=0 ACK
- 34. パケット数とメッセージサイズ • RUDP で2KB送る時 MTU=576 送信側 受信側 seq=0 576bytes seq=1 576bytes MRSでは、RUDPの「パスMTUブラックホール」 を回避するためにMTUを576に固定している。 そのため、2KB送るときに合計8個のパケットが送信される。 TCPに比べてパケットの数が2倍になっている。 またRUDPにはpiggy back機能はない seq=0 ACK seq=2 576bytes seq=3 272bytes seq=1 ACK seq=2 ACK seq=3 ACK RUDPのパケット数は、 TCPのだいたい1.5倍〜2倍
- 36. mrs_benchのスループット(TCP+暗号) コマンドライン recvN recvB (MiB) スループット Mbit/sec サーバCPU 1スレッドの専有度 クライアント プロセス数 サーバ プロセス数 ./cl 10.6.0.199 10 1 —encrypt 約9400 0.3 2.4Mbps 5% 1 1 ./cl 10.6.0.199 10 1 —encrypt —size=1000 約9400 9.1 72.8Mbps 35% 1 1 ./cl 10.6.0.199 10 1 —encrypt —size=2000 約9300 18 144Mbps 68% 1 1 ./cl 10.6.0.199 10 1 —encrypt —size=3000 約9300 24 192Mbps 82% 1 1 ./cl 10.6.0.199 10 1 —encrypt —size=4000 不定 不定 不定 99% 1 1 ※IDCFクラウド L8での測定結果 IDCFのL8マシンでは、1プロセス(1スレッド)では約200Mbps (送受信の両方を暗号化しているので、2倍の400Mbps) が限界となっていることがわかる
- 37. ゲームにおける暗号通信の必要性 • 必要 (トラフィックの5%以下) • ログイン認証、ショップ、アチーブメントなど • 不必要 (トラフィックの95%以上) • MOBの座標更新、カメラ向き更新、GUIイベント送信、ボ イスチャットデータなど MRSでは、パケットごとに暗号の有効・無効を制御できるため、 通信の負荷容量設計においては暗号通信によるCPU消費増大は無視してよい。
- 38. サーバー性能の飽和状態を知る方法 • プロセスごとの飽和状態 • マシン全体の飽和状態 • どちらもtopで見る : CPU % • TCPの場合 : netstatで見る 暗号化したり、メッセージを極端に小さくしたりすると 環境による通信の速度制限に到達する前に サーバーの性能は飽和する。
- 40. topの見方 一つのsvプロセスが飽和 svプロセスの負荷が100% これはCPUコア1個(1スレッド分)を使い切っていることを示す。 これ以上このプロセスの性能は上がらない。 マシン全体の 負荷は 22.3 + 2.7 = 25%程度 このマシンは4コアなので、同様のsvをあと3個増やせば性能は4倍になる。 MRSリアルタイムサーバーの場合は、だいたい単純計算でOK
- 42. TCPはnetstatも参考にできる TCPでは、 netstat -tan | grep 33333 などとして接続の状態を監視できる。 送信バッファ量 localアドレス リモートアドレス 受信バッファ量 接続の状態 受信バッファも送信バッファも ほとんどたまっていない。 受信バッファが大量にたまっていて、 送信はたまっていない。 これはサーバー側の結果なので、 サーバーの性能が飽和しているとわかる
- 43. サーバーの性能が飽和しない時 • 接続数を増やしてもサーバーのCPU消費量が上がらなくなったら？ • だいたいの場合はクライアントの性能が飽和している。 • TCPであればnetstatのrecv-qがクライアント側で貯まる。 • UDPであればクライアントの送信エラーが表示される。 • よりコア数の多いマシンを使うか、マシンを増やして解決。
- 44. mrs_room_bench • MRSを用いて実装されたリアルタイム同期サーバー のmrs_roomをベンチマークするためのクライアン トプログラム • ベンチマーク対象となる mrs_roomのサーバープロ グラムも mrs_room_benchに含まれている(バージョ ン不一致を防ぐため)
- 45. マルチプレイゲームの全体構成 DB Web-0 Internet Web-n Room-0 Room-1 ・・・ Room-n・・・ 2.双方向リアルタイム通信ステップ1:接続先Room Webサーバー部 リアルタイムサーバー部 (mrs_room)
- 47. mrs_room における送信パターン • 標準 • broadcast : 自分も含めて全員に送る • othercast : 自分以外に送る • manycast : 指定した複数に送る • unicast : 指定した相手だけに送る • ownercast : 部屋の所有者だけに送る • 拡張する場合 • nearcast : 近くの相手だけに送る • condcast : 条件を満たす相手だけに送る • etc..
- 50. 4コアマシンの典型的な構成 サーバーマシン sv0 sv1 sv2 sv3 sv4 sv5 room0 room1 ・・・・・・・・・ room2 ・・・ roomN ・・・ roomN roomN roomN roomN ・・・・・ 1台のインスタンスに 6〜8個のサーバプロセスを置く 1個のサーバプロセスが 500〜2000の部屋をホストし、 合計で5000〜10000程度の 同時接続数に対応
- 51. インスタンスは何個必要か？ • 1台の4コアマシンに可能な入力 • 帯域幅の限界 : 1.2Gbps〜8Gbps • パケット数の限界 : 合計15万〜90万/sec • 暗号 : 送受信合計で 50Mbytes/sec • 上記の入力上限を超えるごとに1台必要 全部でどれだけの通信が必要かは、完全にゲーム内容による
- 53. 1インスタンスがホストできる同時接続数 • 適当に仮定を置く • メッセージサイズ:200バイトに固定。ちょっと長いけど。 • 暗号化通信のコストは無視でOK • 送り方は othercastに固定。だいたいのゲームはこれでOK • 通信モデルはホストーゲスト型(ホスト役以外全員がゲスト)に固定 • 部屋の参加人数によらず、ホストが1送ったらほかの全員が1受信する • マシンは AWSの m4 (15万packet/sec, 1.2Gbps)と仮定 • ACKパケットは必ず発生すると仮定
- 54. 1インスタンスがホストできる同時接続 サーバへの送信 /sec/CCU サーバからの送信 /sec/CCU サーバでの 合計パケット数 /sec/CCU ACKも含めた パケ数 バイト数 15万pkt/sec での限界 CCU 1.2Gbpsでの 限界CCU ターン制ゲーム 1msg/sec 1 1 2 4 400 37500 375000 低速少量アクション クラッシュ系、 パズルやスポーツゲームなど 5msg/sec 5 5 10 20 2k 7500 75000 高速大量アクション MOBAやRTS,物理があるFPSな ど 30msg/sec 30 30 60 120 12k 1250 12500 可能なCCUの小さい方を採用する。 ゲームではパケットが小さいので、 だいたいいつもパケット数の制限が帯域の制限よりきつい
- 55. •まとめると •ターン制ゲームは37500CCU(同時接続) •低速少量アクションは 7500 •高速大量アクションは1250 •安全係数を0.5程度掛けると •ターン制ゲームは 18750 •低速少量アクションは 3750 •高速大量アクションは625 1インスタンスがホストできる同時接続
- 56. 1024以上のCCUに対応するための設定 • TCPを使う場合は2つの制限が問題になりやすい • ユーザアカウントあたりの最大ソケット数 • ローカルポート数 • 負荷テストを行うときは、UDPのクライアント側で も上記の問題は起きる
- 57. ユーザアカウントあたりの最大ソケット数 • ulimit -a で確認 このユーザでは1024個までしかソケットを作れない。 TCPでは1CCUあたり1個のソケットが必要。 UDPでもクライアントでは1CCUあたり1個必要。 ulimit -nコマンドで設定してもハードリミット以上は無理 /etc/security/limits.conf の末尾あたりに サーバを起動するユーザーで softとhardリミットの値を書いておくだけでOK。再起動不要
- 58. ローカルポート数の枯渇 • TCPまたはUDPのソケットを作ると、localポート番号が1個割り当てられる • CentOSやAmazon Linuxの設定では、デフォルトで32768から60999までの28232個が使 われる。 • 28232個を超える数のソケットを作ることができない。 • Linuxカーネルの設定を変更することもできるが、推奨しない。 • インスタンスあたりCCUは28232よりだいぶ小さい数、 できれば10000〜15000以下で計画するのが良い。 • そのためにxlargeではなくlargeタイプを使うのも良い案となる。
- 59. 1インスタンスあたりの容量計画(最終案) サーバでの 合計パケット数 /sec/CCU ACKも含めた パケ数 15万pkt/secでの 限界CCU 安全マージン0.5 インスタンスタイプ ターン制ゲーム 1msg/sec 2 4 37500 18750 4コアマシン1台分を、 2コアマシン2台に分ける(9375CCU) 低速少量アクション クラッシュ系、 パズルやスポーツゲームなど 5msg/sec 10 20 7500 3750 4コアマシンでOK 高速大量アクション MOBAやRTS,物理があるFPSなど 30msg/sec 60 120 1250 625 4コアマシンでOK これで負荷テストで確認したいだいたいの性能の目標が得られた。 あてずっぽうの負荷テストを避けられる。
- 60. mrs_room_benchの内容 • 配布物はサーバとクライアントの両方を含む • ビルド方法と起動方法 • 詳細は mrs_room_bench/README.md を参照 • サーバーを起動するには ./sv とするだけ • クライアントを起動する方法は後述 • 評価版の注意点 • 最大接続数が100に制限されている
- 64. mrs_room_benchの起動 • レポジトリのmany.shを修正して起動する • ADDR : 接続先サーバーのIPアドレス • PROTO : 使用プロトコル。 TCP, UDP, WS, WSSのいずれか • N : 同時接続数。4の倍数がのぞましい(部屋あたり4人なので) • SIZE : メッセージサイズ。1以上64K以下、通常は32や200、大きい場合は5000〜10K以内で試す • ENC : 暗号化するかどうか。1なら有効、0なら無効 • INTERVAL : メッセージ送信間隔ミリ秒 • UNRELIABLE : UDPの場合これを1にすると信頼性なしモードで送信 • CREATEINTERVAL : ユーザーを新規作成する頻度。100ミリ秒を指定すると100ミリ秒ごとに新規接続をする
- 65. mrs_room_benchの出力凡例 ここまで、毎秒10本づつCCUを増加させている ここから、負荷が安定している 現在時刻 unixtime pid ループ回数 クライアント数 (CCU) 送信間隔 送ったバイト数 受信バイト数(MiB) • manysv.sh では複数のサーバーをポート番号を変えながら同時に起動できる。 • 他にもオプションはたくさんあるので、 mrs_room_bench/README.mdを参照して下さい。