SUCHE MIT Google
Web virtualuniversity.ch
HOME DIDAKTIK ECDL ELEKTRONIK GUIDES HR MANAGEMENT MATHEMATIK SOFTWARE TELEKOM
DIENSTE
Anmeldung
Newsletter abonnieren
Sag's einem Freund!
VirtualUniversity als Startseite
Zu den Favoriten hinzufügen
Feedback Formular
e-Learning für Lehrer
Spenden
Autoren login
KURSE SUCHEN
Kurse veröffentlichen

Suche nach Datum:

Suche mit Schlüsselwort:

Suche nach Land:

Suche nach Kategorie:
PARTNER
ausbildung24.ch - Ausbildungsportal, Seminare, Kursen... 

 
HTMLopen.de - Alles was ein Webmaster braucht

 
PCopen.de - PC LAN Netze und Netzwerke - alles was ein IT Profi und Systemtechnicker braucht

TELEKOM

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 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, 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)
                                       

DIPLOMARBEITEN UND BÜCHER

Diplomarbeiten zum Runterladen:

Suche im Katalog:
Architektur / Raumplanung
Betriebswirtschaft - Funktional
Erziehungswissenschaften
Geowissenschaften
Geschichtswissenschaften
Informatik
Kulturwissenschaften
Medien- und Kommunikationswissenschaften
Medizin
Psychologie
Physik
Rechtswissenschaft
Soziale Arbeit
Sozialwissenschaften


JOBS
HOME | E-LEARNING | SITEMAP | LOGIN AUTOREN | SUPPORT | FAQ | KONTAKT | IMPRESSUM
Virtual University in: Italiano - Français - English - Español
VirtualUniversity, WEB-SET Interactive GmbH, www.web-set.com, 6301 Zug

Partner:   Seminare7.de - PCopen.de - HTMLopen.de - WEB-SET.com - YesMMS.com - Ausbildung24.ch - Manager24.ch - Job und Karriere