Debian: Von Apache zu Nginx – Teil 1: Vorwort

Übersicht

 

In diesem und den folgenden Beiträgen (es gibt jeden Tag einen) berichte ich euch ein wenig über meine Migration von Apache zu Nginx. Es war eigentlich nicht beabsichtigt, dass da ganze fünf Beiträge draus werden, aber irgendwie wurde es doch ziemlich viel Text und das war dann für einen einzelnen Artikel etwas zu viel. Da könnte man ja fast den Eindruck bekommen, ich würde gerne schreiben … Keine Angst, das einzige was ich gerne in großen Mengen schreibe ist Programmcode ;)

However, ich hatte meinen VPS (Debian 6) bisher immer mit dem apache2 betrieben und auch meine Entwicklungsumgebung auf meinem Desktop und dem Notebook ebenfalls. Das hatte mehrere Gründe. Zum Einen bin ich mit dem Apache aufgewachsen und hatte eigentlich nie etwas anderes verwendet. Ich war auch immer sehr zufrieden mit dem Apachen. Es ist ein guter Webserver mit einer großen Auswahl an mächtigen Modulen und er ist sehr leicht zu konfigurieren. Da ich aber ab und an gerne etwas Neues ausprobiere und immer Spaß daran habe, an meinem Server zu schrauben (auf Software-Ebene), wollte ich mal einen anderen Webserver ausprobieren. Genaugenommen war das Projekt yaana.de einer der Auslöser. Ich möchte da noch etwas Performance aus dem Server quetschen. Und dafür sollte ich mich zu allererst vom Apachen verabschieden.

Zur Auswahl stehen also – neben dem Apachen – Lighttpd und Nginx (ausgesprochen: engine-x).

Zu allererst ein kurzer Überblick der Vor- und Nachteile der drei Kontrahenten: Apache, Lighttpd und Nginx:

Der Apache

Vorteile

  • Open Source & Kostenlos
  • Community. Apache ist der am meist verbeiteste Webserver, die Community dahinter ist entsprechend gigantisch.
  • Module. Es gibt unzählige Module für den Apache um praktisch jede Funktionalität abzudecken

 

Nachteile

  • Performance. Der Apache ist um einiges langsamer als seine Konkurenten. Vor Allem wenn es um das Ausliefern von statischen Dateien geht.
  • Stabilität. Der Webserver hat schon mit schwachen DoS/DDoS Attacken Probleme, der Arbeitsspeicher (und das Logverzeichnis) verbrauchen innerhalb kurzer Zeit viel Speicher.
  • Veraltet und überfüllt. Außerdem ist die Standard Konfiguration meistens nicht optimal und muss angepasst werden.
  • Die Entwicklung läuft vergleichsweise langsam.

 

Der Lighttpd

Vorteile

  • Open Source & Kostenlos
  • Leichtgewichtig. In Version 1.4.13 benötigt der Lighty nicht mehr als 2Mb RSS auf einem VPS. Ein einzelner Prozess erledigt alles, selbst wenn 100 Connections eingehen.
  • Geschwindigkeit. Die Auslieferung von statischen Dateien geschieht mit einer unglaublichen Geschwindigkeit. Das FastCGI und das Proxy Serving ist ebenfalls rasant schnell.
  • Module. Es gibt gefühlt unendlich viele Module mit einer guten Dokumentation.
  • Mod_magnet ist eine Scripting Engine direkt im Webserver. Das Modul integriert Lua in lighttpd.
  • Community. Einen Blog, ein Wiki/bug tracker und ein Forum. Hier findet man immer Hilfe

 

Nachteile

  • Geringe Stabilität gerade was HTTPS+Proxy in Kombination mit Python oder Ruby angeht.
  • Kein Mod_rewrite. Die Built-in rewriting engine ist Schrott, und das Portieren der Apache mod_rewrite Regeln ist nicht ganz einfach.
  • Memory leaks. Und diese wurden seither nicht gefixed.
  • Die Entwicklung läuft vergleichsweise langsam.

 

Nginx

Vorteile

  • Open Source & Kostenlos
  • Leichtgewichtig. Zwar nicht ganz so leicht wie der Lighty, aber dennoch nicht so Ressourcenhungrig wie der Apache.
  • Schnell. Einie benchmarks haben gezeigt, dass Nginx deutlich schneller ist als der Lighty und der Apache. Gerade was die Auslieferung von statischen Inhalten angeht.
  • Module. Ähnlich wie bei den beiden anderen Kontrahenten gibt es auch hier mehr Module als man benötigt. Während Lighttpd eine Lua scripting engine besitzt, kann man den Nginx mit dem Perl Interpreter aufmotzen.
  • Besseres Rewrite Modul. Ein sehr viel besseres Rewrite Modul als Lighttpd mit komplexen Bedinungen. Das Portieren von mod_rewrite Regeln vom Apache ist vergleichsweise einfach.
  • Stabil und keine leaks. Keine Probleme bekannt.
  • Sehr schnelle Entwicklung: Es gibt fast monatlich Updates
  • Die Konfiguration ist einfach und übersichtlich.

Nachteile

  • Kleine Community. Es gibt einen IRC und ein Wiki. Dann wirds auch schon eng.
  • Nginx kann keine FastCGI Prozesse erstellen. Das muss dann über einen externen fcgi spawner geschehen.

 

Der Lighttpd kam bei mir eigentlich nie wirklich in Frage. Das hatte zwei Gründe:

  1. Ist die Konfiguration wirklich hässlich :( Sorry aber ich bin da etwas sensibel.
  2. Weil der Lighttpd ein paar Memory Leaks hat, die seit Jahren nicht gefixt werden.
  3. Hatte ich mir bereits vor längerer Zeit die Rewrite Rules vom Lighty angesehen – eher durch Zufall darauf gestoßen und dann aus Neugierde recheriert – das hat mich direkt abgeschreckt.

Also fällt auf meine Wahl auf den hochangepriesenen Nginx Proxy-/WebServer, mit dem mittlerweile rund 7% des World Wide Webs betrieben werden. Darunter high-visibility Platformen wie WordPress.com, Github, Ohloh, SourceForge, Golem.de uvm. Außerdem verspricht dieser nicht nur mehr Performance sondern auch eine einfachere Konfiguration.

Auch wenn mich der Part mit dem FastCGI Prozessen etwas nerven wird. Mal sehen vielleicht finde ich dafür ja noch eine saubere Lösung.

 

Anforderungen

Ich habe natürlich einige Anforderungen an den Webserver. Damit ich meinen Server migrieren kann, benötige ich folgende Funktionen:

  • RewriteRules für .htaccess files
  • Basic Authentication
  • Virtuelle Hosts
  • PHP
  • Einen Proxy um den Java Webserver dahinter anzubinden

Nginx ist nicht nur ein Webserver sondern auch ein POP3/IMAP-Proxy und ein reverse Proxy. Letzteres Problem war also schonmal gar kein Thema weil der Server einfach exakt für solche Dinge designed wurde. Auch Mongrel lässt sich sehr sehr gut mit Nginx betreiben, wie ich gelesen habe.

PHP lässt sich über FastCGI anbinden, was deutlich performanter ist als mod_php für den Apachen, da PHP somit nicht bei jedem Request mitgestartet wird. Was mir hier noch etwas Sorgen bereitet, ist das nicht vorhandene Feature vom Nginx, FastCGI Prozesse zu starten. Glücklichwerweise bringt PHP5 einen eigenen FastCGI Prozess Manager mit sich: PHP-FPM. Das erleichtert die Anbindung von PHP ungemein.

Virtuelle Hosts, Basic Authtentication und RewriteRules sind für moderne Webserver ohnehin bereits Standardumfang. Und die Rewrite Rules von Nginx sehen sogar ganz brauchbar aus (wenn es um das Portieren von  mod_rewrite Regeln geht). Sollte also alles kein Thema sein.

Bleibt noch eine kleine Anforderung: Die Verzeichnis-Struktur. Meine bisherige Verzeichnis-Struktur sieht wie folgt aus:

/var/www/hostname/subdomain/

Entsprechend gibt es folgende Verzeichnisse:

  • /var/www/itws.de/blog
  • /var/www/itws.de/ci
  • /var/www/yaana.de/www
  • /var/www/yaana.de/blog

Und einige mehr.

Diese Struktur will ich natürlich beibehalten. Es hätte mich nun gewundert, wenn das nicht gehen würde. Nach kurzer Recherche, war ich mir sicher, dass das kein Thema sein wird.

 

Es kann also los gehen.

Ähnliche Artikel

3 Comments to “Debian: Von Apache zu Nginx – Teil 1: Vorwort”

Post comment

last movies