着信バイナリデータをプロトコルバッファ形式で読み取り、応答としてバイナリメッセージを書き込む基本的なTCPサーバーを作成しました。往復時間をベンチマークしたいと思います。
iperfを試しましたが、同じ入力ファイルを複数回送信させることができませんでした。バイナリ入力ファイルを繰り返し送信できるベンチマークツールはありますか？
10494 次
5 に答える
9
LinuxまたはUNIXマシン1にアクセスできる場合は、 tcptraceを使用する必要があります。あなたがする必要があるのは、wiresharkまたはtcpdumpファイルでキャプチャしている間、バイナリトラフィックテストをループすることです。
.pcapそのファイル2を取得したら、 tcptrace -xtraffic <pcap_filename>3で分析します。これにより、2つのテキストファイルが生成され、そのpcap内のすべての接続の平均RTT統計が、と呼ばれるものの下部に表示されtraffic_stats.datます。
[mpenning@Bucksnort tcpperf]$ tcptrace -xtraffic willers.pcap
mod_traffic: characterizing traffic
1 arg remaining, starting with 'willers.pcap'
Ostermann's tcptrace -- version 6.6.1 -- Wed Nov 19, 2003
16522 packets seen, 16522 TCP packets traced
elapsed wallclock time: 0:00:00.200709, 82318 pkts/sec analyzed
trace file elapsed time: 0:03:21.754962
Dumping port statistics into file traffic_byport.dat
Dumping overall statistics into file traffic_stats.dat
Plotting performed at 15.000 second intervals
[mpenning@Bucksnort tcpperf]$
[mpenning@Bucksnort tcpperf]$ cat traffic_stats.dat
Overall Statistics over 201 seconds (0:03:21.754962):
4135308 ttl bytes sent, 20573.672 bytes/second
4135308 ttl non-rexmit bytes sent, 20573.672 bytes/second
0 ttl rexmit bytes sent, 0.000 bytes/second
16522 packets sent, 82.199 packets/second
200 connections opened, 0.995 conns/second
11 dupacks sent, 0.055 dupacks/second
0 rexmits sent, 0.000 rexmits/second
average RTT: 67.511 msecs <------------------
[mpenning@Bucksnort tcpperf]$
この例で使用されているファイルは、サーバーの1つからデータをプル.pcapするスクリプトをループしたときに生成したキャプチャです。expectこれが私がループを生成した方法です...
#!/usr/bin/python
from subprocess import Popen, PIPE
import time
for ii in xrange(0,200):
# willers.exp is an expect script
Popen(['./willers.exp'], stdin=PIPE, stdout=PIPE, stderr=PIPE)
time.sleep(1)
accept()サーバーのパフォーマンスとテストの期間に基づいて、ループ間のスリープ時間を調整できます。
エンドノート：
- KnoppixLive -CDで十分です
- テストトラフィックのみをキャプチャするようにフィルタリング
tcptrace他のオプションを使用すると、ソケットごとの統計を非常に詳細に表示できます。
================================
[mpenning @ Bucksnort tcpperf] $ tcptrace -lr willers.pcap
'willers.pcap'で始まる残りの1つの引数
Ostermannのtcptrace-バージョン6.6.1-2003年11月19日水曜日
16522パケットが表示され、16522TCPパケットがトレースされました
経過ウォールクロック時間：0：00：00.080496、205252パケット/秒分析
トレースファイルの経過時間：0：03：21.754962
TCP接続情報：
トレースされた200のTCP接続：
TCP接続1：
ホストc：myhost.local：44781
ホストd：willers.local：22
完全な接続：リセット（SYN：2）（FIN：1）
最初のパケット：2011年5月31日火曜日22：52：24.154801
最後のパケット：2011年5月31日火曜日22：52：25.668430
経過時間：0：00：01.513628
総パケット数：73
ファイル名：willers.pcap
c-> d：d-> c：
総パケット数：34総パケット数：39
送信されたリセット：4送信されたリセット：0
送信されたackpkts：29送信されたack pkts：39
送信された純粋なack：11送信された純粋なack：2
送信されたsackpkts：0送信されたsack pkts：0
送信されたdsackpkts：0送信されたdsack pkts：0
max sack blks / ack：0 max sack blks / ack：0
送信された一意のバイト数：2512送信された一意のバイト数：14336
実際のデータパケット：17実際のデータパケット：36
実際のデータバイト数：2512実際のデータバイト数：14336
rexmt data pkts：0 rexmt data pkts：0
rexmtデータバイト：0 rexmtデータバイト：0
zwndプローブパケット：0 zwndプローブパケット：0
zwndプローブバイト：0 zwndプローブバイト：0
アウトオブオーダーパケット：0アウトオブオーダーパケット：0
プッシュされたデータパケット：17プッシュされたデータパケット：33
送信されたSYN/FINパケット：1/1送信されたSYN / FINパケット：1/0
req 1323 ws / ts：Y / Y req 1323 ws / ts：Y / Y
高度な風のスケール：6高度な風のスケール：1
req sack：Y req sack：Y
送信された袋：0送信された袋：0
緊急データpkts：0 pkts緊急データpkts：0 pkts
緊急データバイト：0バイト緊急データバイト：0バイト
要求されたmss：1460バイト要求されたmss：1460バイト
最大セグメントサイズ：792バイト最大セグメントサイズ：1448バイト
最小セグメントサイズ：16バイト最小セグメントサイズ：32バイト
平均セグメントサイズ：147バイト平均セグメントサイズ：398バイト
max win adv：40832バイトmax win adv：66608バイト
min win adv：5888バイトmin win adv：66608バイト
ゼロウィンアドバンテージ：0倍ゼロウィンアドバンテージ：0倍
avg win adv：14035バイトavg win adv：66608バイト
初期ウィンドウ：32バイト初期ウィンドウ：40バイト
初期ウィンドウ：1 pkts初期ウィンドウ：1 pkts
ttlストリーム長：2512バイトttlストリーム長：NA
欠落データ：0バイト欠落データ：NA
切り捨てられたデータ：0バイト切り捨てられたデータ：0バイト
切り捨てられたパケット：0パケット切り捨てられたパケット：0パケット
データ送信時間：1.181秒データ送信時間：1.236秒
最大アイドル時間：196.9ミリ秒最大アイドル時間：196.9ミリ秒
スループット：1660 Bpsスループット：9471 Bps
RTTサンプル：18 RTTサンプル：24
RTT最小：43.8ミリ秒RTT最小：0.0ミリ秒
RTT最大：142.5ミリ秒RTT最大：7.2ミリ秒
RTT平均：68.5ミリ秒RTT平均：0.7ミリ秒
RTT stdev：35.8 ms RTT stdev：1.6 ms
3WHSからのRTT：80.8ミリ秒3WHSからのRTT：0.0ミリ秒
RTT full_sz smpls：1 RTT full_sz smpls：3
RTT full_sz min：142.5 ms RTT full_sz min：0.0 ms
RTT full_sz max：142.5 ms RTT full_sz max：0.0 ms
RTT full_sz平均：142.5ミリ秒RTT full_sz平均：0.0ミリ秒
RTT full_sz stdev：0.0 ms RTT full_sz stdev：0.0 ms
損失後のack：0損失後のack：0
segs cum acked：0 segs cum acked：9
重複するack：0重複するack：1
トリプルデュパック：0トリプルデュパック：0
max＃retrans：0 max＃retrans：0
最小retr時間：0.0ms最小retr時間：0.0ms
最大retr時間：0.0ms最大retr時間：0.0ms
平均retr時間：0.0ms平均retr時間：0.0ms
sdv retr時間：0.0 ms sdv retr時間：0.0 ms
================================
于 2011-06-01T04:32:40.187 に答える
2
いつでもiperfのようなプログラムの周りにシェルループを貼り付けることができます。また、iperfがファイル（つまりstdin）またはttcpのようなプログラムから読み取ることができると仮定すると、シェルループがファイルをiperf/ttcpにN回キャットすることができます。
ファイルを送信し、バイナリ応答を待機してから、ファイルの別のコピーを送信するプログラムが必要な場合は、おそらくそれを自分でコーディングする必要があります。
于 2011-05-23T20:01:41.353 に答える
1
ラウンドトリップ時間についてクライアントアプリケーションで時間を測定するか、クライアントとの間で送受信されるネットワークトラフィックを監視して、完全な時間間隔を取得する必要があります。サーバーでの時間を測定すると、サーバーでのカーネルレベルの遅延と、すべてのネットワーク送信時間が除外されます。
于 2011-05-31T22:23:32.737 に答える
0
非常に単純な高レベルのツールとしてnetcatが思い浮かびます...したがってtime (nc hostname 1234 < input.binary | head -c 100)、応答が100バイトの長さであると仮定するようなものです。
于 2012-11-28T15:21:09.260 に答える
0
負荷が高くなると、TCPのパフォーマンスが低下することに注意してください。重い負荷の下でテストする場合は、数千（場合によっては数百万）の新しい接続/2番目または同時に確立されたTCP接続に拡張できる専門的なツールが必要です。
私は自分のブログにこれに関する記事を書きました（これが広告と見なされる場合は削除してくださいが、このスレッドに関連していると思います）：http ://synsynack.wordpress.com/2012/04/09/realistic-latency-アプリケーション層での測定
于 2012-04-10T10:37:58.823 に答える