Serverlast entgegenwirken (1) – lighttpd statt Apache

Heute möchte ich mit einer kleinen Artikelserie starten, die sich damit beschäftigt, wie man einen Internet-Auftritt derart gestaltet, dass auch große Benutzerzahlen abgefangen werden können. Vor diesem Problem steh ich bei einem aktuellen Projekt und möchte die Gedanken einfach mal in Form von Artikeln festhalten, so dass auch andere mit selben Problem nicht lange suchen müssen.

Serverlast entgegenwirken kann man auf vielerlei Arten. Neben einer sauberen Programmierung und dem Cachen von Seiten ist der Begriff Load-Balancing ein gern genannter Begriff (auf die Technik gehe ich ein andermal ein). Viele vergessen aber das eigentliche Problemkind: den Apache-Webserver.

Das Problem mit diesem Webserver besteht darin, dass es für jeden Request eine eigene (Fork-) Instanz ausführt. Je mehr Besucher eine Website hat, desto mehr Instanzen werden also vom Apache ausgeführt. Da der Speicher eines Servers aber begrenzt ist, können nicht beliebig viele Instanzen ausgeführt werden. Je nach Konfiguration des Web-Servers liefert der Apache also keine Seiten an neue Besucher aus oder er müllt den Speicher derart voll, dass das System praktisch steht.
Eine Alternative stellt der Webserver lighttpd dar. Im Gegensatz zum Apache führt dieser nicht für jeden Request eine eigene Instanz aus und kommt dadurch auch mit einer höheren Besucherzahl passabel zurecht. Wie man in Benchmark-Tests lesen kann, hält sich dieser Vorteil bei einer geringen Besucherzahl in Grenzen (hier ist Apache sogar teilweise schneller), bei hohen bis sehr hohen Anfragen liegt lighttpd aber weit vorne (bzw. Apache macht erst gar nicht mehr mit). Frei übersetzt ist zu hier zu lesen:

Lighttpd fängt ab 800 Anfragen an, merkwürdig zu reagieren, während Apache bereits bei 50 Anfragen zu schwächeln beginnt […] und bei 250 gleichzeitigen Anfragen nicht mehr reagierte.

Lighttpd nutzt dabei die FastCGI-Schnittstelle für PHP, Ruby und Co. und bietet nahezu alle wirklich relevanten Module wie URL_Rewrite (inkl. regulären Ausdrücken), output-Kompression, etc.

Sehr interessant ist dazu noch die sehr intelligente Cache-Funktion des Webservers, der die Aktualität des Caches auch anhand von MySQL-Abfragen (!!) kontrollieren kann. So stehen (im Vergleich zu PHP) extrem schnelle Cache-Funktionen zur Verfügung:

  • Modellierung der selben Abhängigkeiten wie in PHP
  • Treffen einer Cache-Entscheidung (auch mittels MySQL)
  • direktes Ausliefern des Cache-Inhalten bei einem Cache-Hit
  • Aufrufen des PHPs bei einem Cache-Hiss, zum Auffrischen des Cache-Inhaltes
  • Zusammenführen von mehrere Content-Fragmenten

Alles in allem ist lighttpd eine sehr interessante Alternative für den Apache-Webserver, wenn es auf Skalierbarkeit ankommt. Leider sind die typischen Apache-Einstellungen nicht übernehmbar, so dass mod_rewrite-Regeln entsprechend umgebaut werden müssen. Sollte man aber von vornherein mit einem großen Projekt rechnen, so ist der Server auf jeden Fall einen Blick wert.

[Update]

Sehr interessant ist auch ein Artikel im TextDrive-Weblog: nach einer Verlinkung von Slashdot wurde der Blog und damit der Server stark beansprucht. Auf der Grafik kann man schön sehen, wie sich der Apache im Vergleich zum lighttpd bei gleichbleibender Besucherzahl verhält.

16 Gedanken zu „Serverlast entgegenwirken (1) – lighttpd statt Apache

  1. Hmm, … das wirkt sehr interessant und auch attraktiv, aber ein Problem welches sich mir jetzt stellt:

    Ich habe einen laufenden Apache2 auf Suse 9.3, …
    und “nur” einen vServer.

    Wie kann ich diesen ohne deutliche Ausfälle nun umstellen?

    Bei durchgehend mehreren Hundert Usern online wäre das nämlich der einzigste Grund, wegen welchem ich noch nicht umgestiegen bin.

  2. Hmmm, hoert sich interessant an. Noch zoegere ich etwas, da ich den Indianer einfach mag… Allerdings geht der Server-Load bei mir teilweise bis > 60 hoch! 🙁 Upps, ja, sehr viel. 🙂 Komischerweise hat sich das gelegt, nachdem ich dieses Mini-Script nun regelmaessig ausfuehren lasse:

    #!/bin/sh

    AMOUNT=`ipcs -s | grep www-data | sort --unique | grep "" --count`

    if test $AMOUNT -gt 10; then
    /etc/init.d/apache2 stop
    sleep 1
    kill -kill `pidof apache2 php5-cgi`
    sleep 1
    kill -kill `pidof apache2 php5-cgi`
    sleep 1
    ipcs -s | grep www-data | perl -e 'while () {@a=split(/\s+/); print `ipcrm sem $a[1]`}'
    sleep 1
    /etc/init.d/apache2 start
    fi

    Ist aber mit Sicherheit nur eine Notloesung… Ich denke mal drueber nach, ob ich den Wechsel mache. 🙂 Bin recht gut in Debian betagt. Zu Hause auch nur Debian im Einsatz (0% Windows).

    Jedenfalls bin ich es gruendlich satt, mich per SSH einzuloggen, zu su-hen und dann “kill -kill `pidof apache2 php5-cgi`” (ich nutze schon den Worker) einzugeben, um anschliessend wieder “/etc/init.d/apache2 start” einzugeben. Ich kann ja nun nicht die ganze Nacht “Wache” am Server halten, ob der Load wieder +30 geht… 🙁

    Aber wie schon gesagt, das kleine Script wirkt ware Wunder! 😉 Habe ich wo im Netz (Google) gefunden.

  3. Ja, ich verwende es. Aber (leider) in einer abgewandelten Fassung. Vor einigen Wochen ging der Load auf ueber 120 (!!!) und das ist langsam toedlich fuer Linux.

    Nun ist der Load auf 0.00. Sieht schoen aus, ist es aber nicht. Der Web-Server ist auch nicht mehr erreichbar und ich darf weiterhin das Kill-Script (in einer geaenderten Fassung) alle 3 Stunden ausfuehren, damit mein Server erreichbar bleibt. 🙁

    Die bei Apache sollten mal an Stabilitaet denken, das ist naemlich ziemlich laestig, jeden Tag mal einen Load von 120 oder von 0 zu haben…

  4. Interessanter Artikel – nur wird eine Sache vergessen: Apache bietet einige nette Funktionen, die sich auf lighttpd oder nginx nur umständlich umsetzen lassen, so zum Beispiel mod_rewrite (die Rules müssten für lighty umgeschrieben werden) oder mod_uploadprogressbar.

    Apache verwendet standardmäßig das mpm_worker Modul – ähnlich wie bei lighttpd wird hier *nicht* für jeden Request eine eigene Instanz gestartet. Erst wenn PHP hinzukommt, springt Apache um auf das veraltete mpm_prefork Modul, welches noch aus Apache1-Zeiten stammt. Dann treten die Probleme auf, die im Artikel beschrieben wurden.

    Kompiliert man den Apache selbst, kann man ohne Probleme mpm_worker auch mit PHP verwenden. Und ob sich dann der Einsatz von lighttpd noch lohnt, ist die eigentlich interessante Frage. Falls jemand dazu mehr Infos hat, wär ich sehr dankbar… 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.