問題タブ [throughput]

現在、オートベンチを使用して個人用 Web サーバーをテストしています。3 つの主要なステップでシナリオを定義したいと考えています。

ステップ 1: 増加するリクエスト負荷を生成します。たとえば、low_rate=10 から high_rate=100 まで、rate=10 ==> ここではすべて OK です。

ステップ 2: CPU 負荷を「修正」できるようにしたい。たとえば、ステップ 1 の最後に CPU 負荷が約 50 の場合、サーバーを約 3 分の間負荷を 50 に維持してから減少させたい ==> 自動ベンチでそれを行うことは可能ですか? はいの場合、どうすればできますか？そうでなければ、このステップをアクティブにするための便利なツールを提案できますか? ステップ3：できるようになりたい

ステップ 3: 現在の CPU 負荷から 0 までの負荷を生成できるようにしたい。たとえば、autobench を次のように構成します。自動ベンチでそれを行うことは可能ですか？はいの場合、どのように？そうでなければ、あなたは私の経験を実行するためのアドバイスをくれますか? 私の英語でごめんなさい！

HornetQ ストア アンド フォワード メカニズムを使用しようとしていますが、コア ブリッジを使用して 1 つのスタンドアロン HornetQ インスタンスから別のインスタンスにメッセージを転送するのは非常に遅くなります。1 秒あたり 200 メッセージを超えるスループット レートを上げることはできませんでした。

驚くべきことに、同じクライアント (メッセージを転送する HornetQ インスタンスにパブリッシュしていたクライアント) を宛先 HornetQ インスタンスで直接指定すると、1 秒あたり 1000 メッセージを超えるスループット レートが観測され始めます (このクライアントは JMS ベースです)。これは基本的に、Forwarding HornetQ インスタンスと宛先 HornetQ インスタンスの間に設定されたコア ブリッジに問題があることを意味します。

以下は、Forwarding HornetQ でコアブリッジを設定するための関連セクションです。

以下は、宛先 HornetQ でコアブリッジを設定するための関連セクションです。

すべてのシステム変数 (CPU/メモリ/ディスク IO/ネットワークなど) は十分に活用されておらず、ログにエラーはありません。

注: NIO とレガシー/古い IO の両方を試しました。これは、HornetQ-2.2.5-Final と HornetQ-2.2.8-GA の両方で試行されました (2.2.8-GA はソースからビルドされました)。

この問題の原因と解決策について何か考えはありますか?

その他の観察事項: コア ブリッジを介して送信されているメッセージはトランザクションに対応しているように見えます...したがって、これらのトランザクションをバッチ処理して、2 つの HornetQ インスタンス間の通信を非同期に行うことは可能ですか?

15 スレッドのスレッド グループがあり、それぞれが 32 KB のイメージ (HTTP POST) を送信します。概要レポートでは、スループットは 550/秒、平均応答時間は 25 ミリ秒で、KB/秒は 148KB/秒と表示されています。これらの数値を関連付けるのは難しいと思います。550 リクエスト/秒を管理でき、各リクエストが 32KB の場合、KB/秒は 550 * 32 KB/秒ではないでしょうか?

編集: リクエストを 1 つだけ送信した場合でも、KB/Sec の下の数値は意味がありません。他のすべての数値を関連付けることができます。1 つのリクエストの概要レポート:

上記の結果から、平均時間とスループットを相関させることは非常に簡単です。私が送信している画像のサイズは 32281 バイトです (Linux OS で報告されています)。コメントでarothが指摘したように、これが圧縮と関係があるかどうかは疑問です。1MB の画像を送信してみましたが、報告された KB/秒は 12.3 でした。

ビジュアル プロファイラー (cuda ツールキット 4.1) の [詳細] タブには、スループットと呼ばれるメトリックがあります。これは、memcpy HtoD DtoH などに対してのみ値を持ちます。それが何であるかを正確に知っている人はいますか? ヘルプ検索では、さまざまなスループット (たとえば、グローバル メモリ スループットなど) が得られますが、このメトリックがどこを指しているのかわかりません。

私は最近、100 ～ 1000 のパケット サイズと 6Mbps ～ 54Mbps の範囲の帯域幅を使用して、802.11g ネットワーク全体の UDP スループットに関する実験を行いました。

より高い帯域幅が期待どおりに機能していないことに気付きました。これは、使用したパケット サイズが原因である可能性があると感じています。より大きなパケット サイズを選択した場合、より高い帯域幅のネットワークでのスループットは高くなりますか? もしそうなら、なぜですか？

レシーバーウィンドウが高遅延接続のスループットにどのように影響するかを理解しようとしています。

私は2台のマシン上に、250ミリ秒の遅延RTTの2つの間の接続を備えた、単純なクライアントサーバーペアのアプリを持っています。このテストをWindows（XP、7）とLinux（Ubuntu 10.x）の両方で実行したところ、同じ結果が得られたので、簡単にするために、次の場合を想定します。クライアントがデータを受信する：WinXP Proサーバーがデータを送信する：Win7 Pro遅延は250mSecRTTです。

クライアントのレシーバーバッファサイズ（デフォルトは8Kb）を変更せずにTCPテストを実行すると、（Wiresharkを使用して）ネットワーク上で確認できます。

• クライアントはACKSをサーバーに送信し、TCPパケットにはRWIN=65kが含まれます
• サーバーはデータを送信し、RWIN=65kを報告します

トレースを見ると、3〜4パケットのバースト（ペイロードは1460バイト）があり、その直後にクライアントマシンからサーバーにACKが送信され、その後約250ミリ秒の間何も送信されず、サーバーからのパケットの新しいバーストが表示されます。クライアントに。

したがって、結論として、サーバーは受信者のウィンドウがいっぱいになる前でも新しいデータを送信しないようです。

さらにテストを行うために、今回も同じテストを実行して、クライアントマシンでレシーバーのバッファーサイズを変更しました（Windowsでは、レシーバーのバッファーサイズを変更すると、マシンによってアドバタイズされるRWINに影響します）。ACKをブロックする前に、パケットの大きなバーストが発生することを期待しています...そして少なくともより高いスループット。

この場合、recvバッファサイズを100,000,000に設定しました。クライアントからサーバーへのパケットのRWIN=99,999,744（これは素晴らしい）ですが、残念ながら、サーバーからクライアントに送信されるデータのパターンは同じです。短いバーストとそれに続く長い待機です。私がネットワーク上で見ているものも確認するために、サーバーからクライアントにデータのチャンクを送信する時間も測定します。大きなRWINを使用したり、デフォルトを使用したりしても、何の変化も見られません。

RWINを変更してもスループットに実際に影響しない理由を誰かが理解するのを手伝ってもらえますか？

いくつかの注意事項：-サーバーは8Kbのチャンクのwrite（）を使用して可能な限り高速にデータを送信します-前に述べたように、Linuxを使用しても同様の効果が見られます。レシーバーのバッファーサイズを変更すると、ノードが使用するRWINに影響しますが、スループットは同じままです。-TCPスロースタートメカニズムに十分な時間を与えてCWINサイズを拡大するために、数百パケット後のトレースを分析します。

提案されているように、ここにワイヤートレースの小さなスナップショットを追加しています

ご覧のとおり、サーバーはパケット＃33でデータの送信を停止します。

クライアントは古いパケットのパケット＃34でACKを送信します（seq = 19305、パケット＃20で送信、ここには示されていません）。RWINが100Mbの場合、サーバーがしばらくブロックしないことを期待します。

20〜30パケット後、サーバー側の輻輳ウィンドウは、私が見ているよりも多くのパケットを送信するのに十分な大きさになるはずです...輻輳ウィンドウは最終的にRWINまで大きくなると思います...パケットのパターンは同じです。データデータは250mSecの間ブロックされます。

TCP および UDP フィルタリングでの iptables のパフォーマンスについて質問するために書いています。多数の iptables ルールでテストしていました。FORWARD チェーンに 10,000 の混合 TCP ルールと UDP ルールがある場合、TCP スループットは 35.5 メガビット/秒、UDP スループットは 25.2 メガビット/秒になります。

TCP スループットが UDP よりも大きいのはなぜですか? ACK パケットのせいで TCP が遅くなると思っていました。私はすでに cisco ACL でテストしましたが、UDP の方が高速です。

PC ---- FW ----- PC トポロジー

簡単なテストを作成しました（flickrやgoogleなどの有名なサイトからファイルをダウンロードするだけです）。テストをローカルで実行します（jmeterから直接実行するか、ローカルで実行されているjmeter-serverと通信します）。平均時間は250ミリ秒で、スループットは250ミリ秒です。 29.4/秒。次に、このテストをホスト（インターネット接続がはるかに優れている）でリモートスタートします。結果として得られる平均時間は225ミリ秒ですが、スループットは非常に低く、2/sまたは1/s未満ですらあります。平均時間数は妥当に見えます。スループットの数値はまったく役に立ちません。jmeterは、すべてのjmeterサーバーで発生するスループットを平均するだけでなく、ローカルのjmeterドライバーとjmeterサーバーの間の時間を何らかの形でカウントしているようです。リモート/分散テストで適切なスループット数を取得するにはどうすればよいですか？

WCF 4.0 + REST を使用して高スループットの Web サービスを作成しています。Web サービスは XML 応答を返します。私の操作メソッドの戻り値の型は XDocument で、WCF が XML を返すように処理します。ただし、XML 応答をメモリ内に作成して呼び出し元に返すのは、あまり効率的ではありません。

XmlDocument/XDocument から XmlWriter に移行しようとしています。コンソール アプリでは、ファイルへの応答を簡単にストリーミングできますが、WCF はどうでしょうか。ストリームを返す WebOperationContext、HttpContext を使用して応答をストリーミングできますか?

助けてくれてありがとう！

ネットワークに関する質問の答えがよくわかりません。助けが必要です。

計算は関係ありません。スループットと転送時間を計算するときに、どのリンクまたは複数のリンクを一緒に検討するかについて考えたいだけです。

大きなファイルは、500 Kbps、2Mbps、および 1Mbps の 3 つのリンクを介して A ホストから B ホストに送信されます。

a) システムに 1 人のユーザーしかいないと仮定した場合、エンドツーエンドのスループットは? b) ファイルが 4GB の場合、転送にかかる時間は? c) 2Mbps リンクの代わりに 100Kbps リンクがあると考えて、a と b のオプションにもう一度答えてください。