Spätestens seit Januar war uns bewusst das wir etwas tun müssen. Die Ladezeiten und Ausfälle des iPhoneBlog waren nicht mehr die Ausnahme, sondern die Regel. Das nervte nicht nur uns sondern auch euch in zunehmendem Maße.

Seit etwa einer Woche sind unsere Pläne umgesetzt und das iPhoneBlog sollte mit Ausnahme des Feeds wieder zuverlässig und schneller als je zuvor erreichbar sein.
An dieser Stelle noch mal der dringende Hinweis. Solltet ihr Probleme mit dem Feed haben, abonniert ihn neu. Die Korrekte Feed Adresse ist:

https://www.iphoneblog.de/feed/

Soweit die Neuigkeiten. Im folgenden eine Schilderung was wir unternommen haben. Dies könnt ihr aus Interesse lesen, als Ratgeber für euren Blog sehen, oder einfach ignorieren. iPhone Relevanz nicht gegeben.

iPhoneBlog.de wurde seit Herbst Ende letzten Jahres auf meinem alten Hetzner Dedicated Server – DS3000 – gehostet. In einer damaligen Nacht und Nebel Aktion zogen wir die Seiten notgedrungen dorthin um. Der alte Anbieter (server4you) hatte ohne Vorankündigung die Seiten Offline genommen und den Vertrag gekündigt (zu hohe Last).

Nun lag die WordPress Installation und alles was so dazu gehörte auf einem Athlon 3000XP mit 1 GB RAM. Das war besser als zuvor, aber auch schon lange nicht mehr Zeitgemäß. Den Normalbetrieb konnte der Server gut verkraften. Zu Spitzenzeiten schaukelte er sich jedoch immer öfter bis zur völligen Erschöpfung hoch. Wie zuletzt beim Live Event zur Vorstellung des iPhone OS 3.0 Noch am Abend dieses Tages hatten wir beschlossen neue Hardware zu mieten die uns für die nächsten Monate bzw. Jahre reichen wird.

Unsere Anforderungen sahen Folgende Punkte vor:

• 4 GB Arbeitsspeicher oder mehr
• Mindestens 2 CPUs lieber 4
• 1 TB Traffic inklusive
• keine 2 Man Show Anbieter
• Hosting in Deutschland
• monatliche Kosten unter 80 €

Der Markt der Serververmieter ist recht Komplex. Aufgrund der sehr guten Erfahrungen in den letzten 5 Jahren viel unser erster Blick auf die aktuellen Angebote von Hetzner. Bis auf server4you und serverloft.de gab es auch keine Alternativen. Andere Anbieter die das Preislimit halten konnten schienen teils unseriös oder machten sonst einen seltsam Eindruck. Server4You schied aufgrund der Vergangenheit auch aus.

Es blieben im Rennen ein DS-5000 von Hetzner und das Angebot PerfectServer L von serverloft.

Entschieden haben wir uns für das Angebot von serverloft. Dies hatte mehrere Gründe. Unabhängig davon dass das Hetzner Angebot unsere Anforderungen abdeckte und zudem günstiger war konnten wir der doppelten Anzahl an CPU Cores nicht widerstehen. Zudem bestand Hetzner auch nach vielen Jahren Treue auf die Einrichtungsgebühr von 99 €. Diese allein bezahlen das Delta zum Serverloft Angebot schon die ersten 5 Monate. Dennoch blieb ein flaues Gefühl. Schließlich vereint Hetzner die Vorteile eines kleinen Anbieters (flexibel) mit den Vorzügen eines großen Anbieters (Rechtssicherheit, Stabilität) in sich. Den neuen Anbieter konnten wir nicht einschätzen.

Für 79 € bietet das Angebot recht viel. Hier ein kleiner Auszug:

• Quadcore Opteron
• ein einfaches Hardware Raid – aber immerhin
• 4 GB Speicher
• Fujitsu Siemens 19″ 2HE Gerät mit beindruckend gutem Handbuch
• Remote Management Interface (IPMI)
• 5000 GB Traffic inklusive (100MBit Anbindung)

Unsere Hochrechnungen sagen uns das wir damit auf jeden Fall für die nächsten 18 Monate auskommen. Also: Bestellt!

Serverloft.de

Nach zwei Werktagen konnten wir erstmals auf die Hardware zugreifen. Das ist schnell. Die Informationspolitik bis dorthin war ausreichend, lässt aber noch Spiel nach oben zu.

Das von uns ausgewählte Startimage Debian 4.0 – Minimal schien eine leicht angepasste Version des Anbieters zu sein. Custom Kernel, /etc/modules angepasst usw. Spielte für uns aber eh keine Rolle, weil wir das OS eh selbst noch mal neu installiert haben. Was wir an dieser Stelle schmerzlich vermissten, war ein WIKI oder Forum des Anbieters, in dem Informationen zur Hardware gesammelt waren. So bleibt uns nichts anderes übrig als die nächsten Monate unsere eigenen Erfahrungen zu sammeln und dann zu handeln. Ein paar erste Ratschläge findet ihr weiter unten im Artikel.

Einen schlechten Eindruck hat zudem auch hinterlassen, dass in der motd des RescueSystems (Ubuntu Live), Kernelparameter empfohlen wurden die beim vorinstallierten Image nicht gesetzt waren. Eine Nachfrage beim Support hat inzwischen ergeben dass diese Informationen veraltet sind.

Auch war der Router/Layer3 Switch (Juniper) in unserem Subnetz mit einem Default Image versehen. Dies hatte zur Folge, dass sich das Interface an dem wir hingen wie ein Mirror Port verhielt. Früher sagte man dazu auch Hub. Wir sahen sämtlichen Traffic aller anderen Kunden in unserem Subnetz. Dies gilt natürlich auch umgekehrt. Selten war das Mitschneiden von Kennwörtern und anderen persönlichen Informationen so einfach möglich. Für das beheben dieses Verhaltens (nach unserem Hinweis) benötigte Serverloft noch 3 weitere Werktage. Für eine erste Stellungnahme gingen auch bereits 2 Tage ins Land. Auch waren SSH, SNMP und andere Dienste auf dem Router erreichbar. Wir haben es gelassen Default Kennwörter zu testen.

Detaillierte erste Eindrücke zum Support findet ihr auch in diesem Beitrag von mir im serversupportforum.de. Dieses Forum wird von Intergenia – der Firma hinter Server4You, Serverloft und anderen – betrieben und „moderiert“.

Mein Fazit zu Serverloft:

Gnadenlos günstig. Aber was man bekommt ist Hardware und eine Netzwerkanbindung. Wer sich nicht in allen Bereichen, die der Betrieb eines Servers mit sich bringt, selbst helfen kann hat verloren. Auch wer mit dem Gedanken spielt sich einen Dedicated Server zum „rumspielen“ oder wahlweise „lernen“ zuzulegen ist bei anderen Anbietern meiner Meinung nach besser beraten. Angebote ohne Support gibt es auch günstiger.

Vom Werbeslogan „Professionelles Hosting“ darf man sich, wie ich meine, daher nicht täuschen lassen. In der Praxis bedeutet das teils unfreundliche oder wahlweise inkompetente Mitarbeiter (Bitte beachten: Dies sind meine ganz persönlichen Empfindungen). Wenn Support für euch wie uns jedoch kein Kriterium ist – bei 79 € – könnte serverloft was für euch sein. Es könnte jedoch auch sein, dass mich hier mein beruflicher Hintergrund (IT-Berater, Großkunden) und der Support von Hetzner etwas blind für die Realität gemacht haben. Eventuell ist das geschilderte ja normal. Unter professionell verstehe ich jedoch etwas anderes.

Technik

Doch genug zum Anbieter. Ab jetzt Details für diejenigen die an der technischen Umsetzung interessiert sind. Vielleicht findet ihr euch ja irgendwann mal in der selben Situation oder könnt uns noch Anregungen geben. Ach ja, die Situation. Neben dem reinen Webserver für das iPhoneBlog soll die Hardware auch noch das eine oder andere Mini Projekt (Thorstens Experimente) beherbergen. Zum jetzigen Zeitpunkt standen folgende Dinge auf der Liste.

• Webserver für diverse Seiten – Neben dem iPhoneBlog hauptsächlich Private Webseiten für Alex, mich, Freunde und Familie.
• mysql Datenbank
• VPN Konzentrator – zur Administration und zum surfen in offenen WLANs
• IceCast 2 – Streaming Server für Live Berichterstattung
• Fileserver
• Diverser Kleinkram – SVN, Jabber,… Spielkram für mich halt…
• Monitoring – der diversen Anwendungen

Schon zu Beginn stand fest dass wir Virtualisierung mit XEN einsetzen werden.

Die Gründe dafür sind einfach. Das wichtigste Kriterium ist eine Partitionierung der unterschiedlichen Anforderungen. Zum Beispiel muss mein „Spielkram“ getrennt sein vom Webserver. Es ist nicht gerade schön wenn mein $$1337-Server läuft, und dafür der Webserver in die Knie geht. Darüber hinaus erlaubt die Virtualiserung ein flexibles Zuteilen von Ressourcen. Die laufenden Applikationen haben für uns ja unterschiedliche Prioritäten.

Auch ist durch die Virtualisierung ein leichteres Skalieren möglich. Wir könnten zum Beispiel in 12 Monaten relativ leicht den gesamten Webserver auf eine zweite Hardware umziehen.
Ich möchte hier jedoch keinen Artikel über Virtualiserung schreiben. Dazu findet sich im Netz ausreichend Material. Es ist ein Branchentrend. Und das zu Recht.

Die konkrete Frage die wir noch hatten war wie genau wir die Partitionierung der vorhandenen Ressourcen vornehmen. Eine Domain – der XEN Begriff für einen virtuellen Computer – für jede Anwendung?

Also zum Beispiel eine Domain für das iPhoneblog.de inklusive aller Dienste wie Apache, mysql, Mail, usw… Eine Domain für unseren anderen Webdienste, eine Domain für Icecast2, eine für …

Oder doch eher eine Domain pro Applikation? Webserver -> Domain. Mailserver -> Eine Domain, SVN -> Eine Domain.

Vielleicht sogar nur 2 Domains. Eine für Alex, eine für mich.

Entschieden habe ich mich letztlich für eine Mischung aus allen 3 Ansätzen. Es ist Quatsch für jede Webseite ein eigenes Betriebsystem laufen zu lassen. Unser Setup sehr ihr im folgenden Schaubild. Im Anschluss eine Diskussion über die Aufgaben der jeweiligen Domains.

dom0

dom0 ist die priviligierte Domain einer XEN Installation. Die dom0 startet, verwaltet und beendet alle anderen Domains. Die Domain0 ist die einzige Domain die auf alle Hardware direkten Zugriff erhält und wird automatisch vom XEN Hypervisor gestartet.

Die generelle Empfehlung ist die dom0 so wenig wie möglich neben dieser Aufgabe machen zu lassen. Daran haben wir uns gehalten. Mit einer Ausnahme. Die Dom0 spielt Router und Firewall für unser „Netzwerk“.

Wie man erkennen kann haben wir alle Domains bis auf dom0 und web nur ein Interface. Dieses Interface ist an die virtuelle Bridge angeschlossen. Diese Domains haben lediglich private IP Adressen.

Zwischen Domain0 und web besteht eine Point to Point Verbindung. Die Domain0 agiert als Router für web.

web

web ist die Domain die unseren Apache beherbergt. Sonst nichts. kein Mysql, kein Mailserver. Wir haben dieser Domain mit Abstand die meisten Ressourcen zugeteilt. Apache profitiert unglaublich von RAM. Ein grundsätzlicher Unterschied zu anderen Domains ist das diese 2 Netzwerkinterfaces hat. Das übliche ins LAN und eines in unser LAN. Beim Webserver wollten wir kein NAT einsetzen. Da nehmen wir die Sicherheitsrisiken in kauf die das mit sich bringt. Es bleibt ein privates Projekt und irgendwo muss das ganze auch vom Betriebsaufwand überschaubar bleiben.

Ursprünglich hatten wir auch den Plan einen Reverse Proxy (entweder squid oder apache mit mod_proxy) in einer separaten Domain laufen zu lassen. Auch dieser ist erstmal dem Betriebsaufwand zum Opfer gefallen. Auch bin ich mir nicht mehr sicher ob er die Seiten noch beschleunigen könnte. Aber dazu später mehr im Abschnitt Apache.

mysql

Ein zentraler mysql Server. Viele Webseiten und Tools benötigen einen mysql Server. Insofern erschien es uns logisch diesen zentral zu betreiben und nicht für jeden Anwendungsfall eine separate Installation. Wir erhoffen uns davon eine Effektivere Ausnutzung der Ressourcen sowie geringer Wartungsaufwand.
Der Nachteil ist jedoch das Applikation A Applikation B negativ beeinflussen könnte.

icecast

Icecast ist unser Streaming Server. Die Ressourcen die so ein icecast Server benötigt sind quasi nicht existent. CPU und RAM bedarf sind kaum messbar. Das einzige was hier anfällt ist Netzwerk Traffic.

Ausgelagert haben wir diesen weil wir uns den mit einem befreundeten Projekt teilen und klare Trennung der Infrastruktur benötigen. Die Alternative wäre gewesen ihn auf dem Toolserver laufen zu lassen.

Tools

Damit wären wir auch schon beim Toolserver. Der Toolserver ist das Auffangbecken für den gesamten Rest. Alle Projekte starten erst einmal hier. Aktuell läuft hier Hauptsächlich ein Fileserver (NAS,WebDAV) für unseren Datenaustausch zwischen den Domains. Eigentlich sollte hier auch das Monitoring stattfinden. Durch einen nächtlichen Fehler liegt das aktuell noch auf „web“. Sehr unschön.

beta

Beta ist die Testumgebung für das iPhoneBlog und aktuell noch nicht von der alten Hardware migriert. Hier läuft ein Klon der WordPress Installation auf dem wir Dinge ausprobieren bevor wir sie auf die live Seite nehmen.

Installation des XEN Host Systems

Wie bereits oben angekündigt haben wir die Debian Minimal Installation von Serverloft.de nicht verwendet. Schließlich installieren wir eh XEN da bietet sich ein sauberer Start an.
Die Installation gestaltete sich dank der IPMI Konsole und eines Recoverysystems recht schmerzlos. Die IPMI Konsole – wer so etwas nicht kennt – ermöglicht den Zugriff auf den Server von der ersten Sekunde an. Technisch wird die Serielle Konsole an einen SSH/Webserver weitergeleitet der auf einem „Mini Computer im Computer“ läuft und seine eigene IP Adresse hat. Darüber kann man den Server auch Ein-/Ausschalten usw. Das rettet einen wenn das eigentliche Betriebsystem – aus welchen Gründen auch immer – nicht erreichbar ist.

Allgemein

Als Leitfaden für die Installation von Debian diente mir die offizielle Dokumentation. Der Einfachheit halber habe ich dazu das Rescue System von serverloft gebootet. Ein Ubuntu Live. Und damit – als debianisches OS – sehr gut geeignet. Auf die eigentliche Installation von Debian werde ich hier nicht eingehen. Doch ein paar Besonderheiten gibt es bei serverloft zu beachten.

Nach der Installation wird man feststellen das die Festplatten bzw. das RAID nur sehr langsam schreibt (~16 MB/s). Abhilfe schafft das aktivieren des Schreib Puffers auf den eigentlichen Festplatten. Damit das funktioniert müssen die Kernelmodule sg und mptctl geladen sein. Danach stehen die Geräte /dev/sg* zu Verfügung. Das eigentliche aktivieren des Schreib Puffers erfolgt mittels sdparm.

sdparm -s WCE=1 /dev/sg0
sdparm -s WCE=1 /dev/sg1

Um die IPMI Konsole aus dem OS heraus ansprechen zu können (mittels ipmitool) müssen die Kernelmodule ipmi_si und ipmi_devintf geladen werden. Leider sind diese (oder der Controller) instabil oder schlecht implementiert. Nach einiger Zeit läuft dann der Kernelthread [kipmi] mit 100% CPU Last. Wir haben die Kernelmodule also wieder deaktiviert. Wir benötigen die Funktionalität eh nicht. Ach ja, versucht nicht die Kernelmodule zu „unloaden“ (wie sagt man das?). Dies hat zur Folge dass sich das IPMI aufhängt. Danach muss der Server physikalisch kurz vom Strom genommen werden. Unschön.

Netzwerksetup

Das einrichten des Netzwerks gestaltete sich als recht kompliziert. Zum einen wollten wir ein virtuelles LAN. Zum anderen war auch die direkte Anbindung der web-domU nicht trivial. Normalerweise hängt man hierzu einfach alle Domains an eine Bridge welche mit dem Router verbunden ist.

Die Router von Serverloft akzeptieren jedoch nur die eigentliche MAC Adresse. Geholfen haben 2 Alternative XEN Netzwerkskripte. Zum einen das network-script Fridu Script. Zum anderen ein leicht angepasstes vif-bridge Skript. Diese beiden Skripte müssen in der xend-config.sxp entsprechend eingetragen werden. Zum Beispiel so:

(network-script 'Fridu-network.script LAN:192.168.1.1:255.255.255.0')
(vif-script 'vif-tp bridge="LAN"')

Die zugehörige DomU Konfiguration sieht dann z.B. so aus:

vif         =
[
 'ip=192.168.1.4,mac=00:16:3e:26:5e:0b,bridge=LAN,vifname=l-web',
 'ip=85.25.178.202,mac=00:16:3e:7d:82:65,bridge=none,vifname=e-web'
]

Wie oben bereits erwähnt wird das externe Interface mit einer Point2Point Verbindung durch die Dom0 geschleift. Dazu muss in der DomU für eth1 folgendes in /etc/network/interfaces stehen:

auto eth1
iface eth1 inet static
  address $_öffentliche_IP_$
  netmask 255.255.255.255 ## Netzmaske ist wichtig
  up /sbin/route add default dev eth1
  up /sbin/route add default gw $_öffentliche_IP_der_dom0_$

Wie ihr merkt hab ich das ganze schon nicht mehr so richtig verstanden. Ist schon fast ne Woche her. Aber vielleicht hilft es dem einen oder anderen (oder auch mir in Zukunft wenn ich es mal wieder verstehen muss) Beispiel zu haben.

WordPress

Das iPhoneBlog ist eine WordPress Installation. Benötigt wird daher ein Webserver mit PHP Unterstützung sowie eine mySQL Datenbank. iPhoneBlog.de wird aktuell mit etwa fünf Anfragen pro Sekunde im Tagesmittel, mit Spitzenwerten von 15 pro Sekunde beschossen. Das Übersteht diese Hardware zwar auch in einer Default Installation. Doch sind die Ladezeiten dann nicht gerade optimal und die Kiste steht unnötig unter Last. Wir haben uns daher ausführlich mit dem optimalen Einstellungen auseinandergesetzt. Dies ist ein fortlaufender Prozess. Doch sind wir mit den bisherigen Optimierungen schon sehr zufrieden so dass wir dieses Wissen teilen möchten. Um Anregungen zu erhalten und oder auch einen Startpunkt für andere zu geben die eine ähnliche Last zu bewältigen haben.

Als Webserver standen zur Auswahl lighttpd („lighty“) und Apache 2.x.

Entschieden habe ich mich für Apache. Mir ist bewusst das der „Lighty“ angeblich sau schnell ist. Aber wir machen teils sehr komplexe Dinge mit dem Webserver und ich wollte nicht das Risiko eingehen auf einen Webserver zu setzen mit dem ich bisher keine Erfahrungen gesammelt habe. Das war mir dann doch zu viel Arbeit.

Um die Ladezeiten des iPhoneBlog zu optimieren haben wir jede Menge unternommen. Die wichtigsten Kriterien waren/sind dabei: mod_mem_cache, wp_supercache, eacclerator und mod_expires. Auch wollen die werte max_clients und KeepAliveTimeout auf den vorhanden RAM angepasst weden.

In der Grafik wird der Weg geschrieben den jede Anfrage an WordPress geht. Desto weiter nach unten die Anfrage geht desto länger die Ladezeiten. Im „schlimmsten“ Fall muss mysql befragt werden.

Im Idealfall sind die Inhalte bereits im Browser Cache. Um diesen Idealfall möglichst oft zu erreichen bietet sich das Apache Modul mod_expires an. Damit kann man sehr gut steuern wie lange Inhalte zwischengespeichert werden. Eine Konfiguration könnte Beispielsweise so aussehen:

    ExpiresActive On
    # 1 Monat aufheben
    ExpiresByType image/gif A2592000
    ExpiresByType image/png A2592000
    ExpiresByType image/jpeg A2592000
    ExpiresByType application/x-javascript A2592000
    ExpiresByType text/javascript A2592000
    ExpiresByType application/x-shockwave-flash A2592000
    ExpiresByType text/css A2592000
    ExpiresByType application/rss+xml A900
    ExpiresDefault "modification plus 1 hour"

Überprüfen kann man den Erfolg sehr gut mit der Webdeveloper Konsole in Safari. Dort einfach mal einen Blick in die Response Headers werfen. Zu beachten sind die Werte Expires,Cache-Conrol und Pragma.
Dynamische Inhalte wie das HTML der Seite sollten natürlich nach Möglichkeit nicht vom Browser gecached werden.

mod_mem_cache verwenden wir um kleine Bilder, javascripts und Stylesheets im RAM vorzuhalten. Diese sind statisch und werden oft angefragt. mod_mem_cache verhält sich hier übrigens wie ein Browser Cache. Welche Inhalte wie lange und ob überhaupt vorgehalten werden entscheiden die durch mod_expires eingestellten Werte maßgeblich.

 CacheEnable mem /
 # Max Cache size in kb (32 MB)
 MCacheSize 32000
 MCacheMaxObjectCount 2000
 # Least recently used
 MCacheRemovalAlgorithm LRU
 MCacheMinObjectSize 1
 # Max Object size in byte (50kB)
 MCacheMaxObjectSize 50000

Beiträge (html) können nicht so pauschal gecached werden. Hierzu Bedarf es Logik der PHP Anwendung. Wenn man einen neuen Beitrag oder Kommentar verfasst soll der ja nicht erst Minuten später erscheinen, sondern sofort. Glücklicherweise gibt es für WordPress zwei sehr gute Plugins die sich genau hierauf verstehen. wp_cache bildet die Basis und kann in jedem WordPress Blog ohne Probleme installiert werden. wp_super_cache versteht sich als Addon zu wp_cache. Die Super Variante hat ihren Namen deshalb weil hiermit in den meisten Fällen nicht eine Zeile PHP ausgeführt werden muss.

wp_super_cache speichert dazu fertige HTML Seiten in einem Verzeichnis und löscht diese wieder sobald eine Aktualisierung des Inhalts stattgefunden hat. Das diese fertigen HTML Seiten dann auch ausgeliefert werden erfolgt durch mod_rewrite Regeln. Im Prinzip wird einfach nur geschaut ob für die angefragte Seite bereits eine Version im Cache existiert. Wenn dem so ist wird diese ausgeliefert.

# Gekürzter Auszug
RewriteCond supercache/%{HTTP_HOST}/$1/index.html -f
RewriteRule ^(.*) supercache/%{HTTP_HOST}/$1/index.html [L]

Zu WordPress selbst und mysql gibt es nicht viel zu sagen. Als einzige Optimierungsmöglichkeit bleibt hier einen PHP Beschleuniger einzusetzen. Wir verwenden dazu eaccelerator. Eine hervorragende Installationsanleitung für Debian findet sich hier.

Dieses PHP Plugin sorgt dafür das PHP Skripte nur beim ersten Aufruf Interpretiert werden. Der Bytecode der Skripte wird im Speicher vorgehalten. Das bringt ein wenig mehr Tempo. Deutlich reduziert sich jedoch die CPU Last (siehe Grafik).

Um die nötigen mysql Anfragen wenigstens schnell auszuführen Bedarf es einer Beobachtung über einen längeren Zeitraum. Hilfestellungen kann das SKript tuning-primer.sh. Es schaut sich einige Laufzeitvariablen an und gibt entsprechende Vorschläge oder Erklärungen. Sollte man jedoch nicht zu ernst nehmen.

Apache Allgemein

Wir verwenden die Apache Variante mpm_prefork. mpm_worker kommt vielleicht irgendwann. Ist mir derzeit jedoch zu viel Arbeit. Zwei sehr wichtige Parameter die es zu beachten gilt sind KeepAliveTimeout und MaxClients.

Den Keep Alive Timeout möchte man am liebsten sehr hoch haben. Er gibt die Zeit in Sekunden an bevor die Verbindung zu einem Browser beendet wird. Er sollte in jedem Fall nicht kleiner als 2 oder 3 Sekunden sein. Sonst würde ggf. bei langsamen Verbindungen während dem Laden einer Seite die Verbindung immer wieder beendet. Dadurch wird es noch langsamer. 4 Sekunden ist denke ich default und sinnvoll. Wenn man es sich erlauben kann (Kriterien folgen) ist auch ein sehr viel höherer Wert von Vorteil. Viele Besucher lesen einen Artikel kurz einige Sekunden an und besuchen dann eine andere Seite. Wenn dann die Verbindung noch gehalten wird geht das einen Tick schneller. Dies bedeutet jedoch das man mindestens 20 Sekunden rechnen sollte damit jemand davon profitiert. Ein Wert von 10 macht in meinen Augen z.B. keinen Sinn. Dann kann man auch gleich auf 3. Wir haben derzeit 25 Sekunden eingestellt.

Der Wert MaxClients gibt an wie viele Apache Prozesse maximal laufen dürfen. Das ist hauptsächlich eine Frage des vorhanden Arbeitsspeichers. Der RAM Bedarf eines apache Prozesses hängt von den geladenen Modulen und anderen Faktoren ab. Um einen idealen Wert für MaxClients zu finden ist die Faustformel Freier Speicher / RSS Size eines Prozesses. In unserem Fall stehen ungefähr 2 GB für Apache zu Verfügung. Der Speicherbedarf eines einzelnen Prozesses ist etwa 20 MB. Es ergibt sich also ein Wert von 100 (2000 MB geteilt durch 20 MB).

Kommen wir noch mal zurück auf den Keep Alive Wert. Eine Verbindung die gehalten (Keep Alive) wert belegt einen Apache Prozess. Dieser kann solange keine anderen Besucher bedienen. Man benötigt also bei entsprechend hohen Keep Alive Werten auch eine entsprechend hohe Zahl von Max Clients. Zum beobachten verwendet man am besten mod_status. mod_status zeigt wie viele Prozesse gerade frei sind, wie viele im Status Keep-Alive sind, usw…
Sollten einmal keine freien Prozesse zu Verfügung stehen muss der Besucher solange warten. Nicht wünschenswert. Den KeepAlive Wert muss man bei steigenden Besucherzahlen also ggf. anpassen.

---

Ich hoffe ich konnte euch einen kleinen Einblick in meine Welt geben. Hoffentlich kann der eine oder andere davon profitieren. Am tollsten wäre natürlich wenn ihr noch Anregungen oder Fragen in den Kommentaren abgebt. Ich steige gerne in eine Diskussion ein. Ursprünglich wollte ich noch ein paar mehr Dinge ansprechen (z.B. das Monitoring). Aber das wird wohl in einem weiteren Artikel kommen. Ist lang genug geworden.

• Thorsten