Technik

Da sich das alte Dictionary was wir momentan für unseren Mailserver zum Auflösen der E-Mail-Adressen unter Last als wahrer Flaschenhals erwiesen hat, habe ich gestern endlich mal angefangen ein eigenes, auf unsere Bedürfnisse zugeschnittenes Dictionary zu schreiben.

Die alte Version war im Prinzip nur das (wenn man so will) Umbiegen von Bordmitteln eines jeden Postfixes auf unser System.

Zugegeben: Das war mit unter recht schmerzhaft anzusehen, aber es hat jetzt einige Jahre sehr gut funktioniert...

Das neue Dictionary ist hingegen komplett anders: Es ist nur bei uns lauffähig, weil es auch nur mit unserer Datenbank spricht. Weiterhin ist es eine komplett eigene Implementation in C, die neben dem Standard-Lookup auch noch so Spielereien wie das Caching (unserer) Domains übernimmt. Im ersten Test war die neue Lösung ca. 10 mal schneller als die alte :eek:

... wobei sich das im Regelbetrieb (dank des Cachings) nochmal verbessern dürfte...

Ich hoffe mal, dass ich heute Nacht die ersten Produktiv-Tests starten kann

Ich habe eigentlich schon richtig lange nichts mehr daran verändert... Die großen Änderungen kamen direkt nach dem "Release" hier:

mod_dvb kann jetzt aus seiner channels.conf eine Playlist generieren, die in Verbindung mit mplayer (etc.) richtig Spass macht - Stichwort: Zapping.

In Verbindung mit der Playlist eigentlich schon ein Muss: mod_dvb kann jetzt auch die PID's von Audio- und Video-Stream umschreiben, sodass diese auch im Player statisch eingestellt werden können (gab da paar Probleme mit älteren Versionen von mplayer)

Ansonsten wartet mod_dvb jetzt auch gerne ein wenig, bis das DVB-Device freigegeben wurde - zumal vorangegangene Prozesse erstmal realisieren müssen, dass ihre Verbindung geschlossen wurde

Zum Download gibts das ganze hier...

Nach dem plötzlichen Festplatten-Tod von gestern habe ich einen weiteren Ausfall zu beklagen:

Den Boot-Manager von meinem iPod nano hats verrissen nachdem ich ihm im RZ an meinem Laptop aufgeladen habe...

Seitdem laufe ich ohne Musik auf den Ohren durch die Welt, aber das ist nicht schlimm, denn ich habe ganz viel Musik im Herzen.

Heute Nacht ist es passiert: Das erste Mal ist wirklich Hardware ausgefallen. :eek:

Zu meinem Leidwesen auf einer relativ wichtigen Maschine, die in den letzten Tagen schon etwas gekränkelt hat... Komischerweise ist es gleichsam auch die neuste Maschine, die wir im produktiven Einsatz haben.

Das Schicksal hat es wahrlich nicht gut gemeint: Gleich beide Festplatten im RAID für das Betriebssystem haben sich verabschiedet, sodass dort nun ein wahrliches Zombie-System herumlungert, denn die Maschine läuft noch, nur halt ohne Festplatten und irgendeine Möglichkeit da von Remote aus was dran zu ändern...

Ich werde mich gleich aufmachen und zu der kleinen Maschine hinfahren. Ich bin ja mal gespannt, wie schnell sich da was retten lässt. Immerhin - und für den Notfall - ist das letzte Backup von gestern Abend. Ich habe schon überlegt die Präsenzen schnell auf eine andere Maschine zu spielen. Da die Maschine allerdings noch als Zombie rumläuft ist das alles ein wenig schwerer, da wir hier und dort auf die IP-Adresse angewiesen sind...

Einziger Trost: Die Daten der Kunden scheinen von dem Ausfall nicht betroffen zu sein, denn die waren gar nicht auf den Platten...

Seit einer halben Ewigkeit setzen wir nun schon auf FastCGI wenn es darum geht PHP-Skripte auszuführen. Zum einen haben wir dadurch mehr Kontrolle über das, was jeder Kunde macht bzw. machen darf, zum anderen ist das natürlich ein großer Vorteil in Sachen Sicherheit, da jeder Skript unter der Benutzer-ID des Kunden direkt ausgeführt wird.

An und für sich hat PHP eine sehr schöne FastCGI-Implementierung, was ein (weiterer) großer Vorteil gegenüber Perl, Python oder Ruby ist. Auf der anderen Seite hat es auch ein paar Macken. Ganz gefährlich ist z.B. die Einstellung "PHP_FCGI_MAX_REQUESTS", die sich recht wenig mit mod_fcgid versteht - so fährt PHP nach n Anfragen den Interpreter runter, beendet sich selbst aber nicht, sodass neue Anfragen in den ersten Tagen schon mal ins Leere liefen.

So eine andere Einstellung, die der PHP im FastCGI-Modus bietet ist "PHP_FCGI_CHILDREN", die PHP veranlasst bis zu n Unterprozesse zu starten, sodass der FastCGI-Server im Prinzip zu einem vollständigen preforked Server wird. Wenn man überlegt, dass PHP gerne Arbeitsspeicher isst, ohne ihn danach wieder freizugeben, eigentlich eine gute Möglichkeit um das ein wenig einzugrenzen.

Da bei uns das allerdings vom Webserver an sich reguliert wird, haben wir die Einstellung auf "1" gesetzt, d.h. PHP durfte maximal einen Kindprozess erstellen - was es auch brav getan hat, nur klingt es ein wenig unlogisch, den Interpreter zu starten, einen Kindprozess zu forken und dann die Anfrage mit zwei Prozessen zu verarbeiten...

Von schlauer Software würde ich so etwas wie "ich habe nur einen Kindprozess, da kann ich mir den fork sparen" erwarten, sodass ich mich eben endlich mal an den PHP-Source-Code gewagt habe um diese Funktion einzupflegen.

Doch siehe da: PHP ist bereits fast so schlau, denn wird "PHP_FCGI_CHILDREN" nicht angegeben, führt PHP gar keinen fork aus...

Leider ist dieses Verhalten (bzw. die FastCGI-Schnittstelle) ganz schlecht dokumentiert und auch die FastCGI-Readme lässt anders vermuten:

PHP_FCGI_CHILDREN (default value: 8 )

This controls how many child processes the PHP process spawns. When the fastcgi starts, it creates a number of child processes which handle one page request at a time. So by default, you will be able to handle 8 concurrent PHP page requests. Further requests will be queued.
Increasing this number will allow for better concurrency, especially if you have pages that take a significant time to create, or supply a lot of data (e.g. downloading huge files via PHP). On the other hand, having more processes running will use more RAM, and letting too many PHP pages be generated concurrently will mean that each request will be slow.

Schön, dass ich es nun besser weiß

Eine letzte Anmerkung zur Überschrift: Will man also nur einen Kindprozess haben, ist es sinnvoller den Fork ganz zu unterbinden, d.h. die Einstellung gar nicht zu setzen. Das spart letzten endes noch das eine oder andere Byte wertvollen Arbeitsspeicher

Rechnungen über Webhosting gelten bei uns immer ab dem Tag, wo die Domain für den Kunden wirklich verfügbar wird. Bei Neuregistrierungen ist das natürlich immer sofort, im Falle eines KK-Antrages kann sich das schon mal mit dem Datum, an dem der Kunde eingerichtet wurde arg unterscheiden - man bedenke nur mal diese zum Teil desaströsen Transfer-Versuche, die zig. tausend mal schief gehen, obwohl alles zwischen den drei beteiligten Parteien kommuniziert wurde...

Nicht nur aus diesem Grund (gibt natürlich noch tausend andere Gründe es so zu machen) muss ich in der Buchhaltung immer einen relativ genauen Startzeitpunkt vermerken, wenn ich die neuen Leistungen für einen Kunden verbuche. In der Vergangenheit war das immer ein recht manueller Prozess, wo ich immer zwischen Leistungs- und Domain-Datenbank hin und her springen musste.

Wie ich gestern dann wieder damit beschäftigt war neue Leistungen einzupflegen, dachte ich mir "Verdammt! Das muss sich endlich mal ändern!" und hab ab diesem Zeitpunkt nur noch NULL als Startdatum eingetragen - wohlwissend (oder vielleicht gerade deswegen) dass ich dann so lange keinen Rechnungslauf mehr machen kann bzw. darf bis ich eine entsprechende Veränderung im System vorgenommen habe...

Da ich gestern Nacht allerdings noch ein paar sehr gern gesehene Kunden aus Hannover mit Geld-Forderungen beglücken wollte (;-)) hab ich mich gegen 1 Uhr nochmal dran gesetzt und entsprechende Funktionalität in 10 Codezeilen nachgereicht.... Moah... Irgendwie fällt mir ein Stein vom Herzen - sicherlich zur "Last" der Kunden, denn gerade was das verrechnen von Webhosting und Domains angeht, hab ich jetzt viel weniger zu tun, folglich werde ich es auch öfter tun

Nachdem ich nun auch schon ein paar Mails zu dem Thema bekommen habe und die letzte Stunde wieder zu ein paar Veränderungen am Code genutzt habe, war ich so frei, den Code einfach mal auf einen Webserver zu legen (also als Sourcecode, nicht als laufendes Modul ).

Wer ihn haben will, kann ihn sich hier besorgen.

So wie es jetzt läuft ist es sicherlich nur die Spitze des Eisbergs. Gelegentlich macht es Spass daran zu arbeiten, oder mal durchzuspinnen, was man alles machen könnte - dafür hab ich aber leider nicht so die Zeit

Was mir noch aufgefallen ist:

• Grundsätzlich eignet sich mod_dvb erstmal nicht für den Einsatz auf "standardmäßig konfigurierten" Webservern von uns - das macht auf Dauer keinen Spass, wenn ständig das Bild flöten geht
  
• Die Funktion ap_rflush (); sollte man bloß nicht zu oft aufrufen - irgendwie bleiben die passenden Kontrollpakete im Arbeitsspeicher und werden nicht freigegeben - irgendwann hat man das schon mal angesprochene Arbeitsspeicherproblem dann auch hier.
  
• Einen MPEG-Datenstrom vom DVR-Device abgreifen tut man am besten mit non-Blocking I/O und einer Blockgröße von 188 Bytes.
  
• Radio hören geht damit natürlich auch (sofern das auch am Adapter ankommt)

Schon faszinierend: Ich habe eben mal ganz kurz (so ca. 30 Minuten) richtig alten Code im System überarbeitet.

Ganz spontan und aus einem kurzen Gedanken heraus.

Die konkreten Zeilen waren ca. 4 Jahre alt (ich habe sie aus einem anderen Projekt von mir übernommen) und sind für eine nicht gerade unwesentliche Funktion im System zuständig. Durch die Überarbeitung ist der Code nicht nur kleiner und verständlicher geworden, sondern auch gleich ca. 8 Mal so schnell :eek:

So macht das Arbeiten gleich noch ein Stückchen mehr Spass!

Ich komme ja ursprünglich aus Nordrhein-Westfalen, wo nach Berlin (u.a.) recht früh großräumig DVB-T eingeführt wurde. Als Technik-Begeisterter war ich da natürlich auch sofort dabei und hatte mir div. DVB-T-Adapter zugelegt.

Der Vorteil an DVB-[S|C|T] war ja schon immer, das man direkt einen MPEG2-Datenstrom geliefert bekommt mit dem man eigentlich nach belieben verfahren kann. Sei es per cat Videos aufzunehmen oder den Datenstrom gleich via Netzwerk zu verteilen. Letzteres fällt natürlich direkt in den Bereich in dem ich mich beruflich wie auch privat als Hobby sehr gerne herumtreibe, so habe ich auch schon recht früh damit herum experimentiert.

Die vorhandenen Lösungen basieren alle mehr oder weniger auf RTP und verstreuen den Datenstrom via Broadcast im gesamten Netzwerk - das hat mir darmals schon irgendwie nicht geschmeckt und tut es heute auch noch nicht. Da ich in einem Single-Haushalt lebe reicht mir eigentlich voll und ganz eine Unicast-Lösung.

Seit dem Wochenende bin ich nun wieder in der DVB-Gemeinde angekommen (nachdem es zunächst kein und nun nur dürftig DVB-T in Stuttgart gibt, kam diesmal nur DVB-C in Frage) und experimentiere aufs neue los.

Vor fast 3 Jahren habe ich angefangen einen PHP-Skript zu schreiben, der den MPEG-Datenstrom via Apache im Netzwerk verteilt. Darmals noch mit mod_php(5) führte das regelmäßig dazu, dass Apache mehr und mehr Arbeitsspeicher aß und die Maschine irgendwann das zeitliche segnete. Drum folgte eine eigene HTTP (samt Telnet) Implementierung in PHP... Die habe ich heute noch, ist aber dementsprechend alt und auch nicht das gelbe vom Ei.

Gestern Nacht hatte ich dann eine skurile Idee wie ich finde: Ich habe mod_dvb geschrieben - ein kleines Apache-Modul, das auf mein DVB-C-Adapter zugreift und einen MPEG2-Datenstrom ausliefert, direkt über Apache und ohne diesen Arbeitsspeicherhunger.

Momentan ist das noch wirklich eine Spielerei, kann auch nur eine Verbindung verarbeiten und liefert nur ARD aus... Ich bin mal gespannt, wieivel meiner Freizeit das noch frisst und was daraus wird