 |
Lastmessung (Benchmarks)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. Softwarekomponentenzugeschnitten. 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 WebserverbenchmarkingBei 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, xDSL und hohe Netzlast).
Bei real existierenden Webservern spielt im Allgemeinen die Stabilität und Sicherheit
eine höhere Rolle als die Performance des Systems. Die Stabilität läßt sich nur schwer
messen, jedoch zeigt eine c't-Analyse zur Verfügbarkeit von Web-Servern, dass NT-Server
deutlich mehr und auch längere Ausfallzeiten aufwiesen als Unix-Systeme.i
Die Website www.attrition.org
führt zu Dokumentationszwecken alle durch Hacker verunstalteten Webseiten, die den
Betreibern bekannt werden. Außerdem führen sie eine Statistik über die betroffenen
Betriebssysteme. In dieser nimmt Windows NT mit rund zwei Dritteln aller Vorfälle
einen Spitzenplatz ein.
Tests diverser Computerzeitschriften haben ergeben, daß Linux unabhängig
von der Art der Systemlast mindestens so gut wie Windows 2000, bei Datenbankabfragen
teilweise sogar besser skaliert. Bei der Erstellung dynamischer Webseiten skalieren
beide Systeme mit der Zahl der CPUs. Bei bis zu vier CPUs wächst
die Systemleistung linear an, allerdings nur, solange nicht andere Faktoren, wie
die Bandbreite der Netzanbindung die Grenze für die Leistung bilden.
Bei beiden Betriebssystemen zeigt sich jedoch dann auch, dass bei einer Erweiterung
auf mehr als vier CPUs die Ergebnisse nicht mehr linear anwachsen.
Artikel dazu:
- Jürgen Schmidt: Gemischtes Doppel; Linux und NT als Web-Server im Test;
c't 13/99, S. 186
- Jürgen Schmidt: Dasein oder Nicht-Dasein, Analyse der Ausfallzeiten von
Web-Servern, c't 8/00, S. 174
- Jürgen Schmidt: Server im Wettstreit; Windows 2000 und Linux 2.4
im Test als Web-Server, c't 17/00, Seite 174
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.
Webserver-(Apache-) Tuning-Tipps
Nicht nur Hardware und Betriebssystem spielen eine Rolle beim "Tunen" eines Server-Rechners.
Auch bei der Software kann einiges den Durchsatz beschleunigen. Zuerst werden alle
Prozesse entfernt, die nicht unbedingt notwendig sind. Insbesondere braucht ein
Serversystem keine speicherfressende grafische Benutzeroberfläche und keine
"normalen" Useraccounts. Es versteht sich auch von selbst, daß immer die neueste
Version des Servrprogramms verwendet wird - nicht nur wegen der Performance, sondern
auch aus Sicherheitsgründen.
Der Apache-Webserver ist wenig anfällig gegen Betriebsstörungen
gleich welcher Art. Er Server besteht aus einem Managerprozeß, der
eine Reihe von Bearbeiterprozessen startet (preforking).
Eingehende Requests werden vom Master registriert und an einen
freien Bearbeiter weitergereicht. Wenn der Bearbeiter mit der Ausführung
des Requests fertig ist, beendet er sich nicht, sondern meldet
sich beim Manager zurück, und dieser teilt dem Bearbeiter den
nächsten Request zu.
Ein Bearbeitungsprozeß ist oftmals nicht in der Lage, einen
Prozessor voll auszulasten: Er muß auf das Eintreffen von Daten
von der Festplatte warten, oder er muß auf den Client auf der
anderen Seite des Netzes warten und sich mit der Abarbeitung des
Requests nach der Übertragungsgeschwindigkeit des Netzes
richten. Damit während dieser Zeit andere Requests bearbeitet
werden können, ist es sinnvoll, mehrere Bearbeiterprozesse zu
haben.
Wie viele Bearbeiterprozesse 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
speziell im Fall von Apache ist es so, daß der Webserver in
genau dem Moment sehr viel langsamer wird, in dem die Maschine
anfangen muß, 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 in der httpd.conf 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)
Dann kann noch die Konfiguration und das Umfeld optimieren:
- In der Datei httpd.conf den Wert HostNameLookups auf "off"
setzen, um die Zahl unnötiger DNS-Abfragen zu reduzieren.
- Setzen Sie für die Grafiken auf den Webseiten einen zweiten Server
ein. Dann liefert der eine nur die Texte und der andere die Grafiken und die
Gesamtperformance steigt ohne administrativen Aufwand.
- Bauen Sie sich einen "schlanken" Server, der nur die nötigsten Module
enthält. Dazu muß der Apache neu compiliert werden, nachdem in
.src/Configuration die nicht benötigten Module auskommentiert
wurden.
- Wenn Sie keine Logdateien brauchen, leiten sie die Logs nach /dev/null
um (in httpd.conf).
- Wenn keine geschützten Verzeichnisse benötigt werden, setzen Sie
global AllowOverride None. Dann kümmert sich der Apache nicht mehr
um die .htaccess-Dateien.
- Es versteht sich von selbst, daß die Web-Daten und Logdateine auf einer
lokalen Platte liegen und nicht etwa per NFS geliefert werden.
- Apache sollte auch immer "standalone" laufen und nicht über inetd
oder einen TCP-Wrapper gestartet werden.
- Vermeiden Sie Server Side Includes (SSI).
- Bei CGI-Skripten:
- So wenig Dateioperationen wie möglich. Dateien sauber öffnen
und schließen.
- Fest geblockte Daten mit read/write lesen/schreiben geht schneller als
zeichenweise Operationen und erlauben wahlfreien Zugriff.
- Vermeiden Sie Aufrufe von fremden Programmen (Shellprozesse). Wenn unbedingt
nötig, nur mit vollem Pfad aufrufen.
- Verwenden Sie mod_perl anstelle des Standard-Perl-Interpreters.
- Stukturieren Sie das Webangebot in Unterverzeichnisse, um den Zugriff auf die
Dateien zu beschleunigen.
- Zum Testen von Netzwerkverbindungen eignet sich das kleine Tool
tcpblast, das als Quelle vorliegt.
Interessanter ist hier Hammerhead 2, das unter
http://hammerhead.sourceforge.net/
heruntergeladen werden kann. Dieses Tool ist einfach konfigurierbar (Datei
/etc/hammerhead/hh.conf bearbeiten). Hammerhead 2 kann mehrere Verbindungen
gleichzeitig öffnen und dabei auch Anfrangen von verschiedenen IP-Aliasen und bis zu
256 verschiedenen Usern generieren. Nach der voreingestellten Testzeit liefert das Tool
einen aussagekräftigen Report. Neben Anzahl der Threads, Timeout-Schwellen, Test-Zeit,
Usern lassen sich noch viele weitere Parameter einstellen. Man kann sogar Erwartungswerte
für Ergebnisse eingeben, die dann mit den realen Resultaten verglichen werden.
Hammerhead 2 wartet bei jedem Request auf Antwort vom Server. Ist der Server
schlecht angebunden, kann es vorkommen, daß die voreingestellte Request-Rate
unterschritten wird. Auch kann das Programm nur so schnell arbeiten, wie der Computer
auf dem es Läuft die Netzwerkanforderungen bedient.
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).
Aber 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)
|
|
|
DIENSTE
