Das war doch mal wieder eine lustige Fehlersuche. Begonnen hat alles mit unerklärbaren Zeitsprüngen bei Lasttests auf meinen apache Webserver: Wenn ich ein "siege" auf eine meiner Seiten abgefeuert habe um Performance Optimierungen zu testen, hatte ich immer mal einzelne Anfragen, die von ein paar Millisekunden Anwortzeit auf 5 Sekunden (5 seconds) plus ein paar Millisekunden hochgesprungen sind. Der Effekt war nicht deterministisch, trat manchmal bei ein paar Requests hintereinander auf, dann aber auch mal ein paar hundert Requests lang gar nicht.

Also macht Admin sich an die Fehlersuche, wie das wohl entstehen könnte. Zunächst habe ich diverse Parameter in meinem fcgi Environment durchprobiert, bis sich herausstellte, dass der Effekt auch auftritt, wenn statische Dateien abgerufen werden, fcgi damit also nix zu tun hat. Also apache zerlegen, mal ein anderes mpm modul ausprobieren ... auch kein Erfolg.

Einige google Quälereien (ohne Erfolg) später hab ich dann mal in einem siege für die zu testende Adresse eine IP-Adresse statt eines Domain Names eingetragen. Siehe da, der Delay trat nicht mehr auf.

Folglich war ich bei einem grundlegenden DNS-Problem meiner Maschine gelandet. Da ich siege immer lokal laufen lasse um Netzwerklatenzen zu vermeiden, habe ich in /etc/resolv.conf mal nach Parametern gesucht, die einen Timeout begrenzen:

options timeout:1

Erfolg: Mein Delay hat sich auf 1 Sekunde verkürzt. Stellt sich also heraus: Von den in der resolv.conf eingetragenen Nameservern antwortet mindestens einer nicht immer auf Anfragen. Die lokale Namensauflösung läuft deshalb per default nach 5 Sekunden in einen Timeout, stellt die Anfrrage erneut, erhält dann meist eine Antwort, und ist glücklich.

Fazit: Die oben genannte Option kann ich jedem Anwender als Eintrag in der resolv.conf empfehlen, wenn ein upstream Nameserver aus irgendwelchen Gründen einfach mal die Antwort verschlampt. So verkürzen sich die Wartezeiten wenigstens ;) Vielleicht würde ein lokaler Name Service Caching Daemon das Problem ebenfalls meistens unterdrücken.

In eigener Sache: Nach viel Basteln, Fluchen, Heulen und Stricken sind schwarzbu.ch und ein paar andere Domains auf einen neuen Server umgezogen. Da bereits vor der Produktivschaltung so ziemlich alles ausgefallen ist was ausfallen kann (beide Raidplatten und Motherboard), gehe ich davon aus, das die Maschine nun erstmal die naechsten 42 Jahre reibunglos einfach so vor sich hin funktioniert. Schamlose Werbung: Der Rootserver Support bei Hetzner funktioniert sehr zuegig, zuverlaessig und unbuerokratisch. Diese Wahl habe ich bisher nie bereuen muessen.

Das System ist ein Debian stable (etch), mit diversen lustigen Diensten. Ein klein wenig stolz bin ich auf den Mailserver (postfix+cyrus ueber cyrus-sasl an openldap), der zunaechst mal alle meine Beduerfnisse erfuellt. Vielleicht schaffe ich es in den naechsten Wochen eine halbwegs anstaendige HowTo online zu bringen. Das waere allein schon fuer meine persoenliche Dokumentation dankenswert. Das Script imapsync hat dabei locker eine halbe Millionen Mails allein fuer meine Account uebertragen. imapsync ist fuer einen IMAP-Mailbox-Transfer eine feine Sache, lediglich der Speicherverbrauch kann etwas ausarten (ich hatte bis zu 1,5GB bei ca. 200k Mails).

schwarzbu.ch selbst war als Typo3 Installation angenehm schmerzfrei zu uebertragen, wegen temporaer sehr kurzer DNS Cache Zeiten sind keine Datendifferenzen aufgetreten. Nach vorherigen Messungen sind die Parsezeiten des ganzen Typo3-php-Mueslis etwa halbiert gegenueber der alten Maschine, das merkt man besonders im Backend. Ich hoffe die Webseiten fuehlen sich auch etwas schneller an, und es bleibt Luft fuer mehr Zugriffe.

Einige Details fehlen noch, insbesondere die Suche laeuft noch nicht wieder so wie sie soll. Fuer diese Nebensaechlichkeiten ist vielleicht bei dem ein- oder anderen Feierabendbier mal Zeit ;)