Mirko Giese. High Performance LAMP

Transkript

1

2 Mirko Giese High Performance LAMP

3

4 Mirko Giese High Performance LAMP

5 Mirko Giese High Performance LAMP ISBN: entwickler.press Ein Imprint der Software & Support Verlag GmbH Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar. Ihr Kontakt zum Verlag und Lektorat: Software & Support Verlag GmbH entwickler.press Geleitsstraße Frankfurt Tel.: +49 (0) Fax: +49 (0) lektorat@entwickler-press.de Lektorat: Sebastian Burkart, sburkart@entwickler-press.de Korrektorat: Frauke Pesch Satz: mediaservice, Siegen Umschlaggestaltung: Maria Rudi Belichtung, Druck & Bindung: M.P. Media-Print Informationstechnologie GmbH, Paderborn Alle Rechte, auch für Übersetzungen, sind vorbehalten. Reproduktion jeglicher Art (Fotokopie, Nachdruck, Mikrofilm, Erfassung auf elektronischen Datenträgern oder andere Verfahren) nur mit schriftlicher Genehmigung des Verlags. Jegliche Haftung für die Richtigkeit des gesamten Werks kann, trotz sorgfältiger Prüfung durch Autor und Verlag, nicht übernommen werden. Die im Buch genannten Produkte, Warenzeichen und Firmennamen sind in der Regel durch deren Inhaber geschützt.

6 Inhaltsverzeichnis V Vorwort 7 1 Einführung Begriffsklärung Sinn und Unsinn Meßmethoden Erfolgskontrolle 17 2 Apache-Webserver KeepAlive htaccess Leistungssteigerung durch richtige Konfiguration Logging Mod_gzip 34 3 Möglichkeiten von PHP Bytecode Cache Profiling Schneller vs. langsamer Code Statische Methoden Klassenkonstanten require_once() Reguläre Ausdrücke Zeichenersetzungen prüfen Fehlerunterdrückung Zeichenvergleich Konstantenmissbrauch Warnungen und Notizen Funktionen in Schleifen Vollständige Pfadangaben Caching Richtige Konfiguration Direkte und zeitversetzte Datenänderung 54 High Performance LAMP 5

7 Inhaltsverzeichnis 4 Möglichkeiten von MySQL Richtige MySQL-Indizierung Query-Optimierung Vergessen Sie den * Vergessen Sie mysql_num_rows() Am Limit arbeiten Slow Log Konfiguration Inhalt und Analyse Tools Was nun? Query Cache DB-Cluster und MySQL-Cluster Replikation Single- oder Multi-Master RLR oder SLR Konfiguration der Replikation Transparente Connect-Methoden DB-Skalierung Optimale Tabellentypen MyISAM InnoDB MEMORY Stored Procedures Richtige Konfiguration Hardware MySQL-Server-Tuning Systemadministration Load Balancing MySQL Proxy Verfügbarkeit durch Systemredundanz Webserver Datenbanken Stromversorgung Netzwerk Rechenzentren Ausfallszenarien Angriff und Gegenwehr 198 6

8 V Vorwort Es begann mit einem Vortrag auf der PHP-Konferenz. Ein Vortrag über Verfügbarkeit und Performance mit der Idee, Einblicke in die Herausforderungen und Lösungsansätze zu geben, die sich stellen, wenn Internetauftritte mit hohen Zugriffszahlen mithalten müssen. Als der dafür vorgesehene Raum zu klein für das große Interesse war, wurde mir klar, dass dieses Thema viel Interesse weckt und viele Entwickler vor ähnlichen Herausforderungen stehen. So wurde auf dieser Konferenz erst einmal skaliert: Der Vortrag fand in einem größeren Raum statt. Nach diesem Vortrag entstand dann dieses Buchprojekt. Ein Buch aus der Praxis für die Praxis. Über die Themengebiete Apache, MySQL, PHP und Systeme zeige ich Ihnen mit vielen Beispielen, wie Sie die Performance Ihrer Webseite verbessern und die Verfügbarkeit steigern können. Die meisten Maßnahmen nutzen beiden Bereichen, es gibt jedoch auch Maßnahmen, die sich positiv auf die Performance, aber negativ auf die Verfügbarkeit auswirken können. Dieses Buch wird Ihnen dabei helfen, Ihre Skripte, Datenbank und Infrastruktur aus einem anderen Blickwinkel zu betrachten. Und natürlich sollen die vielen Beispiele Sie zum Ausprobieren und Experimentieren einladen. Ich danke Sonja Waldschuk und Sebastian Burkart von entwickler.press und der Sedo GmbH für die Möglichkeit und Unterstützung, dieses Buch zu schreiben. Mein besonderer Dank gilt Janina Krätzig für ihre Hilfe, Motivation und ihren Beistand. Sollten Sie Fragen oder Hinweise haben, so bitte ich Sie mich unter folgender - Adresse zu kontaktieren: Mirko Giese HIgh Performance LAMP 7

9

10 1 Einführung Unsere Website muss immer verfügbar sein. Ausfallzeit kostet Geld. Bitte sorge dafür, dass unsere Plattform stabil läuft! Schon mal gehört? Schnelle und verfügbare Plattformen gelten für Kunden als selbstverständlich und sind für Betreiber eine Herausforderung. Im Internet ist die Konkurrenz nur einen Klick entfernt und die Erwartungen an Performance und Verfügbarkeit dementsprechend hoch. Gerade wenn eine Plattform ihre verdiente Aufmerksamkeit bekommt und damit die Zugriffszahlen schnell steigen, wird aus einer ehemals schnellen Plattform eine lahme Ente. Und so schnell die Besucher gekommen sind, so schnell sind sie wieder verschwunden. Hat man dann die vielen Besucher endlich im Griff, fällt die Festplatte des Datenbankservers aus, der Provider hat Probleme mit seinem Routing oder das letzte Systemupdate war doch nicht so unproblematisch wie erhofft. Die Plattform fällt aus und die Besucher sind frustriert. Und wenn dann endlich wieder alles funktioniert, gelingt es einem verärgerten Kunden mit einem einfachen Tool, Ihre Website per DOS 1 unerreichbar zu schalten. Damit ihnen das nicht passiert, gibt es dieses Buch. Ich möchte ihnen Wege zeigen, sich auf Ihr Wachstum vorzubereiten, mit Performance- oder Verfügbarkeitsproblemen umgehen zu können und so sich und Ihre Besucher zufriedenzustellen. Verfügbarkeit und Performance kann eine teure Angelegenheit werden. Vor allem dann, wenn es in Richtung 100 % Verfügbarkeit geht. Auf dem Weg dahin aber sind viele Maßnahmen günstiger als Sie denken. Dieses Buch betrachtet oft die Verbindung des Betriebsystems Linux, dem Webserver Apache, der Datenbank MySQL und der Skriptsprache PHP (LAMP) sie ist am häufigsten anzutreffen und bietet auch viel Raum für Maßnahmen sowohl zur Verfügbarkeitssteigerung als auch für den Performancegewinn. Daneben gibt es aber auch einige Maßnahmen, die unabhängig von der eingesetzten Softwareplattform eingesetzt werden können. Viele Maßnahmen sind sogar ganz unabhängig von der eingesetzten Programmiersprache gültig und anwendbar. 1 Denial of Service High Performance LAMP 9

11 1 Einführung 1.1 Begriffsklärung Lassen Sie uns erst einmal klären, worüber hier die ganze Zeit geredet wird. Der Begriff Performance ist zunächst einmal klar: je schneller, desto performanter. Einzelsystemen sind dort immer Grenzen gesetzt. Selbst bei optimaler Umgebung kann ein EDV-Einzelsystem seine Leistung nicht beliebig linear steigern. Abbildung 1.1: Typische Webserversättigung Abbildung 1.1 zeigt eine typische Webserversättigungskurve. Bis zu einem bestimmten Wert kann die Performance linear gesteigert werden, bis es zur Sättigung kommt. Wird der Sättigungspunkt überschritten, tritt sogar ein Performanceeinbruch ein, der bis zur totalen Leistungsverweigerung gehen kann. Welche Möglichkeiten der Performancesteigerung hat man in diesem Fall? Scale-up: Die Leistungsfähigkeit des Einzelsystems wird erhöht. Es werden also mehr Prozessoren, mehr Speicher, mehr Festplatten o.ä. hinzugefügt; Scale-out: Die Anzahl der Einzelsysteme wird erhöht und die Abfragen werden auf diese Einzelsysteme verteilt. Natürlich ist eine Kombination aus beidem möglich. Ist eine beliebige Anzahl von Einzelsystemen mit identischen Aufgaben innerhalb des Scale-outs beschäftigt, spricht man von einem Cluster. Mitglieder eines Clusters müssen nicht die gleiche Hard- oder Softwareausstattung haben, sondern lediglich die gleichen Aufgaben erfüllen. Trotzdem ist es zu empfehlen, Clustermitglieder mit gleicher Hardund Softwareausstattung zu versehen. 10

12 Begriffsklärung Mit Scale-up gelangt man dabei aber schnell an Grenzen. Einzelhardware ist nicht beliebig in der Leistung zu steigern. Es besteht auch die Gefahr, dass Ihr dann sehr teures System trotzdem nicht in der Lage sein wird, weiter gut zu skalieren. Denken Sie nur an die Limitierung an TCP-Ports: TCP arbeitet mit 16-Bit-Portnummern. TCP-Ports können also Werte zwischen 0 und annehmen. Damit ist die maximale Anzahl gleichzeitiger Verbindungen bereits durch das Protokoll begrenzt: Selbst bei der leistungsfähigsten Hardware wird ein Einzelsystem nie mehr als Clients gleichzeitig bedienen können. Und auch das ist nur ein theoretischer Wert. Praktisch sind nur die Ports bis verfügbar, um mit Clients Webserververbindungen aufzunehmen. Das heißt, pro Einzelsystem sind maximal Clients parallel bedienbar. Mit Scale-out haben Sie es da besser: Jedes im Cluster hinzugefügte System bringt wieder Ports mit in den Cluster, sodass sich mit jedem neuen System im Cluster die Anzahl theoretisch möglicher Clients um erhöht. Deshalb gilt die klare Empfehlung: Setzen Sie beim Skalieren auf Scale-out! Verfügbarkeit möchte ich aufteilen in zwei Bereiche: interne und externe Verfügbarkeit. Interne Verfügbarkeit betrachtet dabei die Verfügbarkeit von einzelnen Komponenten oder Clustern, externe Verfügbarkeit ist im Gegensatz dazu die wahrnehmbare Verfügbarkeit für den Kunden. Fallen Einzelkomponenten aus die interne Verfügbarkeit ist also nicht mehr komplett gegeben kann die externe Verfügbarkeit weiterhin gegeben sein, da das System nach außen weiterhin erreichbar und funktionstüchtig ist. Betreiben Sie zum Beispiel Ihre Webseiten hinter einem Loadbalancer mit 4 einzelnen Webservern, und einer dieser Webserver fällt aus, so wird dieser Ausfall nach außen wahrscheinlich gar nicht bemerkt werden, da die verbleibenden 3 Webserver die Arbeit übernehmen. Selbst beim Ausfall kompletter Cluster des Systems, z.b. eines Datenbankclusters, kann das System nach außen hin einen verfügbaren Eindruck vermitteln, da eine für dieses Szenario geplante Softwarekomponente den Dienst weiterhin lauffähig hält. Interne Verfügbarkeit betrachtet also die Verfügbarkeit von Systemkomponenten, während externe Verfügbarkeit sich auf das Gesamtsystem bezieht. Häufig sind die interne und externe Verfügbarkeit sehr stark aneinander gekoppelt. Fällt eine einzelne Komponenten aus, ist das Gesamtsystem von diesem Ausfall unmittelbar betroffen. Fällt beispielsweise der Datenbankserver aus und die Webserver können ohne Datenbankanbindung keine Seiten ausliefern, ist durch den Ausfall eines Einzelsystems die externe Verfügbarkeit betroffen. Solche für das Gesamtsystem kritischen Komponenten bezeichnet man als Single Point of Failure. Haben Komponenten einen Ersatz, der beim Ausfall einer Komponente deren Funktion übernimmt, spricht man von Redundanz. Ein Beispiel hierfür wären zwei Loadbalancer, von denen einer aktiv die Last verteilt und der andere im Standby-Modus bereitsteht, die Aufgaben des anderen zu übernehmen. Redundanz erhöht die Verfügbarkeit und kostet Geld. Hier gilt es also, eine vernünftige Balance zu finden. High Performance LAMP 11

13 1 Einführung Verfügbarkeit wird meist in einer Prozentangabe angegeben, die sich auf ein Jahr bezieht. Verspricht Ihr Provider ihnen also eine Verfügbarkeit der Netzwerkanbindung von 99 %, sind Ausfälle des Netzwerks von bis zu 3,6 Tagen erlaubt. Keine sehr verlockende Aussicht. Achten Sie also bei den Verfügbarkeitsgarantien darauf, wie viel Ausfallzeit diese hohen Prozentzahlen wirklich für Sie bedeuten. Eine neun hinter dem Komma sollte es da schon sein, wenn ihnen an der Verfügbarkeit gelegen ist. Denken Sie dabei auch immer an Abhängigkeiten der Komponenten untereinander. Garantieren Sie eine Verfügbarkeit von 99,99 % für Ihre Webserver, und Ihre Netzwerkanbindung ist mit 99 % Verfügbarkeit angegeben, so haben Sie im Gesamtsystem also der externen Verfügbarkeit nur eine 99-prozentige Verfügbarkeit. Denn: fällt das Netzwerk aus, nutzten die vielen verfügbareren Webserver ihnen nichts. Die Verfügbarkeit Ihres Gesamtsystems wird sich immer aus dem schlechtesten Wert der Verfügbarkeit eines Single Point of Failures ergeben. 1.2 Sinn und Unsinn Was spricht nun also dagegen, jede Komponente doppelt auszulegen und damit die Verfügbarkeit so nah wie möglich an 100 % zu bringen? Vermutlich Ihr Budget. Ihre ganze Hardware redundant bei einem zweiten Provider aufstellen und darauf warten zu lassen, dass Ihr eigentlicher Provider ausfällt und Sie umschalten können, dürfte eine sehr teure Angelegenheit werden. Analysieren Sie also Ihre Serverlandschaft und versuchen Sie, so wenig Single Points of Failure wie möglich zu haben. Denken Sie dabei an alle Eventualitäten! 10 Webserver im Cluster können alle ausfallen, wenn sie am gleichen Stromkreis hängen und in diesem Stromkreis der Strom ausfällt. Nutzen Sie die Möglichkeiten, die ihnen Ihr Provider bietet: Rechenzentren haben mindestens 2 voneinander unabhängige Stromkreise, die so ausgelegt sind, dass sie mit sehr hoher Wahrscheinlichkeit nicht gleichzeitig ausfallen. Betreiben Sie in Ihren Clustern die Hälfte der Server jeweils an einem und die anderen Hälfte am anderen Stromkreis. Auch Netzwerkkomponenten wie Switches können ausfallen, und Sie sollten zumindest so verkabeln, dass auch hier die Hälfte der Clustermember an einem und die anderen Hälfte an einem anderen Switch angeschlossen ist. So kann zwar die Hälfte Ihrer Server plötzlich unerreichbar sein, die andere Hälfte jedoch arbeitet weiter. Ihr Gesamtsystem wird bestimmt langsamer werden aber es wird nicht ausfallen. Alternativ können Sie Ihren Servern 2 Netzwerkanschlüsse spendieren und diese an 2 verschiedene Switches anschließen. Betreiben Sie dann diese beiden Netzwerkports mittels Bonding als eine logische, so sind sie gegen einen Ausfall eines Switches geschützt. Am Besten planen Sie bereits mit dem Wissen, dass es keine ausfallsichere Komponente gibt. Und sparen Sie nicht am falschen Ende: Haben Sie 20 Webserver an einem Loadbalancer, dürfte ein Ausfall eines Webservers leicht zu verschmerzen sein. Die Komponenten dieses Webservers brauchen also gar keine besonders ausfallsicheren und damit teuren Eigenschaften zu haben wie doppelte Netzteile, Raid Controller usw. Was aber, wenn ihnen der teure Loadbalancer oder Router ausfällt? Sie haben 20 Webserver, ohne dass Sie ein einziger Request erreichen kann. Hier lohnt sich eine größere Investition in Hot-Standby-Hardware sehr. Auch Performanceverbesserungen sollten Sie vor allem dort ansetzen, wo sie benötigt werden. Schön, wenn Ihre Startseite statt in 0,01 Sekunden in 0,008 Sekunden ausge- 12

14 Meßmethoden liefert werden kann. Schade nur, dass das Ihren Kunden nicht auffallen wird. Stürzen Sie sich also nicht blind auf Performanceverbesserungen, sondern analysieren Sie, was überhaupt einen Performanceschub benötigt. Konzentrieren Sie sich anfangs auf die Maßnahmen, von denen Ihre gesamte Website profitiert und kommen Sie dann zu den Methoden, die speziell für einzelne Seiten sind. 1.3 Meßmethoden All die Maßnahmen zur Verbesserung von Verfügbarkeit und Performance sollten nachvollziehbar sein. Ohne Messung können Sie keine Aussagen zur Verfügbarkeit machen. Wie schnell Ihre Seite nach der letzten Optimierung wirklich ist, wird sich erst nach einer Messung zeigen. Messungen sollten auf keinen Fall das gemessene System selbst negativ beeinflussen. Sekündliche Messungen zur Verfügbarkeit, die eine so hohe Last erzeugen, dass sie die Verfügbarkeit gefährden, sind also vollkommen ungeeignet. Greifen Sie auf Tools zurück, die ihnen helfen, diese Messungen durchzuführen und die auf bestimmte Zustände reagieren. Für das Monitoring Ihrer Server, Netzwerke und Services empfiehlt sich Nagios ( Abbildung 1.2: Nagios Tactical Overview High Performance LAMP 13

15 1 Einführung Nagios bringt eine Menge Checks für typische Monitoring-Bedürfnisse mit. Gleichzeitig kann man für Nagios eigene Checks schreiben, sodass Sie praktisch alles technisch abfragbare Überwachen können. Für die langfristige Beobachtung und Analyse empfiehlt sich Cacti ( Abbildung 1.3: Cacti-Netzwerkgraf Cacti kann alles aufzeichnen, was sich in Zahlen ausdrücken lässt. Dank vieler Plug-ins können Sie die Server-Load, Netzwerkverkehr, MySQL-Parameter und Vieles mehr messen. Eine regelmäßige Auswertung dieser Daten wird ihnen helfen, Engpässe zu erkennen, bevor diese sich negativ auswirken. Gerade die Betrachtung der längerfristigen Aufzeichnungen hilft dabei abzuschätzen, wann Ihr System weiter ausgebaut werden muss, um der steigenden Besucherzahl weiterhin gerecht zu werden. Es kann ihnen auch zeigen, ab welchem Zeitpunkt sich Parameter sprunghaft geändert haben. Nicht selten ist zu diesem Zeitpunkt ein Launch online gegangen, dessen Software noch nicht optimal ist. Sie sollten dann noch einmal verfolgen, was zu diesem Zeitpunkt gelauncht wurde und die entsprechenden Komponenten optimieren. Beide Tools helfen, frühzeitig Engpässe bei Verfügbarkeit oder Ausfälle von Komponenten zu erkennen und sie zu beseitigen. Langfristige Trends werden erkennbar, und Sie können Engpässen entgegenwirken, bevor diese auftauchen. 14

16 Meßmethoden Für Performancemessungen Ihres Webservers kann ich ApacheBench ( apache.org/docs/2.0/programs/ab.html) empfehlen. Das haben sie bereits auf Ihrem Server, wenn sie den Apache Webserver installiert haben. Wichtig sind hier Angaben zur Anzahl der Requests (-n) und Gleichzeitigkeit der Requests (-c). Seien sie fair zu Ihrem Webserver eine Gleichzeitigkeit von über 50 ist unwahrscheinlich. Und um Zufallsabweichungen zu verringern, sollten Sie die Anzahl der Requests nicht zu niedrig wählen, also möglichst Requests oder mehr. Mit ApacheBench können Sie auch gut die Performance Ihres Gesamtsystems testen: Machen Sie den Test auf den Loadbalance-URL, und Sie bekommen Auskunft darüber, wie viele Requests Ihr System insgesamt bearbeiten könnte. Aber beachten Sie, dass die regulären Requests dabei hinzugerechnet werden müssen. Testen Sie die Art der Performance nur dann, wenn Sie wenig Last auf Ihrem Gesamtsystem haben. Achtung Seien Sie auf der Hut vor Performancetests Ihres Gesamtsystems, die Ihr Gesamtsystem überlasten könnten! Weder Sie noch Ihre Kunden haben etwas davon, wenn Ihre Seite während solcher Tests nicht erreichbar ist. Steigern Sie nur langsam und vorsichtig die Last in Bereichen, in denen Sie noch sicher sind, Ihr System nicht zu überlasten. Im Zweifel führen Sie diese Tests nicht durch! Tipp Hier eine Alternative für die Bestimmung der Gesamtbelastbarkeit. Statt Ihr System mit sinnlosen Anfragen ausschließlich zur Lastmessung zu gefährden, versuchen Sie doch, nach und nach immer einen Webserver mehr aus dem Balancing herauszunehmen. Auch hier seien Sie vorsichtig und geben Sie jeder Änderung mindestens fünf Minuten Zeit, Wirkung zu zeigen. Wenn Sie gleichzeitig messen, wie viele Requests Ihr momentaner regulärer Besucherkreis auslöst, können Sie auf diese Weise herausfinden, wie viele Webserver Sie für eine bestimmte Last benötigen und diese Größe sehr zuverlässig auf Ihr Gesamtsystem hochrechnen. Beachten Sie bei Messungen mit ApacheBench, dass Sie dort nicht nur die reine Webserverperformance messen, sondern auch andere Faktoren Ihre Messung beeinflussen. Denken Sie dabei nur an das Netzwerk. Misst man die Performance einer großen Website mit ApacheBench von einem Rechner aus, der lediglich per ISDN an das Internet angebunden ist, so werden die Requests pro Sekunde erheblich abweichen von einer Messung, die zur gleichen Zeit von einem Rechner durchgeführt wurde, der mit der gleichen Geschwindigkeit wie diese Website angebunden ist. Sobald Sie Ihr Netzwerk voll auslasten, werden die Messwerte erheblich verfälscht, sie werden praktisch unbrauchbar. Klar sollte auch sein, dass Messungen weit entfernter Netzwerke nicht empfehlenswert sind, da Sie wenig Einfluss darauf haben, wie schnell Ihre Daten transportiert werden. Idealerweise befinden Sie sich im gleichen Netzwerksegment wie Ihr Messobjekt und haben auch die gleiche Netzanbindung. High Performance LAMP 15

17 1 Einführung Datenbankperformancemessungen gestalten sich recht schwierig. Aufgrund der Tatsache, dass allein durch richtige oder falsche Indizierung ganz unterschiedliche Zeiten für die gleichen SQL-Statements erreicht werden können, empfiehlt sich hier eine sehr praktische Messung. Sie messen die Ladezeiten häufig besuchter Seiten z.b. Ihrer Startseite und messen innerhalb des Startskriptes den Zeitaufwand für die Abarbeitung des Skripts selbst sowie die Zeit, die Datenbankoperationen verbraucht haben. Auf diese Art und Weise finden Sie auch schnell die Datenbankoperationen, die besonders viel Zeit verbrauchen und eine Optimierung benötigen. Sehr empfehlenswert ist es auch, die Prozessliste Ihres Datenbankservers während dieser Zeit zu beobachten: Was nutzt es, zur Performancesteigerung 10 neue Webserver zu installieren, wenn der eigentliche Grund Ihrer schlechten Performance darin besteht, dass all Ihre Webserver auf die Datenbank warten. Bei allem Messeifer verlieren Sie bitte nicht den praktischen Grund Ihrer Messungen aus den Augen, und versuchen Sie Ihre Messungen zu verstehen. Messen Sie also die Auslieferungsgeschwindigkeit einer dynamischen Seite, so messen Sie ja nie die reine Webserverperformance, sondern die Performance Ihrer Skriptsprache ebenso wie die Performance Ihrer Datenbank. Messen Sie hingegen die Auslieferungsgeschwindigkeit statischer Webseiten, obwohl sie tatsächlich keine statischen Webseiten ausliefern, ist die Messung nicht aussagekräftig für die Performance Ihres Webservers oder Ihrer Website. Warum so eine statische Messung trotzdem sinnvoll sein kann, werde ich ihnen später zeigen. Ohne speziell zu messen, stellt ihnen Linux permanent einen Indikator für die Systembelastung bereit: die Load. Wie sie sich genau berechnet, ist recht kompliziert, daher reicht es als Faustregel anzunehmen, dass pro Prozessor eine Load von 1 bedeutet, dass Ihr System 2 ungefähr so viele Anfragen verarbeitet, wie es gestellt bekommt. Haben Sie also ein System mit 4 Prozessorkernen, ist eine Load bis 4 völlig unkritisch. Da bei Datenbanken und Webservern Last nie homogen, sondern zufällig auftritt, können auch Load- Spitzen vom Doppelten der Faustregel problemlos verarbeitet werden. Es gibt jedoch bei jedem System einen Punkt, an dem es kippt und die Performance rapide zusammenbricht. Dieser Punkt ist schwer vorhersagbar, da zu viele Einflussfaktoren eine Rolle spielen. In Lastsituationen werden Sie diesen Punkt vielleicht einmal erleben, und Sie sollten sich genau merken, ab welcher Load dieser Zustand eintritt und dann Ihre Serverhardware stets so planen, dass Sie selbst zu Spitzenlastzeiten diesen Punkt nicht mehr erreichen werden. Messen Sie regelmäßig die Load und lassen sich alarmieren, sobald sie einen gefährlichen Wert überschreitet. Erfolgreiche Performanceverbesserungen lassen sich immer daran erkennen, dass die Load sinkt. Performanceverschlechterungen sehen Sie demzufolge auch daran, dass die Load steigt. 2 System hier im Sinne von Gesamtsystem mit allen Komponenten wie Netzwerk, Festplatte, aller darauf laufenden Software 16

18 1.4 Erfolgskontrolle Erfolgskontrolle Haben Sie also alle Messungen im Griff, verstehen Sie, was Sie messen und interpretieren Sie die Werte richtig, geht es an die Optimierung. Von Optimierung sprechen können Sie natürlich erst dann, wenn Ihr Optimierungsversuch tatsächlich die Leistung oder die Verfügbarkeit gesteigert hat. Um das herauszufinden, bedarf es einer Erfolgskontrolle. Messungen vor und nach der Optimierung sind sehr wichtig. Stellen Sie sich dann Fragen wie Hat sich die Performance wirklich gesteigert? Um wie viel Prozent? Ist das nachweislich der Einfluss meiner Optimierung, oder kann es auch andere Ursachen haben? Hat meine Optimierung bisher nicht bedachte Nebenwirkungen? Und scheuen Sie sich nicht, Optimierungen rückgängig zu machen, die keinen Erfolg hatten. Besonders wichtig: immer nur eine Optimierung machen und dann den Erfolg kontrollieren. Diese Regel kann gar nicht genügend betont werden. Sonst kommt es zu einem Zustand, bei dem Sie 10 Dinge gleichzeitig optimiert haben, und die Erfolgsmessung beweist auch, dass sich etwas zum Positiven gewendet hat. Aber wie können Sie sicher sein, dass alle 10 Optimierungen an diesem Erfolg beteiligt sind? Woher wissen Sie, dass nicht die vierte und siebte Optimierung sogar die Performance leicht negativ beeinflusst haben und Sie das nur deshalb nicht merken, weil die anderen Optimierungen das ausgleichen? Auch wenn es also erst einmal mühselig erscheint: Nehmen Sie sich die Zeit und optimieren Sie nur eine Sache, kontrollieren den Erfolg der Optimierung und ziehen dann Rückschlüsse. Erst dann geht es mit der nächsten Optimierung weiter. Optimierungen zur Verfügbarkeit können einen sehr langfristigen Charakter bekommen. Haben Sie z.b. ein Problem damit, dass Ihre Datenbank einmal im Monat aus unbekannter Ursache ausfällt und Sie haben 5 Möglichkeiten identifiziert, an denen das liegen kann, so sind Sie gut beraten, die für Sie wahrscheinlichste Möglichkeit zu beseitigen und dann zu warten. Ob Sie Erfolg damit hatten oder nicht, wissen Sie so richtig frühestens in einem Monat, eher aber in zwei Monaten. Und wenn Sie dann bemerken, dass Ihr Problem damit nicht gelöst ist, gehen Sie Möglichkeit 2 an. Denn auch hier gilt: Machen Sie alle 5 Möglichkeiten auf einmal und Ihre Datenbank stürzt trotzdem einmal monatlich ab, woher wissen Sie, dass Sie die alte Ursache nicht doch behoben haben aber die vierte Änderung dazu führt, dass Ihre Datenbank wieder abstürzt nur aus einem anderen Grund? Um nicht so lange warten zu müssen, lohnt sich die Suche nach der eigentlichen Ursache. Versuchen Sie nachzuvollziehen, was zu der entsprechenden Zeit in Ihrem System los war, welche Aufgaben bearbeitet wurden, ob Cronjobs liefen oder Backups, welche Webseiten aufgerufen wurden. Wenn es geht, versuchen Sie den Systemzustand so herzustellen, wie er zum Zeitpunkt des Ausfalls war. Fällt das System dann wieder aus, ist etwas Wichtiges geschehen: Sie können Ihr Problem reproduzieren. Damit ist eine viel schnellere Lösung dieses Problems möglich, da Sie nun Optimierungen direkt testen können. High Performance LAMP 17

19 1 Einführung Noch ein wichtiger Tipp: Vergessen Sie nie Ihre Kollegen! Machen Sie bekannt, was Sie vorhaben, welche Auswirkungen das haben kann, und dass Ihre Kollegen auf bestimmte Verhaltensweisen Ihres Systems besonders achten mögen. Neben der Möglichkeit, dass einer Ihrer Kollegen die Lösung Ihres Problems vielleicht doch kennt, ist es wichtig, dass Ihre Kollegen von den Änderungen unterrichtet sind und ihnen auch schnell Feedback geben können, wenn Ihre Optimierung unerwartete Nebenwirkungen hat. Sollten Sie Ihre Kollegen im Dunkeln über Ihre Versuche lassen, könnte es sein, dass diese plötzlich seltsame Fehler bemerken und lange nach der Ursache suchen müssen. Stellt sich dann heraus, dass die Ursache in Ihrer letzten Optimierung liegt, von der niemand etwas wusste, könnte das Ihre Optimierungsversuche in ein sehr schlechtes Licht rücken. Dabei meinen Sie es doch gut. Also reden Sie darüber! 18

20 2 Apache-Webserver Der Webserver nimmt in der Auslieferung Ihrer Website eine zentrale Rolle ein. Eigentlich ein einfacher Job. Er nimmt einen Request an, versteht und interpretiert das HTTP- Protokoll und antwortet entsprechend. Auch wenn Sie nicht Apache als Webserver einsetzen, macht Ihr Webserver doch genau das und nichts anderes. Bis ein Client mit dem Webserver überhaupt Kontakt aufnehmen kann, sind einige Dinge zu tun: Der Client muss den Domain-Namen in eine IP übersetzen, diese IP auf dem dazugehörigen Port kontaktieren und eine Verbindung herstellen. Der Webserver öffnet dann wiederum einen Port auf dem Server, über den dann die Kommunikation mit dem Client erfolgen wird. Hierfür stehen ihm bis zu Ports auf dem Server zur Verfügung. Erst danach kann der Webserver mit seiner Arbeit beginnen und den Request abarbeiten. Die Phasen eines solchen Requests möchte ich unterteilen in: Phase Post-Read-Request URI-Translation Header parsing Access Control Was passiert in dieser Phase Tabelle 2.1: Apache-Requestabarbeitung Der Webserver hat den gesamten Client-Request erhalten und die HTTP-Header gelesen. Die angeforderte Seite wird übersetzt in einen physikalisch auf dem Webserver vorhandenen Dateinamen oder ein virtuelles Dokument, das durch einen Skript-Alias gesetzt wurde. Das virtuelle Dokument seinerseits wird zu einem physikalischen Dokument übersetzt. So wird Beispielsweise aus /index.php das tatsächliche File /home/www/hostname/wwwroot/index.php. Der gesamte Übersetzungsvorgang kann komplett beeinflusst werden durch mod_rewrite, das in dieser Phase aktiv wird. Auch hier findet letztendlich eine Übersetzung zu einem physikalischen Dokument statt. Wurde ein Verzeichnis durch den Client angefordert (z.b. wird die durch den DirectoryIndex gegebene Indexdatei gesucht und in eine physikalische Datei übersetzt. Hier werden die Request Header verarbeitet. In dieser Phase können sie geändert, oder es kann auf bestimmte Request Header reagiert werden, so können bestimmte User-Agents von der Seitenauslieferung ausgeschlossen werden. Ebenso wird in dieser Phase die.htaccess-datei ausgewertet. Hier entscheidet sich auch, ob ein Request komprimiert oder unkomprimiert beantwortet wird. In dieser Phase werden Zugangsberechtigungen geprüft und verarbeitet. Sollten Sie eine IP-Adresse blockiert haben, geschieht das in dieser Phase. Beachten Sie, dass die.htaccess-datei zwar in der vorherigen Phase ausgewertet wurde, die eventuell darin gesetzte Zugangsberechtigung aber erst in dieser Phase bearbeitet wird. High Performance LAMP 19