nodomain.cc » lighttpd

Mit SysCP den lighttpd killen

ff — Sat, 02 Aug 2008 10:49:29 +0000

Nachdem fr1tz gestern für ein Verzeichnis zwei verschiedene Benutzernamen einrichten wollte (htaccess), ist der Webserver mit folgender Meldung nicht mehr gestartet:

Duplicate config variable in conditional 85 global/HTTPhost==privat.fr1tz.de/HTTPurl=~^/: auth.backend
2008-08-01 20:08:08: (configfile.c.827) source: /etc/lighttpd/syscp-new.php line: 739 pos: 31 parser failed somehow near here: (EOL)
2008-08-01 20:08:08: (configfile.c.827) source: /etc/lighttpd/lighttpd.conf line: 174 pos: 27 parser failed somehow near here: (EOL)
failed!

Ein

GROUP BY `panel_htpasswds`.`path`

in der syscp-new.php im Verzeichnisschutz-Abschnitt schafft hier Abhilfe. Dann gewinnt halt der mit der kleineren ID

Ich wollte ja heute morgen wieder auf Apache2 umstellen aber als ich dann festgestellt habe wie lahm alles wird habe ich alles schnell wieder rückgängig gemacht und mir die lighttpd-Config vorgenommen.

Mit SysCP den lighttpd killen is a post from: nodomain.cc

Rewrite-Regeln für Serendipity und lighttpd

ff — Thu, 14 Feb 2008 00:22:56 +0000

Gerade durch Zufall entdeckt: Statt die komplette Latte von Rewrite-Regeln für Serendipity auf lighttpd-Syntax anzupassen genügt folgender simpler Eintrag:

## vhost settings
$HTTP["host"] =~ "(nodomain.cc|blog.anderedomain.de)" {
url.access-deny = ( ".tpl", ".inc.php", ".sql", ".db" )
server.error-handler-404 = "/index.php"
}

Der access-deny-Eintrag sorgt dafür, dass ein paar "wichtige" Systemdateien nicht abgerufen werden können und die zweite Zeile definiert die index.php als Error-Handler. Danach noch in S9Y "apache Error-Handler" für "rewrite URLs" aktivieren und das wars.
Nebenbei kann man mit diesem Eintrag alle Domains auf dem Server, auf denen eine Instanz von Serendipity läuft, auf einmal abdecken

Feine Sache das.

Rewrite-Regeln für Serendipity und lighttpd is a post from: nodomain.cc

500er Fehler im Blog

ff — Mon, 11 Feb 2008 22:54:13 +0000

In letzter Zeit häufen sich die Zeiten, in denen hier statt den gewohnten Inhalten lediglich ein "500 Internal Server Error" zu sehen ist. Das passiert deswegen, weil mein lighttpd auf einmal nicht mehr über fastcgi mit PHP sprechen möchte weil er folgendes glaubt:

Feb 9 11:15:32 hermes lighttpd[21881]: (mod_fastcgi.c.2819) backend is overloaded, we disable it for a 2 seconds and send the request to another backend instead: reconnect
s: 0 load: 90

Ich bekomme das Problem nur über einen Neustart von lighttpd und (vorsichtshalber) einem erneuten Starten der fastcgi-Childs in den Griff.
Ich habe versucht der Sache auf den Grund zu gehen und bin auf diese Bugs gestoßen: lighttpd-Ticket 575, Ticket 1488 und evtl. auch PHP-Bug 43610. Als Workaround wird vorläufig der lighttpd per Cron stündlich neu gestartet. Das ist unschön und ich hoffe auf eine baldige Behebung der/des Bugs.

Habt also ein klein wenig Nachsicht wenn hier mal wieder nur was mit 500 steht...

500er Fehler im Blog is a post from: nodomain.cc

lighttpd: HTTPS erzwingen

ff — Tue, 26 Jun 2007 09:01:35 +0000

Da manche Anwendungen bei Aufruf über HTTPS nicht immer Links generieren, die mit https:// beginnen, sollte man solche "falschen" Anfragen im Webserver umleiten, da ansonsten Teile der Website nicht verschlüsselt übertragen würden.
Bei lighttpd geht das ganz einfach:

$SERVER["socket"] == ":80" {
$HTTP["host"] =~ "example.org" {
url.redirect = ( "^/(.*)" => "https://example.org/$1" )
server.name = "example.org"
}
}
$SERVER["socket"] == ":443" {
ssl.engine = "enable"
ssl.pemfile = "/path/to/example.org.pem"
server.document-root = "..."
}

[Quelle]

lighttpd: HTTPS erzwingen is a post from: nodomain.cc

Nochmal die Performance

ff — Sun, 17 Jun 2007 18:55:48 +0000

Ich habe es vorhin ja bereits angedeutet, Micha weiß dazu noch mehr:

ist hier der Vorspung von lighttpd deutlicher, er verarbeitet ca 10% mehr Anfragen pro Sekunde als der Apache. Richtig Würze kommt aber auch hier erst ins Spiel wenn der PHP Opcode Cache XCache verwendet wird. Er bringt in jedem Fall eine Steigerung von 150%. Geht man davon aus, dass eine Migration von Apache zu lighttpd inkl. XCache erfolgt, beträgt die Steigerung sogar 170%.

In den Kommentaren steht u.a. auch, dass man speziell bei Serendipity das Statistik-Plugin deaktivieren sollte, da es Performance frisst.

Ich habe heute mittag übrigens eAccelerator durch XCache ersetzt.

Nochmal die Performance is a post from: nodomain.cc

Benchmark: lighttpd, fastcgi, PHP5 ohne eAccelerator

ff — Sun, 17 Jun 2007 13:55:12 +0000

Ohne eAccelerator sieht die Sache schon anders aus: der Serverload steigt bis auf 10.9 und die durchschnittliche Antwortzeit ist wesentlich höher als mit eAccelerator. Auch wenn ich diesen Benchmark nicht so lange habe laufen lassen wie den anderen bietet er doch eine deutliche Aussage:

Transactions: 1376 hits
Availability: 100.00 %
Elapsed time: 178.21 secs
Data transferred: 87.46 MB
Response time: 1.42 secs
Transaction rate: 7.72 trans/sec
Throughput: 0.49 MB/sec
Concurrency: 10.97
Successful transactions: 1251
Failed transactions: 0
Longest transaction: 24.40
Shortest transaction: 0.03

Die Transaction rate ist bedeutend geringer und die durchschnittliche Antwortzeit ca. 1.2 Sekunden schlechter.
Jetzt dürft ihr euch selbst die Meinung bilden

Benchmark: lighttpd, fastcgi, PHP5 ohne eAccelerator is a post from: nodomain.cc

Benchmark: lighttpd, fastcgi, PHP5 mit eAccelerator

ff — Sun, 17 Jun 2007 13:41:49 +0000

Ich habe mit siege die aktuelle Konfiguration getestet und ich bin überaus positiv überrascht. Ich habe leider keinen passenden Vergleich mit Apache vorliegen, ich kann mich aber erinnern, dass dieser bei weitem nicht so performant war wie lighttpd.

Der Serverload hält sich in Grenzen: zwischen 2.5 und 3.8, kurzzeitig 6.1. Das Blog verhält sich während des Lasttests völlig normal, man bemerkt kaum, dass der Server "mal was zu tun hat".

Das Ergebnis kann sich meiner Meinung nach sehen lassen:

Transactions: 10943 hits
Availability: 100.00 %
Elapsed time: 608.61 secs
Data transferred: 706.97 MB
Response time: 0.33 secs
Transaction rate: 17.98 trans/sec
Throughput: 1.16 MB/sec
Concurrency: 6.02
Successful transactions: 10157
Failed transactions: 0
Longest transaction: 17.09
Shortest transaction: 0.03

Basis dieses Benchmarks war eine von mir zufällig zusammengestellte urls.txt mit URLs aus dem Blog, siege hat mit 15 concurrent users getestet. Momentan lasse ich es noch mit 25 laufen und danach wird eAccelerator abgestellt. Der Server ist ein 1und1 L64 mit AMD Athlon 64X2 3800+ und 1GB RAM.

Benchmark: lighttpd, fastcgi, PHP5 mit eAccelerator is a post from: nodomain.cc

Umstieg auf lighttpd

ff — Sat, 16 Jun 2007 22:46:43 +0000

Ich hatte es schon länger vor und nun habe ich es endlich hinbekommen: Apache ist tot, es lebe lighttpd mit php-fastcgi. Diese Kombination ist wesentlich performanter und bedeutet weniger Overhead als Apache.

Ein paar Eckdaten:
- lighttpd mit mod_fastcgi
- "per User"-Konfiguration, die wie suPHP die PHP-Prozesse unter der Userkennung des jeweiligen vHosts ausführt
- kein Safe-Mode und kein open_basedir nötig
- integriert in Syscp, keine Änderungen an Syscp nötig

Die Migration eines laufenden Systems mit Apache, Syscp und suPHP gestaltet sich relativ einfach, wenn man dieser Anleitung folgt. Mit diesem Skript gelingt das Ganze sogar ohne Änderungen an Syscp. Als Voraussetzung müssen die Fastcgi-Startskripte und die benötigte Verzeichnisstruktur erstellt werden, so wie es hier beschrieben ist.

Achtung: die Logs unter /var/log/apache2 müssen für den lighttpd schreibbar gemacht werden (Gruppe anpassen oder chmod) und für eine Benamung der (eigentlich) virtuellen User von Syscp benötigt man den nscd sowie ein paar kleine Änderungen am System, die ich bei Nachfragen hier gerne noch raussuchen werde.

Rewrite-Rules für Serendipity finden sich hier. Diese müssen einfach als Konfiguration für den S9Y-Vhost hinzugefügt werden.

Jetzt kann der Heise-DoS kommen

edit:// nun funktioniert auch der Verzeichnisschutz...

Umstieg auf lighttpd is a post from: nodomain.cc