Iベンチマークスプレーとakka-httpは、可能なスループットを意識しています。テストされたアプリケーションは簡単です。静的な出力を静的なGETパスに返します。しかし、両方のフレームワークの場合、静的レスポンスの長さが7文字から2040文字に増加すると、スループットは〜64000から〜22000 rpsに減少します。応答長の変更でスプレーとakka-httpスループットが大幅に低下しました。
誰もこのような行動を経験しましたか?どのように状況を改善できますか?
テストされたコードは、ここで見つけることができます:gist
は、それはthis questionに記載された試験に触発されています。
使用したバージョン:2.3.6アッカ
と1.3.1:のUbuntu 14.04、スカラ座2.11.8、OracleのJDK 1.8
アッカ-のhttp:2.4.11
スプレー
あなたは300倍のデータを返していますが、第3因子は減速しています。それでもいいですね。だから、あなたは7 * 64000 = 448000 B/sから2040 * 22000 = 44880000 B/sに押し上げましたが、まだ全体的にはかなり増加しています。 – jrudolph
さて、wrkは〜9MB/sから〜11MB/sに増加しています。しかし、私はAWS CloudWatchからネットワークの飽和に似た何かを見ていません。私はネットワークが私のボトルネックだとは思わない。私はまた、CPUまたはメモリの飽和が見られない:CPU使用率が80%から60%に減少した。メモリは0.5GBから1.5GBに増えます(システムでは14GBの空き容量があります)。 CPU割り込みは大幅に増加しません。だから、なぜスプレー/ akka-httpが大幅に少ないリクエストを処理できるのでしょうか? –
@jrudolph、申し訳ありません。私はテストを繰り返し、間違いを見た。スループットはMB/s単位で〜9MB/sから〜70MB/sに増加しました。私はベンチマークセット(同じ要点にコードが追加されています)にスカラのバリアントを追加し、長い出力で同様のスループットを見ました。ネットワーク帯域幅の制限のように見えます。一方、デフォルトのパラメータを持つクライアントからサーバーまでのiperfは〜88MB/sを与えます。この仮説をよりよく確認するにはどうすればよいですか?テスト結果が見つかりました[こちら](https://docs.google.com/spreadsheets/d/1yuFD7WDOzhWB5_Ob7XgAfFAdWt48SrthbvZSZ45GE-k/edit?usp=sharing) –