Übungen zu Kommunikationssysteme

Übungen zu
Kommunikationssysteme
Messung und Monitoring
Kai-Steffen Hielscher
Dr.-Ing. Falko Dreßler
Lehrstuhl für Rechnernetze und Kommunikationssysteme
Friedrich-Alexander-Universität Erlangen-Nürnberg

Überblick
• Meßaktivitäten am Lehrstuhl
• Monitoring in der Leistungsbewertung
• GPS-gestützes Monitoring verteilter Systeme
• Netflow-Analyse, IPFIX/PSAMP (in Englisch)
• Meßwerkzeuge und Benchmarks
TTCP (in Englisch)
NetPerf (in Englisch)
NPAG
HTTPerf (in Englisch)
2

Meßaktivitäten am Lehrstuhl
• GPS-gestützes Monitoring verteilter Systeme
K. Hielscher
• Monitoring-Infrastruktur für IP-Netze
Filterung, Aggregation, Sampling
IPFIX/PSAMP
F. Dreßler
• Spezifikationsgesteuertes Monitoring rekonfigurierbarer
Hardware
R. Hofmann
• Modellgestütztes statistisches Testen
Funktional, Dienstgüte
W. Dulz, M. Beyer
3

Methoden der Leistungsmessung
• Aktives Messen
Beobachtung des Objektsystems unter definierter, synthetisch
erzeugter Last
Benchmarking
• Passives Messen
Beobachtung des Objektsystems unter realer Last, ohne zusätzlich
erzeugte synthetische Last
Monitoring
• Ereignisgesteuerte Messung
Informationsaufzeichnung beim Auftreten eines bestimmten Ereignisses
z.B. Eintreffen einer Nachricht, Absenden einer Nachricht
• Sampling
Periodisches Aufzeichnen von Informationen
z.B. Aufzeichnung der CPU-Last
4

Methoden der Leistungsbewertung
• Summarische Leistungswertung
z.B. bei Benchmarks
Kompakte Leistungsaussagen: z.B. CPU-Auslastung, Durchsatz
Black-Box-Modell
• Ablauforientierte Leistungsbewertung
Ereignisfolgen
Ereignisse: besitzen keine Dauer
Aktivitäten: Beginn und Ende durch Ereignisse markiert
Ereignisspur: Ereigniskennung und zugehöriger Zeitstempel
Zeitstempel
1034086635.013378727
1034086635.013403696
1034086635.015372540
Ereigniskennung und Attribute
Receive ( 192.168.3.202, 54891 )
Send ( 192.168.3.202, 54891 )
Receive ( 192.168.3.202, 54896 )
5

Ablauforientierte Leistungsmessung
• Hardware-Monitoring
Ereigniserkennung
Generierung des Zeitstempels in Hardware
Aufzeichnung der Ereignisspur
Erkennung von Ereignissen auf höheren Schichten problematisch
Interface
Ereigniserkennung
Ereignisrecorder
Prozessor-Bus
herausgeführter Bus
Erkennt, ob ein
Ereignis vorliegt
(z.B. Adresse)
Greift
Ereigniskennung
und Attribute ab
(z.B. Adresse,
Daten)
Zeichnet
Ereignisspur auf
6

Hardware-Monitor ZM4
Minimalkonfiguration
M
T
G
OBJ 1 OBJ 4
D
P
U 1
OBJ 5 OBJ 8
D
P
U 1
OBJ i
D
P
U 4
Takt-
Kanal
OBJ j
D
P
U 1
MA
1
: PC MA
2
: PC MA
n
:
OBJ k
PC
D
P
U 4
verteiltes
Objektsystem
verteiltes
Monitorsystem
ZM4
Daten- und Steuernetz
STAR
7

Ablauforientierte Leistungsmessung
• Software-Monitoring
Ereigniserkennung
Zeitstempelung
Aufzeichnung der Ereignisse
in Software auf dem Objektsystem
Eventuell Verzögerungen bei Aufzeichnung von Ereignissen
hardwarenaher Schichten
Applikation
Ereignisspuren
IP Stack
Uhr
Ereignisaufzeichnung
Betriebssystem
Hardware
Puffer
8

Ablauforientierte Leistungsmessung
• Hybrid-Monitoring
Ereigniserkennung in Software
Zeitstempelung in Hardware oder Software
Aufzeichnung der Ereignisse in Hardware
Erkennung von Ereignissen auf höheren Schichten möglich
Ereignisrecorder
Ereignis-
Erkennung und
Signalerzeugung
Interface
Bus
herausgeführter Bus
9

GPS-gestützes Monitoring verteilter Systeme
• Leistungsvorhersage für clusterbasierte Webserver-
Konfigurationen
Simulationsmodell
Am realen System gemessene Daten
- Parametrierung des Modells
- Kalibrierung des Modells
- Überprüfung der Ergebnisse
Ablauforientierte Leistungsbewertung
Aktive Messung
Software-Monitoring
10

Webcluster: Funktion
Generierung einer
Anfrage
Übertragung der
Anfrage
Auswahl eines
Webserver-Knotens
Modifikation der
Anfrage
Übertragung der
Anfrage
Bearbeitung der
Anfrage
Internet
Lastgeneratoren
Übertragung der
Antwort
Modifikation der
Antwort
Lastverteilungsknoten
Übertragung der
Antwort
Webserver-Knoten
Generierung der
Antwort
11

TCP-/UDP-Instumentierung
Web
Server
Application
User Space
Analysis Process
online / offline
TCP/IP
Stack
Clock
Netfilter
Kernel
Buffer
Kernel Space
Hardware
12

Zeitsynchronisation
• Verteiltes Objektsystem
Messung der Einwegverzögerungen von TCP-Segmenten
Schwankung der Meßwerte mit der Zeitdifferenz zwischen Knoten
Frequenzänderung mit Temperatur führt zu veränderten
Zeitdifferenzen
13

Zeitdifferenzen
14

NTP
• Network Time Protocol
• RFC 1305
• Zwei-Wege-Zeitübertragung
• 4 Zeitstempel zur Berechnung der Zeitdifferenz
Absendezeitpunkt Client → Server T 1
(Client-Uhr)
Empfangszeitpunkt Client → Server T 2
(Server-Uhr)
Absendezeitpunkt Server → Client T 3
(Server-Uhr)
Empfangszeitpunkt Server → Client T 4
(Client-Uhr)
• Auf Basis von periodischen Zeitdifferenzmessungen kann Frequenzdifferenz
bestimmt werden
• Korrektur der Uhr des Rechners mittels Anpassung der Frequenz
Slew-Mode
Funktion
- Timer-Interrupt alle 10ms (nominal)
- Erhöhung der Uhr um einen bestimmeten Betrag (≈10 ms) bei Timer-Interrupt
- Anpassung des Betrages, um den die Uhr erhöht wird
- Entspricht Frequenzanpassung
• Zeitstempel über das Netzwerk:
Genauigkeit im Millisekundenbereich
17

NTP
Symmetrischer Kanal, kein Offset der Uhren
θ= 0
T 2
= 3 T 3
= 7
0 1 2 3 4 5 6 7 8 9 10 11 12
t 1
T 1
= 1
T 4
= 9
0 1 2 3 4 5 6 7 8 9 10 11 12
t 2
Offset:
θ = ½ [(T 2
- T 1
) + (T 3
- T 4
)]
= ½ [(3 - 1) + (7 - 9)]
= ½ [2 - 2]
= ½ · 0
= 0
Delay (Round-Trip):
δ = (T 4
- T 1
) - (T 3
- T 2
)
= (9 - 1) - (7 - 3)
= 8 - 4
= 4
18

NTP
Symmetrischer Kanal, Offset der Uhren (θ = 1)
θ= 1
T 2
= 4 T 3
= 8
0 1 2 3 4 5 6 7 8 9 10 11 12
t 1
T 1
= 1
T 4
= 9
0 1 2 3 4 5 6 7 8 9 10 11 12
t 2
Offset:
θ = ½ [(T 2
- T 1
) + (T 3
- T 4
)]
= ½ [(4 - 1) + (8 - 9)]
= ½ [3 + ( -1 )]
= ½ · 2
= 1
Delay (Round-Trip):
δ = (T 4
- T 1
) - (T 3
- T 2
)
= (9 - 1) - (8 - 4)
= 8 - 4
= 4
19

NTP
Asymmetrischer Kanal, kein Offset der Uhren
θ= 0
T 2
= 4 T 3
= 8
0 1 2 3 4 5 6 7 8 9 10 11 12
t 1
T 1
= 1
T 4
= 9
0 1 2 3 4 5 6 7 8 9 10 11 12
t 2
Offset:
θ = ½ [(T 2
- T 1
) + (T 3
- T 4
)]
= ½ [(4 - 1) + (8 - 9)]
= ½ [3 + ( -1 )]
= ½ · 2
= 1
Delay (Round-Trip):
δ = (T 4
- T 1
) - (T 3
- T 2
)
= (9 - 1) - (8 - 4)
= 8 - 4
= 4
20

Zeitkorrektur durch Frequenzanpassung
Gemessene Zeit
Gang der Uhr korrigiert durch NTP
Frequenzfehler
Uhr zu langsam
Gang der Uhr unkorrigiert
Offset
Niedrigere Frequenz zum Ausgleich des Offsets
Referenzzeit
21

NTP und die PPS-API
User Space
NTP
Clock
PPS API
PPS pulses
Kernel Space
Hardware
• Zur Anbindung von (externen) Referenzuhren
GPS, GALILEO, DCF-77, MSF, WWVB, LORAN-C, …
• RFC 2783
• Genauigkeit im Mikrosekundenbereich
22

Internet
Load
Balancer
Real Servers
Load
Generator
PPS serial connection
GPS
Subsystem
NTP Network
NTP
Server
23

GPS-Hardware
24

Beispiel-Messungen
• Messung der Zeit (Delay) in
einzelnen Teilsystemen
LG
C1
LB
C2
RS
1
SYN
SYNACK
7
2
6
SYN
3
5
SYNACK
4
8
ACK
9
ACKPSH
10
ACK
11
Request
ACK
ACKPSH
15
14
ACK
13
ACKPSH
12
Reply
16
ACK
ACK
24
17
FINACK
FINACK
23
25
ACK
18
22
26
FINACK
19
21
FINACK
ACK
27
20
25

Detailliertes Simulationsmodel
29

Modell - TCP
• RFC 793
• RFC 1122
• RFC 2581
Slow Start
Congestion Avoidance
Fast Retransmit
Fast Recovery
• RFC 2988
Retransmission Timeout:
Computation and
Implementation
Karn’s Algorithm
30

Eingabemodellierung
• Auf Basis der gemessenen Verzögerungen
Theoretische Verteilungsfunktionen
Multimodale Verzögerungen
Verzögerungen mit unsterschiedlichen Phasen
Bézier-Verteilungen mit Phasen
Autokorrelation
31

Weitere Nutzung der Meßinfrastruktur
• Messungsbasierte Modellierung von Ende-zu-Ende-
Verzögerungen in Funknetzwerken nach IEEE 802.11b
Ziele der Arbeit:
- Kalibrieren des Simulationsmodells (ns-2)
- realistische Leistungsbewertung auch für Konfigurationen jenseits
der Laboranlage
Wichtigste Ergebnisse
- Kreuzkorrelationen wichtig
- Anpassung des ns-2 Modells wichtig für bestimmte Systeme
A. Heindl
32

Infrastruktur für WLAN-Messungen
33

Simulationsergebnisse WLAN
• UDP-Verbindungen mit 800 Byte Nutzlast-Paketen
• Gemessene Delays mit empirischen Verteilungen
modelliert
34

Netflow Accounting
• IPFIX (IP Flow Information eXport) WG (IETF)
• Formerly Cisco Netflow v5…v9
• Goals
Collect usage information of individual data flows
Accumulate packet and byte counter to reduce the size of the monitored data
• Working principle
Each flow is represented by the IP 5-tupel (prot, src-IP, dst-IP, src-Port, dst-
Port)
For each arriving packet, the statistic counters of the appropriate flow are
modified
If a flow is terminated (TCP-FIN, timeout), the record is exported
Sampling algorithms can be activated reducing the # of flows / data to be
analyzed
• Benefits
Allows high-speed operation (standard PC: up to 1Gbps)
Flow information can simply be used for accounting purposes as well as to
detect attack signatures (increasing # of flows / time)
35

IPFIX Protocol
• draft-ietf-ipfix-protocol-03.txt
• Information records
Template Record defines the structure and interpretation of fields in a Flow Data
Record
Flow Data Record is a data record that contains values of the Flow parameters
corresponding to a Template Record
Options Template Record defines the structure and interpretation of fields in an
Options Data Record, including defining how to scope the applicability of the
Options Data Record
Options Data Record is a data record that contains values and scope information
of the Flow measurement parameters, corresponding to an Options Template
Record
• Transport protocol
SCTP must be implemented, TCP and UDP may be implemented
SCTP should be used
TCP may be used
UDP may be used (with restrictions – congestion control!)
36

IPFIX – Terminology
• IP Traffic Flow
A flow is defined as a set of IP packets passing an observation point in
the network during a certain time interval. All packets belonging to a
particular flow have a set of common properties.
• Observation Point
The observation point is a location in the network where IP packets can
be observed. One observation point can be a superset of several other
observation points.
• Metering Process
The metering process generated flow records. It consists of a set of
functions that includes packet header capturing, timestamping,
sampling, classifying, and maintaining flow records.
Packet header
capturing
Timestamping
Classifying
Maintaining
flow records
37

IPFIX – Terminology II
• Flow Record
A flow record contains information about a specific flow that was
metered at an observation point. A flow record contains measured
properties of the flow (e.g. the total number of bytes of all packets of
the flow) and usually also characteristic properties of the flow (e.g. the
source IP address).
• Exporting Process
The exporting process sends flow records to one or more collecting
processes. The flow records are generated by one or more metering
processes.
• Collecting Process
The collecting process receives flow records from one or more
exporting processes for further processing.
38

IPFIX – Working Principles
• Identification of single traffic flows
5-tupel: Protocol, Source-IP, Destination-IP, Source-Port, Destination-
Port
Example: TCP, 134.2.11.157, 134.2.11.159, 2711, 22
• Collection of statistics for each traffic flow
# bytes
# packets
• Periodical statistic export for further analysis
Flow
TCP, 1.2.3.4, 5.6.7.8, 4711, 22
TCP, 1.2.3.4, 5.6.7.8, 4712, 25
Packets
10
7899
Bytes
5888
520.202
39

IPFIX – Applications
• Usage based accounting
For non-flat-rate services
Accounting as input for billing
Time or volume based tariffs
For future services, accounting per class of service, per time of day, etc.
• Traffic profiling
Process of characterizing IP flows by using a model that represents key
parameters such as flow duration, volume, time, and burstiness
Prerequisite for network planning, network dimensioning, etc.
Requires high flexibility of the measurement infrastructure (objectives of traffic
profiling can vary)
• Traffic engineering
Comprises methods for measurement, modeling, characterization, and control of
a network
The goal is the optimization of network resource utilization
40

IPFIX – Applications II
• Attack/intrusion detection
Capturing flow information plays an important role for network security
Detection of security violation
1) detection of unusual situations or suspicious flows
2) flow analysis in order to get information about the attacking flows
• QoS monitoring
Useful for passive measurement of quality parameters for IP flows
Validation of QoS parameters negotiated in a service level specification
Often, correlation of data from multiple observation points is required
This required clock synchronization of the involved monitoring probes
41

Packet Sampling
• PSAMP (Packet SAMPling) WG (IETF)
• Goals
Network monitoring of ultra-high-speed networks
Sampling of single packets including the header and parts of the
payload for post-analysis of the data packets
Allowing various sampling and filtering algorithms
- Algorithms can be combined in any order
- Dramatically reducing the packet rate
• Benefits
Allows very high-speed operation depending on the sampling algorithm
and the sampling rate
Post-analysis for statistical accounting and intrusion detection
mechanisms
42

ReportingThread
Output
buffer
Implementation of PSAMP / IPFIX
43
ObserverThread
SelectionThread
packet Queue packet Queue
libpcap
Filter / Sampler
List
...

Measurement Tools and Benchmarks
• Measurement Tools
TTCP
Netperf
NPAG
• Benchmarks
HTTPerf
44

Practical Measurement Tools: TTCP
• Measure TCP throughput
Ttcp on two hosts, one as active transmitter, one as receiver
Can send TCP or UDP
Receiver computes effective throughput
Simple, light-weight, no super user privilege
45

TTCP
• Available for Linux
• Also available as a GUI-Java application
• Transmitter
ttcp −t [−u] [−s] [−p port] [−l buflen]
[−b size] [−n numbufs] [−A align] [−O
offset] [−f format] [−D] [−v] host [out]
46

TTCP Options 1
−t
−r
−u
−s
−l length
−b size
Transmit mode.
Receive mode.
Use UDP instead of TCP.
If transmitting, source a data pattern to network; if
receiving, sink (discard) the data. Without the −s option,
the default is to transmit data from stdin or print the
received data to stdout.
Length of buffers in bytes (default 8192). For UDP, this
value is the number of data bytes in each packet. The
system limits the maximum UDP packet length. This limit
can be changed with the −b option.
Set size of socket buffer. The default varies from system to
system. This parameter affects the maximum UDP packet
length. It may not be possible to set this parameter on
some systems (for example, 4.2BSD).
47

TTCP Options 2
−n numbufs
−p port
−D
−B
−A align
−O offset
Number of source buffers transmitted (default 2048).
Port number to send to or listen on (default 2000). On
some systems, this port may be allocated to another
network daemon.
If transmitting using TCP, do not buffer data when sending
(sets the TCP_NODELAY socket option). It may not be
possible to set this parameter on some systems (for
example, 4.2BSD).
When receiving data, output only full blocks, using the
block size specified by −l. This option is useful for
programs, such as tar(1), that require complete blocks.
Align the start of buffers to this modulus (default 16384).
Align the start of buffers to this offset (default 0).
For example, ‘‘−A8192 −O1’’ causes buffers to start at the
second byte of an 8192-byte page.
48

TTCP Options 3
−f format
−T
−v
−d
Specify, using one of the following characters, the format
of the throughput rates as kilobits/sec (’k’), kilobytes/sec
(’K’), megabits/sec (’m’), megabytes/sec (’M’), gigabits/sec
(’g’), or gigabytes/sec (’G’). The default is ’K’.
‘‘Touch’’ the data as they are read in order to measure
cache effects.
Verbose: print more statistics.
Debug: set the SO_DEBUG socket option.
49

TTCP Java Version
• java -cp . ttcp
• Command line options (like Unix version)
• GUI
= Num Buffers ∙ Buffersize Results
50

Practical Measurement Tools: Netperf
• Measure available bandwidth between two nodes
Generate different traffic patterns
- Bulk data transfer (e.g. FTP)
- Interactive data exchange (e.g. rlogin)
More detailed and precise measurement than ttcp:
- socket buffer sizes, amount of data, elapsed time, effective
throuhghput, number of frames dropped
Besides TCP/UDP, also support datalink and other network protocols
51

NetperfBulkDataTransfer
• TCP Stream Performance
netperf -H remotehost
performs a 10 second test between the local system and
the system identified by remotehost. The socket buffers
on either end will be sized according to the systems'
default and all TCP options (e.g. TCP_NODELAY) will be
at their default settings.
52

Netperf TCP Stream Options
-s sizespec
-S sizespec
-m value
-M value
-l value
-D
set the local send and receive socket buffer sizes
[Default: system default socket buffer sizes]
behaves just like -s but for the remote system
set the local send size to value bytes.
[Default: local socket buffer size]
behaves like -m, setting the receive size for the remote
system. [Default: remote receive socket buffer size]
set the test length to value seconds when value is > 0 and
to |value| bytes when value is < 0
set the TCP_NODELAY option on both systems
53

Netperf TCP Stream Scripts
• tcp_stream_script
invokes netperf with different socket (57344, 32768,
8192) and send sizes (4096, 8192, 32768).
• tcp_range_script
invokes netperf with a fixed socket size (32768) and
increasing send size (1 to 65536).
• Predefined minimum (2) and maximum (10) number of
observations
• Confidence level (99%) and relative CI width (5%)
54

Netperf TCP Stream Results
netperf -l 60 -H faui7s -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 32768 -S 32768
TCP STREAM TEST to faui7s : +/-2.5% @ 99% conf. : histogram : interval : dirty data
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
131070 212992 4096 60.01 93.60
!!! WARNING
!!! Desired confidence was not achieved within the specified iterations.
!!! This implies that there was variability in the test environment that
!!! must be investigated before going further.
!!! Confidence intervals: Throughput : 19.2%
!!! Local CPU util : 0.0%
!!! Remote CPU util : 0.0%
55

Netperf UDP Stream Options
• netperf -H remotehost -t UDP_STREAM -- -m 1024
• UDP unreliable protocol
• Reported send rate can be much higher than the actual
receive rate
• always report both send and receive rates together
56

Netperf – Other Bulk Data Transfer
Measurements
• DLPI Connection Oriented Streams
• DLPI Connectionless Streams
• Unix Domain Stream Sockets
• Unix Domain Datagram Sockets
• Fore ATM API Streams
57

Netperf Request/Response Performance
Measurements
• TCP
netperf -H remotehost -t TCP_RR
default request size 1 byte
default response size of 1 byte
tcp_rr_script
- Different RequestSize,-ResponseSize)-Pairs
(1,1 64,64 100,200 128,8192)
- Confidence Level 99% and 5% relative CI width
• UDP
netperf -H remotehost -t UDP_RR
udp_rr_script
• Other request/response Measurements
DLPI, Unix Domain Sockets, ATM, …
58

Netperf TCP Request/Response Options
-r sizespec
-l value
-s sizespec
-S sizespec
-D
request and/or response sizes
test duration
For value > 0, test duration will be value seconds.
Otherwise, test duration will be |value| transactions.
local send and receive socket buffer sizes
[Default: system default socket buffer sizes]
like-s butfortheremotesystem
set the TCP_NODELAY option
59

NPAG - Übersicht
Header frei
programmierbar
Verkehrs-modell
Parallelität
Pakettypen
Ttcp
---
Max. Durchsatz
---
TCP, UDP
NetPerf
---
Max. Durchsatz
---
TCP, UDP
Npag
Ja
Variabel
Ja
TCP, UDP, IP,
ICMP
60

NPAG - Design
• Client Server Modell
• Parallelität durch Threads
• Messung durch Integration von Zeitstempel
• Zeitsynchronisation wird vorausgesetzt
Server
Client
Client
NETZ
Server
User Spezifikation
Client
Client Generator
NTP
Server
61

NPAG - Benutzerschnittstelle
• Spezifizierung durch Skriptsprache
• Einfach und übersichtlich
• Schlüsselwörter
stream
tcp, udp, icmp6, ip, ip6
traffic
burst
#stream specification
stream {
tcp {
…
}
ip {
…
}
traffic {
burst {
.…
}
}
}
62

NPAG - Verkehrsbeschreibung
• In der realen Welt ist Datenrate eines Verkehrsstroms meist nicht konstant
• Dies wird berücksichtigt: Datenrate kann während der Messung variiert
werden
Beispiel:
burst1 burst2 burst3 burst4
traffic {
}
burst {
packets = 100;
delay = 0.1;
repeat = 2;
}
bust {
packets = 200;
delay = 0.2;
repeat = 2;
}
63

Beispiel: Verkehrsstrom
• Spezifikation eines Verkehrsstroms mit
folgenden Eigenschaften:
TCP: Quellport 5000
Zielport 5001
IPv4: Quelladresse 192.168.0.2
Zieladresse 192.168.0.1
Versenden von 100 Paketen je 100 Byte.
Messung des maximalen Durchsatzes
#stream definition
stream {
}
#specify tcp
tcp {
sport = 5000;
dport = 5001;
}
#specify ip
ip {
src = 192.168.178.2;
dst = 192.168.178.1;
}
#secify traffic parameters
traffic {
burst {
send_packets = 100;
size = 100;
}
}
64

NPAG - Anwendungsmöglichkeiten
• Messung des Durchsatzes bei variabler Datenrate
• Messung der Verzögerung
• Paketverluste (UDP)
• Zum Testen des Protokollstacks, Firewalls, ISS lassen sich verschiedene
Pakete zusammenstellen
IP-Spoofing
Dst_addr = src_addr;
IP-Version 4
Ungültige Flags
Ungültige Header-Werte
65

Benchmarks
• Web server benchmarks: simulation of Web clients
Httperf
- Single client generating HTTP requests
- Several optimizations to circumvent operating system restrictions
- Different workload models
• Constant request rate
• Sequential requests
• Requests from log file
• Session-oriented with bursts
• Cyclic set of URIs
- Command line options:
httperf [--burst-length N] [--client I/N] [--close-withreset]
[-d|--debug N] [--failure-status N] [-h|--help]
[--hog] [--http-version S] [--num-calls N] [--num-conns
N] [--port N] [--rate X] [--recv-buffer N] [--sendbuffer
N] [--server S] [--think-timeout X] [--timeout X]
[--uri S] [-v|--verbose] [-V|--version] [--wlog y|n,F]
[--wsess N,N,X] [--wset N,X]
66

HTTPerf Options 1
--burst-length=N
--client=I/N
--close-with-reset
-d=N
--debug=N
--failure-status=N
-h
--help
Specifies the length of bursts. Each bursts consists of
N calls to the server.
Specifies that the machine httperf is running on is
client I out of a total of N clients. I should be in the
range from 0 to N-1.
Requests that httperf closes TCP connections by
sending a RESET instead of going through the
normal TCP connection shutdown handshake.
Set debug level to N. Larger values of N will result in
more output.
Specifies that an HTTP response status code of N
should be treated as a failure (i.e., treated as if the
request had timed out, for example).
Prints a summary of available options and their
parameters.
67

HTTPerf Options 2
--hog
--http-version=S
--num-calls=N
--num-conns=N
--port=N
This option requests to use up as many TCP ports as
necessary.
By default, version string „1.1‚“ is used. This option
can be set to „1.0“ to force the generation of
HTTP/1.0 requests.
This option specifies number of calls to issue on each
connection. If N is greater than 1, the server must
support persistent connections. The default value for
this option is 1.
This specifies the total number of connections to
create. On each connection, calls are issued as
specified by options --num-calls and --burst-length.
The default value for this option is 1.
This option specifies the port number N on which the
web server is listening for HTTP requests. By default,
httperf uses port number 80.
68

HTTPerf Options 3
--rate=X
--recv-buffer=N
--send-buffer=N
--server=S
Specifies the fixed rate at which connections or
sessions are created. A rate of 0 results in connections
or sessions being generated sequentially (a new
session/connection is initiated as soon as the
previous one completes). The default value for this
option is 0.
Specifies the maximum size of the socket receive
buffers used to receive HTTP replies. By default, the
limit is 16KB.
Specifies the maximum size of the socket send
buffers used to send HTTP requests. By default, the
limit is 4KB.
Specifies the IP hostname of the server. By default,
the hostname “localhost“ is used. This option should
always be specified.
69

HTTPerf Options 4
--think-timeout=X
--timeout=X
--uri=S
-v
--verbose
-V
--version
Specifies the maximum time that the server may
need to produce the reply for a given request. Note
that this timeout value is added to the normal
timeout value (see option --timeout).
Specifies the amount of time X that httperf is willing
to wait for a server reaction. The timeout is specified
in seconds and can be a fractional number (e.g., --
timeout 3.5). By default, the timeout value is infinity.
Specifies that URI S should be accessed on the
server.
Puts httperf into verbose mode. In this mode,
additional output such as the individual reply rate
samples and connection lifetime histogram are
printed.
Prints the version of httperf.
70

HTTPerf Options 5
--wlog=B,F
--wsess=N1,N2,X
This option can be used to generate a specific
sequence of URI accesses. This is useful to replay
the accesses recorded in a server log file, for
example. Parameter F is the name of a file containing
the ASCII NUL separated list of URIs that should be
accessed. If parameter B is set to „y“, httperf will
wrap around to the beginning of the file when
reaching the end of the list (so the list of URIs is
accessed repeatedly). With B set to „n“, the test will
stop no later than when reaching the end of the URI
list.
Requests the generation and measurement of
sessions instead of individual requests. A session
consists of a sequence of bursts which are spaced
out by the user think-time. Each burst consists of a
fixed number L of calls to the server (L is specified
by option --burst-length).
71

HTTPerf Options 6
--wset=N,X
This option can be used to walk through a list of
URIs at a given rate. Parameter N specifies the
number of distinct URIs that should be generated
and X specifies the rate at which new URIs are
accessed. A rate of 0.25 would mean that the same
URI would be accessed four times in a row before
moving on to the next URI.
72

HTTPerf Output
Total: connections 30000 requests 29997 replies 29997 test-duration 299.992 s
Connection rate: 100.0 conn/s (10.0 ms/conn,

Sample HTTPerf Server Performance Graph
74