Hier nun der versprochene Benchmark meines VPS. Einmal mit Apache und das Gleiche nochmal mit dem Nginx.
Der Geschwindigkeitsvorteil ist klar zu sehen (Bedenke: Es war eine kleine Datei, daher sind die Werte generell recht klein). Auch das arbeiten auf den Systemen auf meinem Server fühlt sich deutlich performanter an. Hat sich also gelohnt

Apache

Document Path:          /test.html
Document Length:        169 bytes

Concurrency Level:      5
Time taken for tests:   19.938 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      463000 bytes
HTML transferred:       169000 bytes
Requests per second:    50.16 [#/sec] (mean)
Time per request:       99.690 [ms] (mean)
Time per request:       19.938 [ms] (mean, across all concurrent requests)
Transfer rate:          22.68 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       45   49   2.3     49      75
Processing:    47   50   3.5     50      84
Waiting:       47   50   3.4     49      84
Total:         93  100   4.5     98     141

Percentage of the requests served within a certain time (ms)
  50%     98
  66%    100
  75%    100
  80%    101
  90%    103
  95%    109
  98%    113
  99%    120
 100%    141 (longest request)

Nginx

Document Path:          /test.html
Document Length:        169 bytes

Concurrency Level:      5
Time taken for tests:   19.090 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      379000 bytes
HTML transferred:       169000 bytes
Requests per second:    52.38 [#/sec] (mean)
Time per request:       95.450 [ms] (mean)
Time per request:       19.090 [ms] (mean, across all concurrent requests)
Transfer rate:          19.39 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       45   47   1.4     46      65
Processing:    47   49   1.2     49      60
Waiting:       47   49   1.2     48      60
Total:         92   95   2.0     95     115

Percentage of the requests served within a certain time (ms)
  50%     95
  66%     95
  75%     96
  80%     96
  90%     97
  95%     98
  98%    100
  99%    102
 100%    115 (longest request)

Im Zuge meiner Umstellung von Apache auf Nginx mussten auch vier WordPress-Installationen migriert werden. Interessant dabei waren in erster Linie die Permalinks zu erhalten (und damit die RewriteRules zu portieren).

Da es sich um vier voneinander unabhängige WordPress-Installationen handelt und ich die Server Config DRY halten möchte, gibt es für die WordPress-spezifischen Sachen mal wieder eine include Datei:

# vim /etc/nginx/wordpress.inc

rewrite ^(/[^/]+/)?files/(.+) /wp-includes/ms-files.php?file=$2 last;

rewrite ^(/[^/]+)?(/wp-.*) $2 last;
rewrite ^(/[^/]+)?(/.*\.php) $2 last;

rewrite ^/(.*)$ /index.php?q=$1 last;

if (!-e $request_filename) {
        rewrite ^(.+)$ /index.php?q=$1 last;
}

Nun müssen die VHost-Konfigurationen noch entsprechend um ein Include erweitern werden:

# blog.itws.de
server {
        server_name blog.itws.de;
        root /var/www/itws.de/blog;

        include defaults.inc;
        include enable_php.inc;
        include wordpress.inc;
}

Fertig. Wie ihr sehen könnt, an sich also kein Hexenwerk.

Übersicht

• Teil 1: Vorwort
• Teil 2: Installation und Konfiguration
• Teil 3: PHP
• Teil 4: Einen Tomcat anbinden
• Teil 5: Basic Authentication

Wie im ersten Teil beschrieben, muss ich ein paar meiner VHosts per Basic Authentication schützen. Hier zeige ich euch noch kurz, wie ich das mit nginx angestellt habe.

In meinem Fall möchte ich die Subdomain ci.itws.de schützen. Dazu lege ich mir erstmal ein Verzeichnis auth an, in dem ich die htpasswd-Dateien speichere:

# mkdir /etc/nginx/auth

Und ich lege mir einen Benutzer an:

# htpasswd -c /etc/nginx/auth/ci ghost

Danach muss ich nur noch den server-Block in der Datei /etc/nginx/sites-available/itws.de anpassen:

server {
    server_name ci.itws.de;
    root /var/www/itws.de/ci;

    include defaults.inc;
    include enable_php.inc;

    auth_basic  "ITWS CI";
    auth_basic_user_file auth/ci;
}

Fertig. Nach einem schnellen Restart von Nginx ist ci.itws.de per BA geschützt.

Übersicht

• Teil 1: Vorwort
• Teil 2: Installation und Konfiguration
• Teil 3: PHP
• Teil 4: Einen Tomcat anbinden
• Teil 5: Basic Authentication

Ich möchte den Nginx auch auf meinem Notebook verwenden um dort die gleiche Umgebung wie auf dem Server zu haben. Und auch die gleiche Performance.

Da ich aber in der Firma mit dem Tomcat arbeite (den ich zur Zeit über mod_proxy an den Apachen angeklingt habe), muss ich meinen Nginx auch entsprechen konfigurieren. Da die Proxy-Funktionen im Nginx kein Modul sind, sondern der Nginx selbst ein Proxy-Server ist, ist das spielend einfach:

server {
    server_name ci.itws.de;
    root /var/www/itws.de/ci;

    index index.jsp index.html index.htm;

    proxy_pass http://localhost:8080;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
}

Übersicht

• Teil 1: Vorwort
• Teil 2: Installation und Konfiguration
• Teil 3: PHP
• Teil 4: Einen Tomcat anbinden
• Teil 5: Basic Authentication

Installation

# apt-get install php5 php5-cli php5-cgi php5-suhosin php5-fpm

# /etc/init.d/php5-fpm restart

Übersicht

• Teil 1: Vorwort
• Teil 2: Installation und Konfiguration
• Teil 3: PHP
• Teil 4: Einen Tomcat anbinden
• Teil 5: Basic Authentication

Installation

Um eine aktuelle Version (1.0.6) auch unter Debian zu bekommen, kann man einfach das dotdeb Repository in die sources.list aufnehmen:
dotdeb.org bietet ein umfangreiches Repository um Debian Systeme in perfekte LAMP Server zu verwandeln. Hier ist nicht nur die aktuelle Version von PHP 5.3 mit dem FPM, den ich später noch brauchen werde, sondern auch die aktuelle Version des nginx zu finden. Außerdem ist die Default-Konfiguration des Nginx aus dem dotdeb Repo etwas sauberer als die aus dem offiziellen Debian Nginx Repo …
(weiterlesen …)

Übersicht

• Teil 1: Vorwort
• Teil 2: Installation und Konfiguration
• Teil 3: PHP
• Teil 4: Einen Tomcat anbinden
• Teil 5: Basic Authentication

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).

(weiterlesen …)

Auf Github findet ihr im Projekt itws/dotfiles meine Linux config Dateien. Im Moment liegen dort nur die configs für die ZSH und git, wird aber  noch mehr

Nein, natürlich hasse ich weder Nils noch seinen Blog.

Was mich aber stört, ist das PHM Network. Prinzipiell eine sehr gute Idee die Beiträge aller guter PHP Blogs zu aggregieren. Aber einen Nachteil hat es: Dadurch tauchen alle Artikel von Feeds, die ich ohnehin schon im RSS Reader habe, auch im RSS Feed von phphatesme.com auf. Das bedeutet, ich markiere einige Beiträge doppelt als gelesen.

Vorschlag meinerseits: Die PHM Network Beiträge nur im Blog darstellen, aber nicht im RSS Feed und somit die Nerven der Entwickler schonen, die über den RSS Reader lesen

Und direkt mal 3 Repos erstellt. Eins für mein Backup-Script, eins für die ITWS PHP Tools und eins für YAP, mein Projektmanagement System.

Mal sehen wann ich neben yaana.de Zeit für YAP finde