Tag Archive for 'Serie'

Serie NSClient++ – Teil 4: Eventlog und weiteres!

Teil 4 von 4 in der Blogserie NSClient++

Im vierten Teil der NSClient++ Serie geht es um die Überwachung des Windows Eventlogs und weitere kleine Features des NSClients wie z.B. check_multiple.

Die Prüfung des Windows Eventlogs kann über mehrere Wege stattfinden.
In unserer Serie erfolgt die Prüfung über CheckEventlog und die dazugehörige Filtersprache, durch Angabe verschiedener Filter sind auch hier komplexe Abfragen möglich. Beispielsweise kann mit folgender Abfrage auf vorkommen von Fehlermeldungen (nicht success) innerhalb des Systemlogs geprüft werden die einen Tag alt sind und von einem Service erzeugt wurden. Eine CRITICAL Meldung wird in diesem Fall ab dem ersten Treffer erzeugt.

$ ./check_nrpe -H srv-ts.int.netways.de -p 5666 -c CheckEventLog -a file=system filter=new filter=out filter-eventType==success filter+eventSource=substr:Service 'filter-generated=>1d' MaxCrit=1

Dabei wird ausgegeben welche Services den Fehler verursacht haben, zur genaueren Diagnose sollte dann das Eventlog herangezogen werden.
Die Ausgabe kann je nach Gusto noch mit verschiedenen Parametern angereichert werden. Zu finden ist die Dokumentation der Filtersprache unter http://www.nsclient.org/nscp/wiki/CheckEventLog/CheckEventLog

Ein weiterer interessanter Check des NSClients ist im Modul CheckHelpers enthalten. Das Kommando CheckMultiple ermöglicht es ähnlich zu check_multi unter Linux/Unix in einem Connect mehrere Abfragen auszuführen. CheckMultiple erwartet als Argumente die auszuführenden Checks, um Beispielsweise die Festplattenauslastung sowohl auf prozentualer als auch auf absoluter Basis zu messen kann beispielsweise dieses Kommando verwendet werden:

$ ./check_nrpe -H srv-ts.int.netways.de -p 5666 -c CheckMultiple -a command=CheckDriveSize Drive=c MaxWarnUsed=80% MaxCritUsed=95% ShowAll=long command=CheckDriveSize Drive=c MinWarnFree=2G MinCritFree=1G ShowAll=long
WARNING: c:: Total: 40G - Used: 36G (90%) - Free: 3.99G (10%) > warning, OK: c:: Total: 40G - Used: 36G (90%) - Free: 3.99G (10%)|'c:'=90%;80;95; 'c:'=36.00G;37.99;38.99;

Die Verknüpfung der von CheckMultiple ausgeführten Prüfungen ist immer oder, d.h. der schlechteste Status der ausgeführten Subprüfungen wird immer in das Ergebniss übernommen. In unserem Testfall ist die Prüfung also ein WARNING Status. Die Textuelle Ausgabe der beiden Prüfungen wird ausschließlich bei den Performancedaten kombiniert, so bleibt jede Information der eigentlichen Prüfungen erhalten.

share save 171 16 Serie NSClient++ – Teil 4: Eventlog und weiteres!

Serie NSClient++ – Teil 3: Basisüberwachung

Teil 3 von 4 in der Blogserie NSClient++

Nachdem in Teil eins und zwei der Blogserie über den NSClient++ die Grundlagen und Installation durchgeführt wurden kann es nun ans Überwachen der ersten Komponenten gehen. Ziel dieses Teils ist es eine Basisüberwachung des Betriebssystems abzudecken, daraus ableiten lässt sich dann auch eine erweiterte Überwachung diverser Dienste, Festplattten oder Prozesse.

Die Kommunikation hin zum Client erfolgt über das Plugin check_nrpe, wichtig hierbei ist NRPE mit aktivierten Kommandoargumenten übersetzt zu haben. Die benötigte Option hierfür heißt “–enable-command-args” und muss zur Kompilezeit angegeben werden.

Generell funktionieren die verschiedenen Abfragen ähnlich, einzig das auszuführende Kommando (Parameter “-c”) und die dazugehörigen Argumente (Parameter “-a” für check_nrpe) unterscheiden sich je nach Prüfung.

Ein Beispielhafter Aufruf für die Prüfung der CPU Auslastung über einen Zeitraum von 5 Minuten sieht wie folgt aus:

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckCPU -a warn=80% crit=95% time=5m ShowAll=long

Sieht das Ergebnis wie gewünscht aus können wir uns den weiteren Checks widmen. Als Basisüberwachung werden folgende Prüfungen auf jedem Windowssystem eingerichtet:

  • CPU Auslastung (80% Warning, 95% Critical, 5 Minuten Messintervall)
  • Festplattenauslastung (80% Warning, 95% Critical)
  • Speicherauslastung (70% Warning 85% Critical)
  • Uptime
  • Server Dienst

Die Kommandozeilen für die genannten Prüfungen:

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckCPU -a warn=80% crit=95% time=5m ShowAll=long
OK: 5m: average load 1%|'5m'=1%;80;95;

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckDriveSize -a Drive=c MaxWarnUsed=80% MaxCritUsed=95% ShowAll=long
OK: c:: Total: 40G - Used: 24.6G (61%) - Free: 15.4G (39%)|'c:'=61%;80;95;

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckMEM -a MaxWarn=70% MaxCrit=85% type=physical ShowAll=long
OK: physical memory: Total: 2G - Used: 840M (41%) - Free: 1.18G (59%)|'physical memory'=41%;70;85;

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckUpTime -a ShowAll=long
OK: uptime: 0:13

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckServiceState -a Server
OK: All services are in their apropriate state.

Funktionieren diese Abfragen können dazu noch passende Nagios bzw. Icinga Kommandos definiert werden:

define command {
        command_name    check_win_load
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckCPU -a warn=$ARG1$ crit=$ARG2$ time=$ARG3$ ShowAll=long
}

define command {
        command_name    check_win_drive
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckDriveSize -a Drive=$ARG1$ MaxWarnUsed=$ARG2$ MaxCritUsed=$ARG3$ ShowAll=long
}

define command {
        command_name    check_win_mem
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckMEM -a MaxWarn=$ARG1$ MaxCrit=$ARG2$ type=physical ShowAll=long
}

define command {
        command_name    check_win_uptime
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckUpTime -a ShowAll=long
}

define command {
        command_name    check_win_service
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckServiceState -a $ARG1$
}
share save 171 16 Serie NSClient++ – Teil 3: Basisüberwachung

Serie NSClient++ – Teil 2: Installation

Teil 2 von 4 in der Blogserie NSClient++

Für die Installation des NSClient++ zur Windowsüberwachung gibt es generell zwei Möglichkeiten.

Variante eins ist die Installation auf Basis von zum Download bereitstehenden MSI Paketen. Bei dieser Installationsweise werden während des Installationsvorgangs die benötigten Parameter abgefragt.

Bei der zweiten Installationsvariante wird das ZIP Archiv heruntergeladen und auf die Systeme ausgerollt. Vorab sollte allerdings eine Anpassung der globalen Konfigurationsdatei “nsc.ini” erfolgen um die gewünschten Parameter zu setzen. Danach kann dieses Archiv einfach auf beliebig viele Rechner verteilt werden, wobei nach Entpacken des Archives manuell der Windows-Dienst registriert und gestartet werden muss.

Die Registrierung und der Start des Dienstes erfolgt in einer Kommandozeile mit den Befehlen:

# nsclientpp.exe -install
# net start nsclientpp

Beiden Installationswegen gemein ist jedoch der automatische Start des “nsclientpp” genannten Dienstes beim nächsten Neustart des Systems. Wer sich für den manuellen Installationsweg entscheidet muss in der NSC.ini folgende Parameter an die vorhandene Umgebung

Aktivieren der gewünschten Checks in derr [modules] Sektion:

FileLogger.dll
CheckSystem.dll
CheckDisk.dll
NRPEListener.dll
CheckEventLog.dll
CheckHelpers.dll

Durch die Aktivierung der oben genannten DLL’s wird die Funktionalität des NSClient++ bestimmt, eine Erklärung der Funktionen innerhalb der Bibliotheken findet sich in der Dokumentation unter http://www.nsclient.org/nscp/wiki/CheckCommands

Anpassungen im [settings] Abschnitt:

allowed_hosts=<Kommaseparierte IP Adressliste der Monitotingserver>
use_file=1

Die Direktive use_file weist den NSClient an die Konfigurationsdatei anstatt von Registryeinträgen zu verwenden. Bei der Installation wird also lediglich der Dienst registriert, weitere Einstellungen werden nicht in die Windows Registrierung geschrieben.

Zusätzlich müssen noch Kommandoargumente und Sonderzeichen für diese freigeschalten werden, dazu gibt es in der Sektion [NRPE] folgende Parameter die jeweils auf 1 zu setzen sind:

allow_arguments=1
allow_nasty_meta_chars=1

Werden Änderungen an der Konfiguration durchgeführt muss der Dienst durchgestartet werden. Dies erfolgt entweder über den Dienste-Manager oder durch die Kommandozeile:

# net stop nsclientpp
# net start nsclientpp

Ist die Installation und Konfiguration abgeschlossen und der Dienst erfolgreich gestartet kann vom Monitoringserver aus ein erster Test erfolgen:

# /usr/local/nagios/libexec/check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckVersion

Als Antwort des Clients wird hierbei die Versionsnummer der aktuell Installierten NSClient Version zurückgegeben. Sollten hier Fehler auftreten bietet der NSClient die Möglichkeit den Dienst über eine Kommandozeilenoption in den Debugmodus zu schalten und so eventuell auftretenden Fehler zu lokalisieren. Dazu wird als erstes der Dienst gestoppt und der NSClient manuell mit der Option “-test” gestartet.

# net stop nsclientpp
# nsclientpp.exe -test
share save 171 16 Serie NSClient++ – Teil 2: Installation

Serie NSClient++ – Teil 1: Grundlagen

Teil 1 von 4 in der Blogserie NSClient++

nswide Serie NSClient++   Teil 1: GrundlagenZur Überwachung von Windows Servern mit Nagios oder Icinga hat sich mittlerweile der NSClient++ als Agent auf dem System etabliert.

Er bietet die Möglichkeit sowohl per “check_nt” als altes Verfahren und auch mittels NRPE Abfragen auf dem Windows System durchzuführen. Grundsätzlich sind die Abfragen in verschiedene Module gegeliedert, nennenswert an dieser Stelle sind:

  • CheckDisk – prüft die Festplattenauslastung
  • CheckEventLog – prüft Einträge im Eventlog
  • CheckSystem – prüft Prozesse, Dienste, CPU Auslastung, …

sowie

  • CheckHelpers – biete weitergehende Möglichkeiten zur Prüfungsausführung

Jedes dieser genannten Module bietet diverse Sub-Module um Abfragen auszuführen, die Parametrisierung der einzelnen Checks ist hierbei ähnlich.

Im weiterem Verlauf der Blogserie werden die Installation und Konfiguration wie auch diverse Checks und deren Aufruf vorgestellt. Die Kommunikation zum überwachten System findet hierbei ausschließlich per verschlüsseltem NRPE statt.

share save 171 16 Serie NSClient++   Teil 1: Grundlagen

Jasper Reporting – Eine Einführung

Teil 1 von 15 in der Blogserie Jasper Reporting

jaspersoft reporting Jasper Reporting   Eine Einführung

Reporting & Business Intelligence – Ein ungeliebtes Thema?

Gerade der zweite Begriff erklärt schon recht gut, wo eigentlich die Wurzeln dieser Technologien liegen. Natürlich im Business Feld, denn noch vor einigen Jahen wurden mit den entsprechenden Tools hauptsächlich betriebswirtschaftliche Zahlen analysiert und ausgewertet. Also beispielsweise Vertriebszahlen, Umsätze oder Daten aus dem Produktionsbereich. Doch in letzter Zeit sind diese Tools und Werkzeuge auch immer mehr in den IT Bereich eingedrungen. Kein Wunder, denn SLAs, Verfügbarkeitsreports und andere Statistiken, werden ziemlich ähnlich aufbereitet und errechnet.

So haben auch wir uns in den letzten Jahren immer mehr mit dem Thema Reporting beschäftigt. Zuerst natürlich in den Monitoring Projekten: Wo es früher vielleicht noch ausreichend war, einzelne Fachabteilungen hin- und wieder mit einem manuell erstellten Excel Report zu besänftigen, wird heute meistens mehr erwartet. Selbst die internen Kunden einer IT Abteilung wollen heute genau wissen, welche Leistungen erbracht wurden, wie die Hardware ausgelastet war und welche Verfügbarkeiten in der Praxis erreicht wurden. Das lässt sich nur noch sehr schwer manuell ad hoc erstellen. Aber auch unsere Managed Services Kunden wollen immer besser und aktueller informiert werden und bekommen inzwischen von uns jeden Monat eine komplette Übersicht aller Aktivitäten, wie beispielsweise Tickets, Traffic, Domains oder Auslastungswerte.

Schön, dass parallel dazu in den letzten Jahren auch immer mehr Open Source Lösungen, wie Pentaho, Eclipse Birt und Jasper zum Thema Reporting auf den Markt gekommen sind. Einige Möglichkeiten, die diese Programme nun bieten haben wir zum einen schon im letzten Jahr auf unserer Open Source Monitoring Conference und dann auch wieder auf dem Nagios Workshop in Kassel vorgestellt und nun möchten wir unseren Lesern hier im Blog einen Einblick in dieses Thema ermöglichen und einige konkrete Einsatzszenarien auf Basis von Jasper Reporting aufzeigen.

Von der Installation der Serverkomponenten, über die Erzeugung von Reports mit dynamischer Parametrisierung und Darstellung von Informationen in Diagrammen bis hin zur automatischen Versendung der erstellten Reports, soll die Serie Hilfestellung geben und den Einstieg erleichtern. Geplante Themen sind:

  • Installation des Servers
  • Verwendung von iReport
  • Einfach Reports und Design-Tips
  • Statische und dynamische Parameter
  • Gruppierung von Daten
  • Verwendung von Diagramme
  • Anzeige von aktuellen Nagios-Daten
  • SLA-Reporting
  • Automatische Versendung
  • uvm.

Besonders Neugierige können auf unsere Website schon vorab Informationen finden und unter jasper.demo.netways.de einen Blick auf das Demo-System werfen. Wenn Sie keinen Teil dieser Serie verpassen wollen, empfehlen wie Ihnen unseren RSS Feed zu abonnieren oder uns via Twitter zu folgen.

share save 171 16 Jasper Reporting   Eine Einführung

Twitter Development – Zusammenfassung

Teil 10 von 10 in der Blogserie Twitter Development

twitter code Twitter Development   ZusammenfassungIn den letzten Wochen, haben wir den Großteil der vorhandene API-Funktion, welche durch Twitter bereitgestellt werden, angeschnitten. Was mich persönlich begeistert ist die Möglichkeit, sämtliche Objekte des Twitterverse im Gesamtkontext mit Suchen, Replies und Inhalten zu sehen.

Gleichzeitig erklärt die Einfachheit der API auch die massive Anzahl an Twitter-Clients, die am Markt verfügbar sind. Genau dieses Ansatz ist beispielhaft und kann auch anderen Diensten zum Erfolg verhelfen. Auch anderen Diensten wie z.B. Facebook brachte die Möglichkeit der Integration und Anbindung zahllose Entwickler und eine große Community.

Eine vollständige Liste der API-Calls ist im Twitter API Wiki zu finden und wer Zeit und Lust hat kann aufbauend auf den gezeigten Beispielen welche auch hier zum Download bereitstehen einen tieferen Blick hinter Kulissen werfen.

Hier noch mal eine Liste der Blogposts zum Thema:

  • Verbindung mit Twitter aufbauen
  • Informationen über den eigenen User ermitteln
  • Friends und Followers
  • Private und Public Timelines
  • Nachrichten Empfangen und Versenden
  • Replies und Mentions
  • Suche von Tweets
  • Zusammenfassung

Meine nächste Blog Serie ist schon in Arbeit und geht in Richtung Open Source Reporting.

share save 171 16 Twitter Development   Zusammenfassung

Nagios Benachrichtigungen direkt an iPhone pushen

In einem früheren Blogartikel dieser Serie habe ich mich ja schon mit dem Thema beschäftigt, wie man Nagios Benachrichtigungen per Apples Push Mechanismus direkt an ein iPhone übertragen kann. Der damals vorgestellt Lösungsweg erfordert aber den Umweg über einen zwischengeschalteten Mac: Der Nagios Server schickt dabei seine Meldungen per Netzwerk an den dort laufenden Growl Client. Über ein Plugin in Growl werden die Meldungen dann an Prowl, einen ähnlichen Dienst für das iPhone weitergeleitet. Der Nachteil des Macs-in-the-Middle Ansatzes kann aber auch ein Vorteil sein: Man muss sich keine Gedanken über Eskalationen machen. Sitzt man am Rechner, bekommt man seine Meldungen dort lokal angezeigt. Ist man unterwegs und der Mac im idle Mode, werden sie zum iPhone weitergeleitet. Das geht vollautomatisch.

 Nagios Benachrichtigungen direkt an iPhone pushenTrotzdem haben mich viele Leute angeschrieben und gefragt, ob es denn nicht auch einen Weg gibt, die Meldungen direkt an das iPhone zu verschicken, ohne den Mac dazwischen. Entweder weil das natürlich unnötig kompliziert ist oder viel naheliegender, weil sie gar keinen Mac haben. Natürlich geht das auch, denn Prowl stellt eine komplette API zur Kommunikation zur Verfügung, die man auch direkt vom Nagios Server aus ansprechen kann. Dies erfordert aber natürlich wie immer, wenn man einen Provider nutzt, dass der Nagios Server noch ins Internet kommt.

Hier also der komplette Weg, wie man einen direkten Push an das iPhone einrichtet:

  1. Als Service um die Benachrichtigungen zu pushen verwenden wir Prowl. Erstellen Sie sich dort unter “Register” einen persönlichen Account.
  2. Zur einfacheren Authentifizierung von Scripten verwendet Prowl einen API Key. Nach dem Einloggen können Sie diesen Schlüssel im Bereich “Settings” direkt anfordern. Kopieren Sie sich die Zeichenkette aus 40 Buchstaben und Ziffern am besten in die Zwischenablage. Wenn mehrere Personen Prowl Benachrichtigungen bekommen sollen, benötigt jeder einen eigenen Account und damit auch einen eigenen API Key.
  3. Installieren Sie sich die Prowl iPhone Applikation aus dem App Store (kostet einmalig 2,39, danach fallen keine weiteren Kosten mehr an). Nach der Installation müssen Sie auf dem iPhone nur noch Ihren Usernamen und Ihr Passwort angeben. Ob die Software korrekt installiert und konfiguriert wurde können Sie nun auf der Prowl Seite testen: Unter “Add A Notification” kann man aus der Website eine Prowl Testnachricht versenden.
  4. Nun geht es an die eigentliche Konfiguration auf dem Nagios Server. Zuerst laden wir uns das Prowl Perl Script direkt von Prowl herunter, kopieren es auf den Nagios Server und machen es ausführbar. Oder einfacher direkt auf dem Server:
    # cd /usr/lib/nagios/plugins/eventhandlers
    # wget http://prowl.weks.net/static/prowl.pl
    # chmod 755 prowl.pl
  5. Das Script benötigt einige Perl Bibliotheken. Auf einem Debian oder Ubuntu System lassen die sich mit
    aptitude install libwww-perl libcrypt-ssleay-perl

    installieren. Auf anderen Systemen muss man “perl -MCPAN -e shell” bemühen und dann die folgenden Pakete installieren:

    install Crypt::SSLeay
    install LWP::UserAgent
  6. Danach sollte man das Script zumindest einmal manuell testen, um sicherzugehen, dass alle notwendigen Bibliotheken installiert sind und die Kommunikation mit der Prowl API funktioniert:
    ./prowl.pl -apikey="APIKEY_HERE" -application="Nagios" -event="Notification" -notification="Dies ist eine Fehlermeldung"
  7. Nun geht es an die Integration in Nagios. Da der Prowl Account ja userspezifisch ist, sollte man den API Key am besten gleich bei dem passenden Benutzer mitspeichern. Es bietet sich dazu an, eine Custom Variable eines bestehenden oder neuen Kontakts zu benutzen:
    define contact {
    contact_name 			jhein_iPhone
    alias 				Julian Hein
    service_notification_period 	24x7
    host_notification_period 	24x7
    service_notification_options 	w,u,c,r
    host_notification_options 	d,u,r
    service_notification_commands 	notify-service-by-prowl
    host_notification_commands 	notify-host-by-prowl
    _prowl_apikey 			APIKEY_HERE
    }
  8. Als nächstes müssen nur noch die passenden Commands definiert werden:
    define command {
    command_name 	notify-host-by-prowl
    command_line 	$USER2$/prowl.pl -apikey="$_CONTACTPROWL_APIKEY$" -priority=1 -application="Nagios" -event="Host Notification" -notification="$HOSTNAME$ $HOSTSTATE$ '$HOSTOUTPUT$'"
    }
    
    define command {
    command_name 	notify-service-by-prowl
    command_line 	$USER2$/prowl.pl -apikey="$_CONTACTPROWL_APIKEY$" -priority=1 -application="Nagios" -event="Service Notification" -notification="$HOSTNAME$ $SERVICEDESC$ $SERVICESTATE$ '$SERVICEOUTPUT$'"
    
    }

Wichtig ist noch, dass der embedded Perl Interpreter ausgeschaltet ist, den sonst kann das Perl Skript nicht fehlerfrei ausgeführt werden. Dazu gibt es in der nagios.cfg eine entsprechende Direktive. Wird der ePN genutzt, kann man alternativ auch in der Command Definition den normalen Interpreter angeben. Statt “$USER2$/prowl.pl” müsste man dann “/usr/bin/perl -w /usr/lib/nagios/plugins/eventhandlers/prowl.pl” angeben. Nagios Benachrichtigungen direkt an iPhone pushen

Das wars eigentlich schon. Einfacher und günstiger kann man realtime Meldungen kaum auf sein mobiles Gerät senden. Man sollte sich allerdings klar sein, dass das ganze nur funktioniert, solange der Nagios Server sich noch mit dem Prowl Gateway im Internet verbinden kann. Zusätzlich gibt es ein API Limit von aktuell 1.000 Meldungen pro Stunde und natürlich garantiert Prowl keinerleih Verfügbarkeit. Aber das ist bei SMS ja auch nicht anders.

share save 171 16 Nagios Benachrichtigungen direkt an iPhone pushen

Serie High Performance Websites – Zusammenfassung

Teil 6 von 6 in der Blogserie High Performance Websites

serie Serie High Performance Websites   ZusammenfassungZusammenfassung der Serie über High Performance Websites.

In dieser Artikelserie haben wir versucht einen kurzen Einblick in die Optimierung von Server, Sourcecode und Infrastruktur in Bezug auf Performance zu geben.

Für Feedback oder Anregungen sind wir selbstverständlich jederzeit offen und freuen uns über jede Kontaktaufnahme.

share save 171 16 Serie High Performance Websites   Zusammenfassung

Serie High Performance Websites – Teil 5: letztes Feintuning

Teil 5 von 6 in der Blogserie High Performance Websites

high performance serie4 Serie High Performance Websites   Teil 5: letztes FeintuningDieser vorerst finale Teil befasst sich mit den restlichen Serverseitigen Themen Redirects und Keep-Alive. Zusätzlich wird auf DNS und das DNS Cacheverhalten des Browsers eingegangen.

Für die Performance von Webseiten hat DNS ausschließlich beim erstmaligen Aufruf Einfluss. Hier ist zu beachten das der DNS Server ihres ISP typischerweise 10-200 Millisekunden braucht um eine Namensauflösung durchzuführen. Nach der Erstanfrage wird der DNS Eintrag sowohl im Betriebssystem als auch im Browser gecached um erneute Anfragen zu vermeiden. Wie lange der bereits erfragte Eintrag zwischengespeichert wird gibt in erster Linie die TTL (Time-To-Live) in der DNS Zone an, desweiteren ist in den Browsern hinterlegt wie lange der DNS Cache zusätzlich zur TTL Einträge speichern soll. Dies kann bedeuten das trotz bereits abgelaufener TTL ein DNS Eintrag im Browser noch durch den Cache vorgehalten wird.

In Summe kann festgehalten werden das es sinnvoll ist die Verwendung unterschiedlicher Hostnamen auf ein minimum zu reduzieren um die durch DNS Anfragen entstehende Latenz beim erstmaligen Laden der Seite zu reduzieren.

In den vorherigen Kapiteln wurde vieles unternommen um die Ladezeit für den Benutzer so gering wie möglich zu halten. Genau das Gegenteil verursachen leider verwendete Redirects, wird bei der ersten HTTP Anfrage ein Redirect vom Server erwidert folgt daraus ein erneuter (also zusätzlicher) HTTP Request. Dieses Verhalten verzögert das Laden der eigentlichen Seite und sollte vermieden werden.

Ziel ist also Redirects wenn möglich zu verhindern oder sehr eingeschränkt zu verwenden.

Zur weiteren Optimierung sollte Keep-Alive serverseitig aktiviert werden, hier werden vom Browser bereits offene TCP Verbindungen für einen definierten Zeitraum wiederverwendet. Dieser Mechanismus spart zusätzlich Zeit für den eigentlichen TCP Verbindungsaufbau. Der Server und Browser signalisieren beim initiieren der Verbindung im “Connection” Header ob Keep-Alive Verbindungen erlaubt sind. Zusätzlich zu Keep-Alive wird unter HTTP/1.1 Pipelining zur Verfügung gestellt um die Verbindungsgeschwindigkeit zu erhöhen. Hier werden mehrere Anfragen über einen Socket übermittelt ohne vorher auf eine Antwort des Servers warten zu müssen.

In Apache wird Keep-Alive durch die folgenden Direktiven aktiviert.

Keep-Alive on

share save 171 16 Serie High Performance Websites   Teil 5: letztes Feintuning

Serie High Performance Websites – Teil 4: Weniger ist Mehr !

Teil 4 von 6 in der Blogserie High Performance Websites

high performance serie3 Serie High Performance Websites   Teil 4: Weniger ist Mehr !Ein weiterer wichtiger Punkt bei der Optimierung ist das Thema Kompression, hierbei werden sämtliche noch komprimierbaren Inhalte (HTML, CSS, JavaScript, …) geschrumpft und so in einer verkleinerten Version ausgeliefert.

Die durchschnittliche Einsparung durch Komprimierung beträgt bis zu 70% was bedeutet das nur 30% des ursprünglichen Dateiinhaltes übertragen werden müssen. In den meisten Setups wird “gzip” für die Verkleinerung der ܜbertragungmenge verwendet, gzip bietet hier eine bessere Komprimierungsrate als “deflate”.

Um die Komprimierung in Apache zu aktivieren muss mod_deflate geladen werden, zusätzlich zum laden des Moduls muss in der VirtualHost (oder globalen) Konfiguration die Kompression aktiviert werden.

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/x-javascript

Zusätzlich lässt sich mit dem Parameter DeflateCompressionLevel der Komprimierungsgrad festlegen, die Grundeinstellung ist hier meist ausreichend.

Einige ältere Browserversionen unterstützen leider keine Kompression, deswegen sollten zusätzlich folgende Einstellungen hinterlegt werden um auch diesen “Exoten” Zugang zur Webpräsenz zu ermöglichen.

BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

Durch die nun gesetzten Einstellungen werden sämtliche “textuellen” Inhalten wie HTML/CSS oder JS ab jetzt komprimiert übertragen. Im nächsten Teil wird nun noch angeführt wie mittels DNS, Keepalive und der vermeidung von Redirects noch zusätzlich Ladezeit verkürzt werden kann.

Analog hierzu ist die Konfiguration unter Lighttpd, das “deflate” Modul ist vollständig unter http://redmine.lighttpd.net/projects/lighttpd/wiki/Mod_Deflate dokumentiert. Die Einrichtung ist hier denkbar einfach sofern Lighttpd mit Kompressionsunterstützung übersetzt wurde (sollte in allen Distributionspaketen Standard sein).

share save 171 16 Serie High Performance Websites   Teil 4: Weniger ist Mehr !