UNIX Netzwerk-Tools

Prof. Jürgen Plate

2 Statistik und Lastmessung

2.1 Serverstatistik

Unix-Tools

http-analyze: Das Programm von Stefan Stapelberg vereint viele Funktionen anderer Statistikprogramme -- und ist freie Software.
http://www.netstore.de/Supply/http-analyze/
Sawmill: (früher Chartreuse Cartouche) kann beliebige Logdate-Formate lesen und detaillierte grafische Statistiken liefern. Es kann als CGI-Programm die Statistik auch "on-the-fly" liefern. Konfiguration über ein WWW-Interface.
http://www.flowerfire.com/sawmill/
The Webalizer: schnelles, freies Analyseprogramm, das die Statistiken im HTML-Format ablegt. Für verschiedene Logformate. Detaillierte Statistiken.
http://www.webalizer.org/
Checklog: ist ein einfaches Perl-Skript zum Generieren von Reports. Das Programm versucht zu ermitteln, wie viele Personen den Server besuchen und wie tief sie in die Seiten gehen.
http://www.rpg.net/help/checklog
wusage: ist ein C-Programm zum Generieren von grafischen Logfile-Statistiken. Läuft auf verschiedenen Plattformen.
http://www.boutell.com/wusage/
getstats: ist ein C-Programm zum Generieren von detaillierten Statistiken (stündlich, täglich, wöchentlich, monatlich, nach Domain etc.). Getgraph produziert dann grafische Darstellungen der Reports.
http://www.uu.se/Software/Getstats/
Analog: arbeitet ähnlich wie getstats, ist jedoch schneller und hat ein etwas unterschiedliches Ausgabeformat. Konfigurierbar und mehrsprachig.
http://www.analog.cx/
W3Perl: ist ein grafisches Statistikpaket, das in Perl geschrieben wurde. Es erhebt den Anspruch, das umfassendste und umfangreichste Server-Statistik-Tool zu sein.
http://www.w3perl.com/
WWWStat: erzeugt die Serverstatistiken im HTML-Format. Dateinamen müssen im Quelltext (Perl) angepaßt werden. Verschiedene Möglichkeiten der Statistik-Ausgabe.
http://www.ics.uci.edu/WebSoft/wwwstat/
BrowserCounter: ist ein Agent Log Analyzer. Das Programm listet alle Browser auf, die den Server besucht haben.
http://www.nihongo.org/snowhare/utilities/browsercounter.html
Summary: erlaubt in der Profi-Version Sub-Reports für virtuelle Domains, liefert umfangreiche Reports (auch für Referrer) und erlaubt den Export der Daten.
http://www.summary.net/summary.html

Plattformunabhängige Tools

Bazaar Analyzer Ein Logfile-Analysator, der mit jedem Java-fähigen Browser funktioniert. Viele Features und Grafikausgabe. Die Standardversion ist kostenlos.
3D UWwebmon ist ein Java-Applet das mit jedem Java-fähigen Browser funktioniert. Grafikausgabe, konfigurierbar.
WatchWise erlaubt Echtzeit-Analyse und -statistik, verwendet eine eigene Datenbank.
Webtrax ist ein freies Perl-5-Programm für das NCSA Combined log format.

Einfache Statistik-Tools

Wenn es nur um eine übersicht geht oder wenn nur ganz bestimmte Dateien statistisch untersucht werden sollen, dann geht es sogar mit "Bordmittteln". Um nur die Anzahl von Abrufen zu ermitteln, genügt ein Shellskript. Das folgende Mini-Script soll Ihnen zeigen, wie einfach das ist. Voraussetzung für das Gelingen ist die Verwendung der GNU-Versionen der Programme. Das Script muß zudem am ersten Tag des Monats aufgerufen werden. Es liefert dann die Statistik für den vergangenen Monat. Die Ergebnisse werden in eine Datei geschrieben, deren Name durch die Variable DATEI vorgegeben ist. Die Variable SUCH gibt ein Suchmuster für die Dokumentennamen vor. Dies kann ein Namensteil einer Datei oder ein Pfadname sein, z.B. index -- definiert als regulärer Ausdruck. Der sed-Aufruf entfernt Dateipfade und andere unnötige Dinge aus der Eingabe. Gegebenenfalls müssen Sie das Skript Ihren Wünschen anpassen.

#!/bin/sh
# Zugriffsstatistik
#
DATEI=/home/httpd/stat/stat.txt
{
cd /home/httpd/stat
echo ""
echo "abgerufene Dokumente `date --date '1 days ago' '
echo "-----------------------------"
echo ""
echo "     Anz.  Datei"
echo ""
grep "$SUCH" /var/log/httpd.access_log | \
  grep "$AKT" | \
  sed -e 's?^/.*/??' -e 's?^/??' -e 's? HTTP.*$??' | \
  grep ".html" | \
  sort | \
  uniq -c
} > $DATEI

Zugriffe auswerten mit Webalizer

Es gibt diverse Programme zum Aufbereiten von Server-Logdateien. Wie so oft ist die einfachste Lösung meist die beste. Der Webalizer ist ein Opensource-Programm zur Darstellung der Zugriffsstatistiken für eine Homepage. Er ist auf die unterschiedlichsten Plattformen portiert, z.B. Linux auf PC, Alpha und PPC, Solaris auf Sparc oder Windows. Die Auswertungsmöglichkeiten sind recht umfangreich und hängen davon ab, wie die Konfigurationsdatei des Webalizers und die Konfigurationsdatei des Webservers eingerichtet sind. Er kann zudem nicht nur für WWW-Logs, sondern auch für die Squid- und FTP-Logdateien verwendet werden.

Das Programm liefert eine Webstatistik der letzten 12 Monate. In der Übersicht sehen Sie die monatlichen Daten im Vergleich:

Zusammenfassung des Monats,
Tages-Statistik,
Statistik nach Uhrzeiten,
Auswertung nach abgerufenen Seiten,
Liste der Rechner, die auf die Webseiten zugegriffen haben,
Browsertypen
und vieles mehr

In den meisten Distributionen ist der Webalizer enthalten. Im Netz ist er über http://www.webalizer.org/ erhältlich. Dort stehen die Quellen und fertige Binaries für alle Plattformen zur Verfügung, die nur entpackt werden müssen.

Die Unterstützung verschiedener Sprachen ist leider etwas archaisch, denn es müssen die passenden Headerdateien einkompiliert werden -- es ist also auch das komplette Quellpaket erforderlich. Für eine Installation in Deutsch (und in anderen Sprachen) stellen z.B. die DLR oder die schwedische Firma Chalmers die Quellen zum Download bereit.

http://www.go.dlr.de/fresh/unix/src/www/.warix/webalizer-2.01-06-src.tgz.html

http://swamp.chl.chalmers.se/pub/www/tools/webalizer/

Im Folgenden wird eine relativ einfache Konfiguration beschrieben. Webalizer bietet darüber hinaus weitere Features, die in der beiliegenden Dokumentation beschrieben sind.

Wer die Installation mittels der Quell-Dateien vornimmt, muß diese auf normalem Wege mit der üblichen Befehlsfolge kompilieren. Die genaue Anleitung mit den Optionen, die bei ./configure möglich sind, kann man in der einfachen Installationsanleitung der Webalizer-Homepage nachlesen.

Konfiguration

Nach Installation des Webalizers enthält das Verzeichnis eine Standard-Konfigurationsdatei, in der viele Optionen voreingestellt sind. Andere sind auskommentiert, so daß man sie bei Bedarf nur aktivieren muß. Für den größten Teil der Optionen existiert eine Default-Einstellung, so daß prinzipiell kein Eintrag in der .conf-Datei nötig ist.

Es werden hier nur die wichtigsten Optionen der Konfigurationsdatei besprochen. Die Datei heißt standardmäßig webalizer.conf und sollte, damit sie beim Start des Webalizers ohne Pfadangabe gefunden wird, am besten in /etc/ stehen. Um sie zu benutzen, wird der Durchlauf dann einfach mit webalizer gestartet. Benutzt man verschiedene Konfigurationsdateien für verschiedene Aufgaben, so muß außer bei Benutzung von /etc/webalizer.conf als Konfigurationsdatei dem Programm stets der Pfad mit der Option -c mitgegeben werden. So lassen sich beispielsweise für jeden virtuellen Server getrennte Statistiken erstellen.

Nun wird die Konfigurationsdatei mit dem Editor bearbeitet. Suchen Sie die Zeile:

#LogFile /var/lib/httpd/logs/access\_log

Entfernen Sie das Kommentarzeichen (#) und ersetzen Sie die Pfadangabe mit dem Pfad zu Ihrem Apache-Logfile. In der Konfigurationsdatei muß angegeben werden, welche Logdatei benutzt werden soll, d.h. es gibt hier keine Voreinstellung.

LogFile   /var/log/httpd/access\_log

Es gibt mehrere Logfile-Formate, die benutzt werden können, das Standardformat heißt clf. Ebenso funktioniert der Durchlauf mit gezippten Logfiles im gz-Format, was man vielleicht nutzen möchte, weil man ab und zu große Logfiles packen will, um Plattenplatz zu sparen.

Dann sollten Sie das Verzeichnis angeben, in dem die Ergebnisse gespeichert werden sollen. Suchen Sie nun die Zeile:

#OutputDir /var/lib/httpd/htdocs/usage

Entfernen Sie das Kommentarzeichen und ersetzen Sie die Pfadangabe mit der zu dem Verzeichnis, in dem Sie die Berichte ablegen möchten. Dieses sollte sich in Ihrem Webverzeichnis befinden. Zum Beispiel:

OutputDir  /opt/www/htdocs/webalizer

Es empfiehlt sich natürlich, eigene Verzeichnisse für die Ausgabe zu erstellen. Falls man mit verschiedenen Konfigurationsdateien verschiedene Jobs erledigt, sollte man natürlich auch in der jeweiligen .conf-Datei das jeweilige Ausgabeverzeichnis angeben, da sonst Daten überschrieben werden oder, je nach Einstellung, neue Daten an solche angehängt werden, die überhaupt nicht dazu passen. Suchen Sie dann die Zeile:

#Incremental no

Entfernen Sie das Kommentarzeichen und ersetzen Sie "no" durch "yes". Hiermit weisen Sie Webalizer an, den Stand des Logfiles zu speichern und beim nächsten Aufruf an dieser Stelle fortzusetzen. Suchen Sie die Zeile

#ReportTitle Usage Statistics

Entfernen Sie das Kommentarzeichen und ersetzen Sie den Eintrag durch einen Titel Ihrer Wahl. Suchen Sie dann die Zeile

#HostName localhost

Entfernen Sie das Kommentarzeichen und tragen Sie Ihren Hostnamen ein.

Danach folgen viele eher unwichtige bzw. defaultmäßig richtig oder sinnvoll eingestellte Parameter (siehe Holzmann/Plate). Speichern Sie die Datei webalizer.conf.

Ausführen

Die einfachste Methode ist der Start von Hand. Damit wird die Logdatei ausgelesen und die HTML-Dateien mit der Serverstatistik in dem von Ihnen angegeben Verzeichnis erstellt. Webalizer sucht seine Konfigurationsdatei zuerst im aktuellen Verzeichnis und dann in /etc. Der Aufruf zum Test könnte dann lauten:

webalizer -c /etc/webalizer.conf

Der manuelle Aufruf ist auf Dauer natürlich nicht besonders praktisch. Besser ist da ein Eintrag für den Cron-Mechanismus. Man kann z.B. in die Datei /etc/crontab folgenden Eintrag aufnehmen:

30 4 * * *   root /opt/www/bin/webalizer > /dev/null 2>&1

Gegebenenfalls sind noch die Parameter -p für den inkrementellen Modus oder -c file zur Angabe der Konfigurationsdatei nötig. Weitere Parameter listet die Manualpage auf. Die Statistik rufen Sie mit Hilfe der Datei index.html im durch OutputDir spezifizierten Verzeichnis ab.

Der Webalizer ist auch in der Lage, die Informationen aus der Datei /var/log/transferlog für eine FTP-Statistik auszuwerten. Wenn Sie auch noch die Logdatei des Squid analysieren wollen, geht auch dies nach dem gleichen Schema wie für FTP.

2.2 Lastmessung am Server

Ein Benchmark (englisch: Bezugswert, Maßstab) ist ein Verfahren, um die Leistung eines Systems beurteilen zu können. Ein Benchmarkprogramm ermittelt Vergleichswerte, mit deren Hilfe verschiedene Systeme auf ihre Geschwindigkeit, Zuverlässigkeit und Stabilität geprüft und untereinander verglichen werden können. Benchmarkprogramme sind im allgemeinen speziell auf bestimmte Hardware bzw. Softwarekomponenten zugeschnitten. Die Ergebnisse sind jedoch immer vom verwendeten Benchmarkprogramm abhängig. Ein Vergleich von Ergebnissen unterschiedlicher Benchmarks ist daher nur bedingt aussagekräftig. Ein Benchmarkprogramm simuliert i. A. eine hohe Beanspruchung der zu testenden Hardware/Software. Dabei werden die verschiedenen Funktionen des zu testenden Objektes aufgerufen und die Geschwindigkeit der Reaktionen gemessen und aufgezeichnet. Außerdem kann ein längerdauernder Benchmark auch Hinweise über die Stabilität der zu testenden Hard- oder Software geben.

Die Ergebnisse des Benchmarks können als Anhaltspunkt für das Verhalten und die Geschwindigkeit der getesteten Hardware oder Software im realen Einsatz geben. Wie nahe diese Ergebnisse jedoch wirklich mit der Realität übereinstimmen, hängt vom verwendeten Benchmarkprogramm und seiner Abbildung des realen Betriebs ab. Bei der Auswertung der Ergebnisse muss deshalb immer beachtet werden, dass die Ergebnisse nur als Annäherung an die tatsächliche Leistung gesehen werden können. Dennoch können Benchmarks Anregungen für Optimierungen liefern.

Besonderheiten des Webserverbenchmarking

Bei einem Webserverbenchmark werden unter anderem die Anfragen pro Sekunde gemessen, die der Webserver verarbeiten kann. Weiter misst der Bechmark die Geschwindigkeit, mit der auf Anfragen reagiert wird. Dies betrifft zum Beispiel die Abarbeitung von CGI-Scripten und die Generierung dynamischer Webseiten. Um den Benchmark optimal an die jeweiligen Bedürfnisse anzupassen bieten die meisten Webserverbenchmarkprogramme diverse Einstellungsmöglichkeiten. Diese erlauben es, unter anderem, die Testroutinen des Programmes so einzustellen, dass der Benchmark eine möglichst hohe Übereinstimmung mit realen Bedingungen hat, um möglichst aussagekräftige Ergebnisse zu erhalten. Zum Beispiel kann man einen Webserver lediglich auf den Zugriff statischer beziehungsweise dynamischer HTML-Seiten testen oder man verwendet Einstellungen, die den Zugriff auf beide Arten simuliert. Ein Faktor, der die Ergebnisse stark verfälschen kann, ist der Ort, an dem der Benchmark durchgeführt wird. In der Regel befindet sich der Client mit dem Benchmarkprogramm an einem Switch mit dem Server, so dass nur minimale Übertragungszeiten zwischen Server und Client entstehen. In der Realität sind die Verzögerungen durch die Anbindung des Clienten an das Netz wesentlich höher (z. B.: Anbindung durch Modem, ISDN, DSL und hohe Netzlast).

Hardwareoptimierung

Die Geschwindigkeit von Webservern ist stark von der Hardwareausstattung des Computers abhängig, auf der das Programm läuft. Somit kann man durch Optimierung der Hardware bereits erhebliche Geschwindigkeitssteigerungen erreichen. Besonders wichtig ist hierbei der Arbeitsspeicher des Systems sowie die Geschwindigkeit der Festplatten. Außerdem kann auch der Einbau zusätzlicher Prozessoren die Geschwindigkeit steigern, wobei hier auch das verwendete Betriebssystem eine Rolle spielt. Je besser dieses die anfallende Systemlast auf die Prozessoren verteilt, desto höher der Geschwindigkeitsgewinn für die Anwendungen. Auch eine Vergrößerung der Bandbreite des Netzes kann die Geschwindigkeit des Webservers erhöhen.

Wie viele parallel laufende Serverprozesse sinnvoll sind, hängt von einer ganzen Reihe von Parametern ab. Zunächst einmal wäre es sicherlich schön, wenn immer genau so viele Bearbeiter vorhanden sind, wie gleichzeitige Requests bei der Maschine ankommen. Nun kann ein Rechner aber nicht beliebig viele Prozesse starten, und ein Webserver wird in genau dem Moment sehr viel langsamer, in dem die Maschine beginnt, Webserverprozesse mangels RAM in den Swapbereich auszulagern. Das ist ein sehr unangenehmer Moment, denn bei gleichbleibender Anzahl von Requests pro Sekunde ("Last bleibt gleich") dauert die Abarbeitung eines einzelnen Requests nun viel länger ("Durchsatz sinkt"), und damit steigt die Anzahl der ausstehenden Requests ("Ressourcenverbrauch steigt"). Das Gesamtsystem versucht darauf mit einer weiteren Erhöhung der Serverprozeßzahl zu antworten und treibt die Maschine nur noch weiter in den Swap - die Requests werden noch langsamer bearbeitet und als Antwort werden nur um so mehr Serverprozesse erzeugt.
In dieser Situation bricht die Systemleistung zusammen, oder das System kommt im Extremfall vollständig zum Halt. Mit Hilfe des Parameters "MaxClients" kann man beispielsweise beim Apache-Webserver die Anzahl der Serverprozesse nach oben begrenzen und so verhindern, daß die Maschine in diesen fatalen Zustand gerät - die Zahl muß so gewählt werden, daß die Maschine sicher nicht ins Swappen gerät. Als hilfreich hat sich hier die Analyse der Zahlen in /proc/<pid>/statm erwiesen, wobei als <pid> die Prozeßnummern der httpd-Prozesse einzusetzen sind:

plate@atlas:~ > server=`grep -l httpd /proc/*/cmdline`
plate@atlas:~ > echo $server
/proc/12366/cmdline /proc/16768/cmdline /proc/16769/cmdline /proc/16892/cmdline
/proc/23378/cmdline /proc/24373/cmdline /proc/3474/cmdline /proc/self/cmdline

plate@atlas:~ > for i in $server; do cat `dirname $i`/statm; done
1090 1005 951 40 0 965 576
1327 1242 919 49 0 1193 777
1330 1245 919 49 0 1196 780
1117 1032 968 48 0 984 575
1341 1256 918 49 0 1207 791
1117 1032 968 48 0 984 575

Die ausgegebenen Zahlen sind in /usr/src/linux/Documentation/proc.txt genauer erläutert. Sie bedeuten von links nach rechts:

size       total program size
resident   size of in memory portions
shared     number of the pages that are shared
trs        number of pages that are 'code'
drs        number of pages of data/stack
lrs        number of pages of library
dt         number of dirty pages

Der Gesamtspeicherverbrauch eines Serverprozesses ergibt sich aus seinen resident (im RAM befindlichen) Unshared Pages (Page-Größe 4 KB in Intel-Rechnern). Also ist die Differenz zwischen der zweiten und der dritten Zahl einer jeden Zeile zu bilden und mit vier zu multiplizieren, um den RAM-Verbrauch eines einzelnen httpd in KByte zu ermitteln. Bei obiger Tabelle ergibt sich (auf ganze KByte gerundet):

(1005 - 951)/4 = 14
(1242 - 919)/4 = 80
(1245 - 919)/4 = 80
(1032 - 968)/4 = 16
(1256 - 918)/4 = 85
(1032 - 968)/4 = 16

Bei einem geeigneten Wert für MaxClients erzielt der Apache-Webserver bei zunehmender Last ("ramp-up") linear mehr Durchsatz, bis der Sättigungspunkt erreicht ist. Danach bleibt die Leistung auf einem stabilen Plateau, wenn nicht ein anderer leistungsbegrenzender Faktor wirksam wird (Netzbandbreite, DNS-Lookups, Plattenbandbreite, CPU-Leistung).

Bei nachlassender Last reduziert der Managerprozeß die Anzahl der Serverprozesse bis auf "MaxSpareServers". Bei steigender Last wird der Manager diese Zahl dann wieder steigern. Da das Starten von neuen Serverprozessen einige Zeit dauert, bleiben immer "MinSpareServers" aktiv. Je stärker und je schneller die Last auf einem Webserver springt, um so größer sollte man den Abstand zwischen beiden Werten wählen. Je langsamer die Maschine beim Starten von neuen Serverprozessen ist und je ruckartiger die Last auf dem Server ansteigen kann, um so höher muß man MinSpareServers wählen, damit im Falle einer Spitzenlast schon ausreichend viele Server vorhanden sind.
(Nach einem Aufsatz von Kristian Köhntopp)

Stress-Tests

Hier - wie auch bei all den anderen Testprogrammen - sollte man die Tests auf lokale Server loslassen, sonst kann es ärger mit dem Provider geben (der vielleicht eine Denial-of-Service-Attacke vermutet) oder teuer werden (wenn nach Volumen bezahlt wird).

Den Server stressen

Oft soll nicht nur eine Netzverbindung getestet werden (überlegen Sie mal, wie man einen Mailserver per POP3-Anfrage testen könnte), sondern der Server selbst. Laufen alle Prozesse flüssig, sind CPU- oder Plattenlast im grünen Bereich? Für diesen Zweck eignet sich stress (http://weather.ou.edu/~apw/projects/stress/), das gezielt den Rechner stressen kann. So sorgt der Aufruf

stress --loadavg 20

für eine entsprechende CPU-Last (+/- 20%). Mit

stress --hogdisk 1000m test

werden 1 GByte Daten in die Datei "test" geschrieben. Ansonsten ist das Programm sehr schlicht zu bedienen, die Hilfe-Ausgabe liefert weitere Optionen:

stress 1.16

   usage: stress [flag [arguments]]
   flags: --hogio [n]       (make n sync(2) calls)
          --loadavg [n]     (bring load avg up to n)
          --hogcpu [n]      (make n sqrt(3) calls)
          --hogmemory [n s] (malloc(3) n pages of s bytes)
          --hogdisk [n f]   (fputs(3) n bytes to file f)
   valid number suffixes: k, m, g (i.e. 4k => 4096)

2.3 Performancemessungen im Netz

Es gibt verschiedene Möglichkeiten, die Performance von Netzwerkkomponenten zu ermitteln:

Eine Möglichkeit ist, spezielle Neztwerkmessgeräte (wie zum Beispiel JDSU Smart Class Ethernet oder Acterna HST-3000C) zu werwenden.
Es gibt auch etliche kommerzielle Softwarelösungen, z.B. PRTG von Paessler.
Die hier beschriebene Variante, ist mit einem möglichst geringem finanziellen Aufwand und ohne spezieller Hardware (Netzwerktester) verbunden. Es kommen vielmehr leicht erhältliche Softwaretools zum Einsatz.

Zu berücksichtigen ist ebenfalls, dass die in Datenblättern und Standards genannten Geschwindigkeiten immer Bruttoangaben sind. Die 100 MBit/s bei Fast Ethernet geben die Bitrate auf dem Kabel an. Dabei wird neben den eigentlichen Nutzdaten auch die Verwaltungsinformation eingerechnet.

Die Platzierung der zur Messung herangezogenen PCs sollte so gewählt werden, dass der Standort im Netzwerk den Realbedingungen in etwa entspricht. Das heißt, einer der Mess-PCs sollte im gleichen Netzwerksegment wie die Applikcationsserver (z. B. Webserver) stehen. Der zweite PC ist dann im gleichen Netzwerksegment wie die Anwender-PCs anzuschließen.

Die Bandbreiten und Durchsatzraten können mit Hilfe von Tools wir ping, mtr und iperf ermittelt werden. Bei der Auswertung der Ergebnisse ist zu berücksichtigen, dass bei produktiv genutzten Netzen niemals der Idealwert der Durchsatzrate erreicht werden kann. Werte im Bereich zwischen 65% und 75% des idealen Durchsatzes sind die Regel.

Erste Messungen lassen sich mit dem Standard-Diagnose-Werkzeug ping durchführen. ping schickt kleine ICMP-Pakete (Echorequest) an eine Gegenstelle und zeigt, sofern der Empfänger das Protokoll unterstützt, die Zeit bis zum Eintreffen der Antwort an. Diese entspricht ungefähr der doppelten Latenzzeit. ping ist das Standardprogramm, um die Erreichbarkeit eines Rechners zu testen, es kann aber auch für einfache Performance-Tests verwendet werden. Von einem Test-PC kann ein zweiter Test-PC oder direkt ein im Netzwerk erreichbarer Server "angepingt" werden. Ein möglicher Befehl wäre:

ping -f -c 100 -s 1400 -U IPADRESSE

Mit der Option "-f" wird ein Flood Ping erzeugt, d. h. Die Datenpakete werden mit maximal möglicher Geschwindigkeit gesendet. Es werden 100 Pakete der Paketgröße 1400 Bytes an IPADRESSE geschickt. Das Senden von Flood-Pings ist in der Regel nur dem root-Benutzer gestattet.

Iptraf

Bei Iperf handelt es sich um ein Tool, mit dem der TCP- und UDP-Durchsatz zwischen zwei Rechnern gemessen werden kann. So ist es unter anderem möglich, Schwachstellen im Netzwerk aufzuspüren und das Netzwerk zu optimieren.

Iperf besitzt eine Client-Server-Struktur. Daher ist es möglich, die Performance zwischen zwei Netzwerkhosts zu messen. Dazu muss das Tool auf den zu testenden Hosts, meist Server oder Arbeitsplatz-PCs, installiert werden. Auf dem einen System muss das Tool im Server-Modus gestartet werden, auf dem anderen als Client. Die eigentliche Messung wird vom Client ausgelöst.

Der Iperf-Server lauscht standardmäßig auf Port 5001, der nicht durch ein Firewallsystem blockiert sein darf. Gegebenefalls ist beim Aufruf des Tools ein anderer Port zu wählen (wie im Beispiel unten). Beachten Sie auch, dass Iperf bei einer Messung sehr viel Netzwerk-Traffic erzeugt. Läuft beispielsweise der Test bei einer 100-MBit-Anbindung 10 Sekunden (Defaultwert), werden mehr als 100 MByte an Daten übertragen. Bei einer Gigabit-Anbindung kann in 10 Sekunden sogar ein Traffic von mehr als 1000 MByte entstehen.

Iperf bietet viele Optionen an. So kann man das Format anpassen (KBit, MBit, KByte, MByte) oder das Intervall zwischen den Berichten ändern (Default 10s). Ebenso ist eine Änderung des benutzten Ports oder der TCP-Window-Größe möglich. Die Messung muss auch nicht über TCP erfolgen, sondern kann auch über UDP durchgeführt werden. Darüber hinaus gibt es noch einige weitere spezielle Optionen, über die man sich in der Manual-Page oder per Hilfefunktion (-help) informieren kann.

Im Folgenden wird ein einfaches "Kochrezept" geschildert, das meist ausreicht. An einem Standort ist der Iperf-Server und am anderen der Iperf-Client aufzubauen. Die Platzierung der beiden Systeme im Netzwerk ist so zu wählen, dass es den realen Bedingungen einer Anwendungsverbindung entspricht, um aussagekräftige Messungen zu erreichen. Lässt man parallel zur Messung mit Iperf typisches Anwendungen laufen, die ebenfalls eine Netzwerkverbindung zwischen den beiden Standorten nutzen, erhält man auch ein ungefähres Bild über die durch die Anwendung hervorgerufene Belastung des Netzes. Das Kommando für den Iperf-Server könnte wie folgt aussehen:

iperf -s -p 1111

Damit wird der Port 1111 auf dem Server geöffnet. Das Kommando auf dem Iperf-Client wäre dann zum Beispiel:

iperf -p 1111 -c IPADRESSE_SERVER

Dieser Befehl bewirkt, dass sich der Client mit IPADRESSE_SERVER auf Port 1111 verbindet. Eine mögliche Ausgabe könnte wie folgt aussehen:

# perf -p 1111 -c 1.2.3.4
---------------------------------------------------------------
Client connecting to 1.2.3.4, TCP port 1111
TCP window size: 16.0 KByte (default)
---------------------------------------------------------------
[  3] local 1.2.3.3 port 44634 connected with 1.2.3.4 port 1111
[ ID] Interval Transfer Bandwidth
[  3] 0.010.4 sec 6.84 MBytes 5.53 Mbits/sec
#

Im oben abgebildeten Beispiel wurde eine Bandbreite von 5.53 Mbit/sec ermittelt. Per Default arbeitet Iperf mit einem recht kleinen TCP-Window. Um näher an das theoretische Maximum eines Netzwerkes zu kommen, sollte bei schnelleren Netzen ein größeres TCP-Window eingestellt werden (z. B. -w 512k für ein 512-KByte-Window). Ebenfalls interessant ist die Möglichkeit, mehrere Client-Threads über die Option -P parallel zu starten und so den Verkehr einer stark belasteten Verbindung zu simulieren.

Die folgende Tabelle zeigt einige Iperf-Messwerte aus der Praxis. Gemessen wurde an einem alten 10-MBit-Ethernet-Hub, einem 100-MBit-Switch und einem Gigabit-Ethernet. Iperf wurde zuerst ohne weitere Optionen gestartet und dann mit dem Kommando iperf -c 192.168.0.20 -w 512k -l 512k:

Netzwerk	Iperf ohne Opt.	Iperf mit Opt.	theoret. Wert
10-Mbit-Hub	7,5	7,5	10
100-Mbit-Ethernet	95	95	100
Gigabit	Ethernet	346	948	1000

Die Werte des Hubs ergeben sich durch die entstehenden Kollisionen auf einem Shared Media, höhere Werte sind kaum möglich.
Beim 100-MBit-Ethernet wurde problemlos eine Auslastung von 95% erreicht.
Bei Gigabit-Ethernet macht sich die Defaulteinstellung der TCP-Window-Größe stark bemerkbar. Mit einem entsprechend großen Fenster ist aber auch hier eine Auslastung von fast 95% erreichbar.

Weiterführende Informationen finden Sie auf der IPerf-Homepage.

Das Tool netio, das unter www.ars.de/netio/ beheimatet ist, leistet ähnliche Dienste wie Iperf. Auch hier gibt es Server und Client, die in einem Programm integriert sind.

mtr

Das Tool mtr kombiniert die Funktionalität von ping und traceroute recht übersichtlich (mtr = "my traceroute"). Um Netzwerkprobleme auf die Spur zu kommen, testet man als erstes die Erreichbarkeit des entfernten Systems mittels ping. Ist das System erreichbar, zeigt aber schlechte Antwortzeiten, so sollte man den Weg der Daten nachvollziehen, um zu prüfen wo der Fehler liegt. Hierfür bietet sich das Standardprogramm traceroute an. Hier kommt mtr ins Spiel, das ständig die Ping-Statistik aktualisiert. So können Sie sehen, welche Router langsam antworten oder eine nicht zu vernachlässigende Anzahl von Ping-Anfragen ignorieren. Die Ergebnisse beinhalten den prozentualen Anteil der verlorenen Pakete, die (durchschnittliche, beste, schlechteste) Antwortzeit jedes Routers und die Standardabweichung dieser Zeiten.

mtr prüft Router entlang des Weges zum Zielhost und limitiert dabei die Anzahl der Hops die individuelle Pakete durchlaufen. Dabei analysiert mtr die Antworten der Verfallszeit. Dieser Vorgang wird regelmäßig wiederholt (default 1s) und die Antwortzeit der Hops protokolliert. mtr nutzt dafür ICMP-Echorequests und ermittelt die Daten in Echtzeit. Eine mögliche Ausgabe könnte wie folgt aussehen:

plate@netzmafia:~$ mtr -s 1450 -n -f 3 -c 10 -r www.space.net
HOST: www.netzmafia.de            Loss%   Snt   Last   Avg  Best  Wrst StDev
  3. 129.187.0.137                 0.0%    10    0.7   2.6   0.6  18.1   5.5
  4. 129.187.0.133                 0.0%    10    1.1   1.1   0.9   2.1   0.4
  5. 188.1.37.89                  10.0%    10    0.9   1.0   0.9   1.2   0.1
  6. 188.1.144.110                 0.0%    10    2.5   2.5   2.4   2.9   0.1
  7. 188.1.144.149                 0.0%    10    6.4   6.6   6.3   8.3   0.6
  8. 188.1.145.234                 0.0%    10   17.2  17.6  16.4  19.4   1.2
  9. 80.81.193.105                10.0%    10   21.0  21.1  20.8  21.7   0.3
 10. 195.30.3.113                  0.0%    10   27.4  28.6  26.9  39.9   4.0
 11. 195.30.3.217                  0.0%    10   28.3  46.6  27.8 152.5  41.3
 12. 195.30.3.234                  0.0%    10   27.7  27.6  27.2  27.9   0.2
 13. 194.97.129.8                  0.0%    10   27.8  27.6  27.2  28.3   0.4

Loss: zeigt die Prozent der verlorenen Datenpakete an
Snt: ist die Anzahl der gesendeten Datenpakete
Last: gibt die Antwort des zuletzt versendeten Datenpaketes aus
Avg: ist der Wert der durchschnittlichen Antwortzeit
Best: ist der Wert der besten Antwortzeit
Wrst: ist der Wert der schlechtesten Antwortzeit

Beachten Sie auch, dass sich im WAN unter Umständen die Route der Datenpakete ändern kann, wodurch sich auch der Weg des Datenpaketes durch das Netzwerk verlängert und ein höherer Wert für die Antwortzeit ausgegeben wird. Weitere Informationen liefert die Manualpage von mtr und die MTR Homepage.

Bing

Iperf konnte eine Aussage zur gerade realisierten Bandbreite auf einer bestimmten Verbindung machen. Ohne Client-Server-System lässt sich die ungefähre Bandbreite einer Verbindung mit dem Werkzeug Bing messen. Die Namensabwandlung von "ping" ist dabei gewollt. Während Ping sich um die Erreichbarkeit eines Systems kümmert und Paketlaufzeiten misst, dient Bing der Ermittlung der realisierbaren Bandbreite eines Links. Bing nutzt dazu zwei verschiedene Paketgrössen, um ein etwas realitätsnäheres Ergebnis zu bekommen. Ein möglicher Kommandoaufruf ist:

plate@netzmafia:~$ bing -e 10 -S 1450 -s 100 localhost www.space.net
BING    localhost (127.0.0.1) and www.space.net (194.97.129.8)
        100 and 1450 data bytes (21600 bits)
www.space.net: 136.709Mbps 0.158ms 0.007315us/bit
www.space.net: 127.059Mbps 0.170ms 0.007870us/bit
www.space.net: 43.028Mbps 0.502ms 0.023241us/bit
www.space.net: 32.000Mbps 0.675ms 0.031250us/bit
www.space.net: 32.095Mbps 0.673ms 0.031157us/bit
www.space.net: 32.095Mbps 0.673ms 0.031157us/bit

--- localhost statistics ---
bytes   out    in   dup  loss   rtt (ms): min       avg       max   std dev
  100    10    10          0%           0.016     0.023     0.054     0.011
 1450    10    10          0%           0.018     0.019     0.020     0.001

--- www.space.net statistics ---
bytes   out    in   dup  loss   rtt (ms): min       avg       max   std dev
  100    10    10          0%          26.807    27.377    28.309     0.503
 1450    10    10          0%          27.482    28.178    28.951     0.548

--- estimated link characteristics ---
host                              bandwidth       ms
www.space.net                       32.095Mbps      26.791

Im Beispiel sorgt die Option "-e 10" für entsprechend viele Testläufe. Mit "-s 100" legt man die kleinen Testpakete auf 100 Byte fest und mit "-S 1450" die grossen Pakete auf 1450 Byte. Mehrere Aufrufe erbringen durchaus verschiedene Ergebnisse. Zum Schluss werden die beiden Hosts angegeben, zwischen denen eine Verbindung gemessen werden soll. Dabei muss die Maschine auf der bing gestartet wird nicht unbedingt einer der beiden Testendpunkte sein. Das Ergebnis von Bing hängt von einer ganzen Reihe von Faktoren ab. Die Hardware des Rechners und der Ethernetkarte spielen ebenso wie Treibergüte und Maschinenbelastung ins Ergebnis hinein. Näheres erfährt man aus der bing-Manualpage und von der Entwickler-Website.

nuttcp

Mit dem Programm nuttcp kann man die Transferrate für TCP, UDP und UDP-Multicast messen. Da es seine Daten aus dem Arbeitsspeicher heraus über das Netzwerk sendet, wird nur die Zeit gemessen, die zum Ausführen des Netzwerkcodes im Kernel benötigt wird. Zusätzlich zu den Transferraten gibt das Programm auch die benötigte CPU-Zeit aus. nuttcp basiert auf nttcp von Silicon Graphics, das seinerseits eine Weiterentwicklung von ttcp (Mike Muuss, Berkeley 1984) ist.

nuttcp funktioniert nach dem Client-Server-Prinzip und ist in den Repositories von Debian und in den FreeBSD-Ports vorhanden. Wie bei nttcp gibt es neben dem Sender- und Empfängermodus einen Servermodus, in dem Senden und Empfangen möglich sind. Dieser ist insbesondere beim Aufruf via inetd nützlich (beim Start über inetd entfällt auch der Login auf dem fernen Rechner). Die Ergebnisse werden beim Client angezeigt. Eine Besonderheit von nuttcp ist, dass es ausser dem memory-to-memory-Transfer auch disk-to-memory, memory-to-disk und disk-to-disk messen kann. Damit lassen sich Szenarien messen, die realistischen Einsatzgebieten näher kommen.

Auf dem Server wird nuttcp mit dem Parameter -S ("Server") gestartet. Bei bedarf kann mit dem Parameter -P noch ein Port angegeben werden (bei älteren Versionen ab 5000, bei neueren ab 1024). Wird nuttcp als Server gestartet, forkt es automatisch in den Hintergrund und verbleibt dort bis ein Fehler auftritt, oder der Prozess beendet wird. Dies kann man mit dem Parameter –nofork unterbinden. Zum Beispiel:

root@server# nuttcp -S

Auf dem Client wird nuttcp mit der IP-Adresse oder dem Domainnamen des Servers als Parameter gestartet. Es dauert standardmäßig 10 Sekunden, bis der Test zuende ist. Erst dann sieht man eine Ausgabe. Zum Beispiel:

root@client# nuttcp 192.168.1.23
  113.0118 MB /  10.07 sec =   94.1244 Mbps 1 %TX 22 %RX 0 retrans 0.15 msRTT

Die Messung liefert:

Wie viele Daten gesendet wurden: 113.0118 MB
Der durchschnittliche Datendurchsatz: 94.1244 Mbps
CPU Auslastung des Servers: 1 %RX
CPU Auslastung des Clients: 22 %TX
Anzahl der Paketwiederholungen: 0 retrans
Rount Trip Time: 0.15 msRTT

Mit dem Parameter -i n für "Berichte jede n Sekunden" kann das Ausgabeintervall eingestellt werden und mit dem Parameter -T lässt sich die Testzeit verlängern. Werden Server und Client jeweils mit dem Parameter -xt gestartet, wird zusätzlich ein automatisches Traceroute ausgeführt. Der Parameter -r erlaubt einen Test in Gegenrichtung. Alle Parameter werden gelistet, wenn man nuttcp ohne Parameter aufruf. Natürlich gibt es auch eine Manualseite. Zum Beispiel:

root@client# nuttcp -i1 192.168.1.23
   11.1875 MB /   1.00 sec =   93.8425 Mbps     0 retrans
   11.2500 MB /   1.00 sec =   94.3728 Mbps     0 retrans
   11.1875 MB /   1.00 sec =   93.8493 Mbps     0 retrans
   11.2500 MB /   1.00 sec =   94.3726 Mbps     0 retrans
   11.1875 MB /   1.00 sec =   93.8418 Mbps     0 retrans
   11.2500 MB /   1.00 sec =   94.3764 Mbps     0 retrans
   11.1875 MB /   1.00 sec =   93.8429 Mbps     0 retrans
   10.9375 MB /   1.00 sec =   91.7516 Mbps     0 retrans
   11.5000 MB /   1.00 sec =   96.4709 Mbps     0 retrans
   11.2500 MB /   1.00 sec =   94.3690 Mbps     0 retrans

  112.8125 MB /  10.06 sec =   94.1159 Mbps 1 %TX 23 %RX 0 retrans 0.16 msRTT


root@client# nuttcp -r -i1 192.168.1.23

   11.1250 MB /   1.00 sec =   93.3215 Mbps     0 retrans
   11.1875 MB /   1.00 sec =   93.8476 Mbps     0 retrans
   11.1250 MB /   1.00 sec =   93.3230 Mbps     0 retrans
   11.1875 MB /   1.00 sec =   93.8477 Mbps     0 retrans
   11.1250 MB /   1.00 sec =   93.3234 Mbps     0 retrans
   11.1875 MB /   1.00 sec =   93.8478 Mbps     0 retrans
   11.1250 MB /   1.00 sec =   93.3224 Mbps     0 retrans
   11.1875 MB /   1.00 sec =   93.8480 Mbps     0 retrans
   11.1875 MB /   1.00 sec =   93.8477 Mbps     0 retrans
   11.1250 MB /   1.00 sec =   93.3230 Mbps     0 retrans

  112.0048 MB /  10.04 sec =   93.6184 Mbps 5 %TX 5 %RX 0 retrans 0.21 msRTT

Mit dem Parameter -u kann man auch UDP-Verbindungen testen.

root@client# nuttcp -u -i1 -T5 192.168.1.23
    0.1191 MB /   1.00 sec =    0.9994 Mbps     0 /   122 ~drop/pkt  0.00 ~%loss
    0.1191 MB /   1.00 sec =    0.9994 Mbps     0 /   122 ~drop/pkt  0.00 ~%loss
    0.1191 MB /   1.00 sec =    0.9994 Mbps     0 /   122 ~drop/pkt  0.00 ~%loss
    0.1191 MB /   1.00 sec =    0.9994 Mbps     0 /   122 ~drop/pkt  0.00 ~%loss
    0.1191 MB /   1.00 sec =    0.9994 Mbps     0 /   122 ~drop/pkt  0.00 ~%loss

    0.5967 MB /   5.01 sec =    0.9999 Mbps 100 %TX 0 %RX 0 / 611 drop/pkt 0.00 %loss

Der Parameter -w "size" ermöglicht das Setzen der Puffergröße ("window"), beispielsweise setzt -w8m den Puffer auf 8 Megabyte. Auf die gleiche Weise kann mittels -l "size" die UDP Paketgröße bzw. die TCP write size gesetzt werden, z. B.: -l512. Nicht zuletzt kann mit -R die Datenrate (in bps) festgelegt werden, z. B.: -R10m für 10 MBit/s. Seit Version 6.2.8 gibt es für UDP auch noch einen "burst mode", den man bei -R zusätzlich angibt, zum Beispiel: Sende UDP-Pakete mit 300 Mbps in Bursts von 20 Paketen:

root@client# nuttcp -u -R300m/20 -i1 -T5 192.168.1.23
    0.0352 MB /   1.00 sec =    0.2949 Mbps     0 /    36 ~drop/pkt  0.00 ~%loss
    0.0361 MB /   1.00 sec =    0.3031 Mbps     0 /    37 ~drop/pkt  0.00 ~%loss
    0.0352 MB /   1.00 sec =    0.2949 Mbps     0 /    36 ~drop/pkt  0.00 ~%loss
    0.0361 MB /   1.00 sec =    0.3031 Mbps     0 /    37 ~drop/pkt  0.00 ~%loss
    0.0361 MB /   1.00 sec =    0.3031 Mbps     0 /    37 ~drop/pkt  0.00 ~%loss

    0.1797 MB /   5.03 sec =    0.3000 Mbps 100 %TX 0 %RX 0 / 184 drop/pkt 0.00 %loss

Der folgende Vergleich zeigt, was bei Verkleinern der Fenstergröße geschieht:


root@client# nuttcp -i1 -T5 192.168.1.23
   11.1875 MB /   1.00 sec =   93.8433 Mbps     0 retrans
   11.1875 MB /   1.00 sec =   93.8479 Mbps     0 retrans
   11.2500 MB /   1.00 sec =   94.3727 Mbps     0 retrans
   11.1875 MB /   1.00 sec =   93.8457 Mbps     0 retrans
   11.2500 MB /   1.00 sec =   94.3721 Mbps     0 retrans

   56.5000 MB /   5.04 sec =   94.0850 Mbps 1 %TX 22 %RX 0 retrans 0.17 msRTT
   
root@client# nuttcp -w1k -i1 -T5 192.168.1.23
    3.5000 MB /   1.00 sec =   29.3589 Mbps     0 retrans
    3.5000 MB /   1.00 sec =   29.3604 Mbps     0 retrans
    3.5625 MB /   1.00 sec =   29.8850 Mbps     0 retrans
    3.5000 MB /   1.00 sec =   29.3597 Mbps     0 retrans
    3.5625 MB /   1.00 sec =   29.8831 Mbps     0 retrans

   17.6537 MB /   5.00 sec =   29.6094 Mbps 2 %TX 13 %RX 0 retrans 0.17 msRTT

Anmerkungen zur Bewertung der gemessenen Werte

Alle oben beschriebenen Programme liefern einen "Schnappschuss" der augenblicklichen Situation, der von vielen Dingen beeinflusst werden kann, darunter die Netzbelastung insgesamt oder die augenblickliche Belastung des zum Test eingesetzten Rechners. Daher lohnt es sich, einerseits mehrere Messungen nacheinander durchzuführen und andererseits zu verschiedenen Tageszeiten zu messen.

Wie schon erwähnt, wird bei den in Datenblättern und Standards genannten Geschwindigkeiten immer neben den eigentlichen Nutzdaten auch die Verwaltungsinformation eingerechnet, etwa der Header, die Preamble, die Prüfsumme (CRC) und sogar die Lücke zwischen den Frames (Inter Frame Gap, IFG). Bei der Suche nach Performanceproblemen sollte man sich daher bewusst sein, welche Übertragungsraten von welchem Medium zu erwarten sind. Dies sind keinesfalls die theoretischen Maximalwerte für eine bestimmte Technik.

In der Praxis werden diese Werte nur selten erreicht. Neben der Bandbreite einer Verbindung spielt das verwendete Protokoll eine wichtige Rolle. So erzeugt beispielsweise FTP einen geringen Overhead, bei NFS ist er schon größer, und SMB hat einen relative großen Overhead. So können die mit den oben genannten Tools ermittelten Werte dazu verwendet werden, die Netzwerkverbindung auf Funktionalität zu testen. Applikationen werden diese Werte meist nicht erreichen. Gründe hierfür sind unter anderem: Beim Kopieren von Daten zwischen lokaler und entfernter Festplatte müssen Daten im Dateisystem geschrieben bzw. gelesen werden, was zumindest bei Gigabitnetzen oft langsamer ist als der theoretisch mögliche Wert des Netzwerkes. Insbesondere das Kopieren kleiner Dateien ist bei vielen Dateisystemen relativ langsam.

Applikationen verwenden unterschiedliche Protokolle; der Protokoll-Overhead lässt weniger Payloaddaten zu, schmälert daher die Nettobandbreite. Ein weiterer Overhead durch die Verschlüsselung und Entschlüsselung entsteht bei Daten, die über einen VPN-Tunnel oder anders verschlüsselte Protokolle transportiert werden.

Als Beispiel für den netzwerkunabhängigen Overhead diene ein einfacher Test: es wird eine 1 GByte große Datei (im GBit-Netz) per Secure Copy (scp) auf einen entfernten Server übertragen. Es zeigt sich eine Übertragungsrate von 65.1 MByte/s. Gegenüber dem mittels Iperf ermittelten Wert von ca. 116 MByte/s (925 MBit/s) zeigt sich der durch das Betriebssystem, die Verschlüsselung und die Geschwindigkeitsbegrenzung der Festplatten erzeugte Geschwindigkeitsverlust.

Bei Wireless LAN ist Differenz zwischen der vom Hersteller angegeben Übertragungsrate und dem Nettowert sehr groß. Von den 11 MBit/s des Standards IEEE 802.11b bleiben beispielsweise für den Nutzer nur ca. 5 MBit/s übrig. Bei IEEE 802.11g und 802.11a beträgt die Bruttodatenrate 54 MBit/s. Unter idealen Bedingungen werden damit maximal 25 MBit/s netto übertragen. Bei unzureichender Signalstärke verringern viele Access Points die Geschwindigkeit auf bis zu 1 Mbit/s.