diameter Queue
diameterプロトコルはtcp であり、ネットワークリソースの接続、切断、タイムアウトに係るステートマシンをtcpレイヤに任せることができ、ビッグパケットにも対応することができる。
diameterプトロコル設計単体で考えた場合、シンプルに実装設計することが可能である。しかし、シンプルになることによるデメリットもある、永続tcpなので、例えばudpサーバのようにRSSパケット受信＋CPUコア占有処理のように、並列スケールアップさせる実装設計はdiameterプロトコルでは難しい
motivation
先に述べた通りプロトコルがシンプルであるがために「diameter over tcp」はスケールアウト、スケールアップに弱い。アプライアンスメーカーの意図するように、ユーザ増加に伴ってそのライセンスを追加購入・配置するのは芳しくない。そこで「優先度付 分散キュー」と、「mysql-bin-log」を採用することによって1筐体（40 core割当）で、2Mtps(１グループパフォーマンス：500Ktps x 4グループ）：１秒間に200万リクエストに応答できる diameterサーバを設計・実装した
モジュール配置図
※実装評価では、10core:1グループ、500K tps（１秒間に50万リクエスト）までを確認
※4グループへのスケールアウトは、設計・論理上可能
優先度付 分散キュー
seagull@diameter との接続評価
seagull@diameter は、１コア（シングルスレッド）で動作するdiameterクライアントシミュレータである、今回評価では以下のようにネットワーク接続設定した
seagull@diameter クライアントと、xdiameterを接続し以下について評価した
- キューイング処理で並列度が上がるか？
- 1プロセス・500Kpps程度のスループット
- キュー目詰まりとスレッド（CPU）間コンテキストスウィッチ増加の副作用は？
- tcpリソースが充分か？
結果
- seagullクライアントツールの送信・受信限界が想定よりもだいぶ低く、1プロセスあたり、20Kpps 程度が限界であったが、このクライアントを４並列（別プロセス）させて80Kppsまでスケールアウトできることを確認
- この時、サーバ側負荷は非常に低く想定では、tcpサーバ：単体負荷評価時の500Kpps近いスループットを実現できると考えられる
- 80Kpps x 平均322 Byte(CCR:466, CCA:178) = 200Mbps までは実測確認
左側：グリーン端末でseagullシミュレータをオペレートし、右側：ブルー端末はXdiameter サーバの起動・ログ表示・パケット確認に使用した
本パフォーマンス・スケール実動作の通りクライアント側はそれぞれのモジュールが理想的に分散スケールアウトできている。また、サーバ側はクライアント４CPUが100%CPUビジー状況時にも十二分な余裕を持っていることがわかる
パケットキャプチャイメージを以下に示す。
このパケット送受信シーケンスが示す通り、readとsend は必ずしも交互に処理されていない、xdiameterのパケット受信 -> キューイング処理をバッチ処理としており、最大一度のバッチで16パケットまで連続処理している