Technik

Ich hatte letzte Woche mal testweise eine MySQL-Tabelle auf die sehr oft lesend wie auch schreibend zugegriffen wird von MyISAM auf HEAP umgestellt. Ging auch gleich alles viel schneller, jedoch war der Speicherplatz-Bedarf der Tabelle nun 10 Mal mehr wie vorher...

Auf den kleinen Geschwindigkeitsvorteil haben wir dann doch lieber verzichtet, denn das waren die 500 MB Arbeitsspeicher mir dann doch nicht wert - zumal besagte Anwendung "nur" im Backend läuft.

Seit jeher setzen wir auf unsere eigene Verwaltungssoftware und ich kann es nur immer wieder sagen: Das hat Vor- und Nachteile, für uns überwiegen jedoch die Vorteile

Nachteil ist natürlich, dass nicht immer alles für den Kunden direkt verfügbar ist, sprich er muss gelegentlich bis oft den "Umweg" über uns im Support machen. Ein anderer Nachteil ist, dass das System sich ständig weiterentwickelt - es ist noch nicht ausgewachsen und bringt oftmals nur die Leistung, die es in einem bestimmten Punkt bringen muss, oder ein wenig mehr. Viel mehr dann aber auch nicht und das ist schlecht, wenn man bedenkt, dass wir noch recht jung am Markt sind und ständig wachsen.

Letzterem ist schon vor längerer Zeit ein Programm zum Opfer gefallen, dass wir intern "vHost-Deamon" nennen - ein Programm, das die Konfiguration für den Webserver überprüft, bearbeitet und aktiviert. Das lief bis dato in seiner zweiten Generation und ist auch ganz wunderbar - bis auf die Last, die es auf den gewachsenen Systemen hervorruft. Die Anforderungen an die System-Ressourcen hatten uns dazu veranlasst das Programm nicht automatisch ablaufen zu lassen, sondern immer von Hand anzustoßen, was natürlich den Grad der automatisierung rapide absenkt.

Nun war das aber kein Zustand auf dem man sich ausruhen könnte, sodass ich in den letzten Monaten immer mal wieder an der 3. Generation gearbeitet habe. Gestern Nacht war ich dann mal so mutig und habe die Beta ins erste Produktiv-System genommen.

Funktioniert perfekt!

Ich gebe es nur ungern zu, aber es stimmt: Wird ein Marktbegleiter angegriffen, dann freut man sich schon mal ein wenig - wenn auch nur inoffiziell. Jeder weiß ja, was des einen Freud ist, ist gleichsam des anderen Leid.

Anders verhällt es sich, wenn der Marktbegleiter, der dort angegriffen wird, zufällig auch der ist, bei dem man selbst seine Maschinen unterstellt. Dann hat man gar keine Zeit sich irgendwie zu freuen. Denn die Erreichbarkeit der eigenen Systeme knickt je nach Härte des Angriffs im Handumdrehen ein und man hat erstmal Stress herauszufinden, woher die Ursache dafür kommt.

So geschehen heute zwischen 11:40 und 11:54.

Ein wenig zitterig ist mir immernoch zu mute, aber es ist gut zu wissen, dass sich an der entscheidenden Stelle schnell und zuverlässig gekümmert wurde - das lindert doch ein wenig den Schmerz

Ich habe eben einen Prozess angestossen, der schon längst überfällig war: Ich erstelle für mich selbst ein neues Kontakt-Handle.

Das hat den Hintergrund, dass im "alten" Handle noch unsere alten Telefonnummern vermerkt waren (die nach wie vor funktionieren, aber halt nicht mehr aktuell sind). Die DeNIC mag es dabei irgendwie nicht, wenn Firmennamen oder Telefonnummern in bestehenden Kontakt-Handles geändert werden, weswegen die Handles dann komplett neu angelegt werden müssen.

Wir hatten den Fall "glücklicherweise" schon mal bei einem Kunden, wo es nur um ca. 8 Domains ging. Genug Zeit um uns für die Zukunft vorzubereiten. So musste ich eben nur eine einzige Funktion ausführen um den Vorgang anzustoßen.

Trotzdem bleibt es ein mulmiges Gefühl im Bauch wenn man nahezu alle Domains im Hause modifizieren lässt. :hmm:

Ich weiß es nicht.

Was ich aber weiß ist, dass mplayer in Verbindung mit meinem mod_dvb schon mal Probleme bei der Datenübertragung via WLAN hatte, weswegen ich eigentlich immer auf meiner Workstation fern geschaut oder eben ein LAN-Kabel an den Laptop angeschlossen habe.

Irgendwann letzte Woche wollte ich mal Kaffeine, das ja bekanntlich auf Xine basiert, ausprobieren. Das hat auch wunderbar funktioniert, so sehr, dass ich kurzerhand Kaffeine's Playlisten-Format als Handler in mod_dvb integriert habe. Irgendwann einen Abend später fiel mir dann mal auf, dass ich das LAN-Kabel gar nicht im Laptop stecken hatte...

... obwohl ich schon die ganze Zeit völlig ruckelfrei fern gesehen habe... Merkwürdig! Warum sollte Xine besser über WLAN-Netze laufen als mplayer? :hmm:

Es ist nun schon fast eine halbe Ewigkeit her, dass ich festgestellt habe, dass es nun auch LightScribe-Software für Linux gibt...

Allerdings bin ich bis dato niemals wirklich dazu gekommen, es wirklich mal zu testen - bis gestern! Gestern gab es für mich einen privaten Anlass (deswegen gibt es auch keine Fotos oder so ) die ganze Sache mal auszuprobieren - außerdem ist es traurig immer nur den Staub von den ganzen LightScribe-Rohlingen zu wischen.

Entgegen der Weitläufigen Meinungen, dass LightScribe unter Linux immernoch ein schweres Unterfangen sei, bin ich eigentlich richtig zufrieden, denn es hat alles sofort und ohne Probleme funktioniert. Nunja, der Umstand, dass der Labeler immer nur ein einzelnes Bild schreiben kann stellte mich vor ein ganz kleines Problem - aber wozu gibt es so tolle Programme wie GIMP, wo man sich in Windeseile eine Schablone erstellen kann?

Mein Fazit: Immernoch ne tolle Sache - wenn auch nur Spielerei - die ich von nun an Garantiert öfter machen werde!

Ich habe irgendwann mal die Regel eingeführt, dass in unserer Datenbank jeder Posten einer Rechnung seperat abgebildet wird, d.h. es gibt ein übergeordnetes Rechnungs-Objekt, dem mehrere Posten untergeordnet sind.

Eigentlich eine tolle Sache, denn so kann man ganz bequem über unser Interface jede Rechnung anschauen ohne groß kramen zu müssen oder PDFs runterzuladen. Der Nachteil daran ist natürlich, dass man jeden einzelnen Posten gesondert einpflegen muss.

... das stößt mir bis heute jeden Monat ganz besonders bei den Rechnungen unseres Registrars auf, denn jede Registrierung, Verlängerung oder jeder Transfer einer Domain wird dort als einzelner Posten gebucht - und man kann sich vorstellen, dass man hierbei sehr schnell im dreistelligen Bereich ist.

Und das von Hand? Nie wieder!

Heute war es wieder fällig und ich hatte echt keine Lust mehr. Gut, dass unser Registrar dazu eine Schnittstelle hat mit der man indirekt auf die Posten einer Rechnung zugreifen kann - habe ich mehr oder weniger nur durch Zufall herausgefunden und gleich mal implementiert.

Der interessiere Kunde und der neugierige Blogleser wissen, dass wir auf unseren Webserver PHP an einer FastCGI-Schnittstelle betreiben. Im normalen Betrieb ändert sich - nicht zuletzt dank einiger Patches - für den Kunden rein gar nichts, es fühlt sich meistens an wie das andernorts übliche mod_php.

Die Art und Weise wie PHP dies implementiert ist hervorragend, denn für jeden beliebigen PHP-Skript muss nur ein einziger Interpreter ausgeführt werden - etwas, was ich schon oft vermisst habe. Denn die anderen populären Sprachen wie Perl oder Python implementieren ihre FastCGI-Schnittstellen zumeist auf höherer Ebene, d.h. ein FastCGI-Prozess kann oftmals nur mit einem Perl- oder Python-Skript verwendet werden, sprich nicht so universell wie PHP.

... solch eine Lösung kam für mich eigentlich niemals in Frage, zumal im Falle einer "kapitalistischen Umsetzung" der Kunde hier speziell nur FastCGI-Skripte verwenden könnte. Unnötiger Mehraufwand!

Für Python habe ich heute einen ersten "Wrapper" geschrieben: Momentan noch ein kleiner 20 Zeiler in C geschrieben, der sich den Python-Interpreter und die FastCGI-Schnittstelle zu eigen macht und beides "intelligent" miteinander kombiniert. Die ersten Tests waren bisher sehr vielversprechend - ich bin mal gespannt, was daraus wird! :hmm:

... wenns fertig ist, wird es dann natürlich OpenSource - versteht sich von selbst

Ich wollte schon immer mal unsere eingesetzte PHP-Version (5.1.4) auf etwas höheres upgraden...

Allerdings bin ich bisher immer vor der 5.2er-Reihe aufgrund von Migrationsberichten zurückgeschreckt und für die 5.1er habe ich mich ehrlich gesagt zu dämlich angestellt, da das letzte Release zu finden :hmm:

Gestern Nacht habe ich mir dann ein Herz gefasst, nochmal genauer geschaut und ein wenig geschraubt. Auf meinem Entwicklungssystem läuft nun PHP 5.1.6 und PHP 5.2.4 im Parallelbetrieb, d.h. ich kann individuell bestimmen für welchen Kunden welche PHP-Version benutzt wird. Aus Spass habe PHP 4.4.7 noch oben drauf gelegt - man weiß ja nie - auch wenn ich dafür übelste Beschimpfungen vom Helferlein über mich ergehen lassen musste.

Wer PHP 4.4.7 zusätzlich noch mit dem Suhosin-Patch versehen will und das Modul statisch einkompiliert könnte btw. Probleme beim Installieren bekommen - hierzu als kleiner Tipp: Einfach die Funktionen import_request_variables und extract im Modul "Standard" nicht registrieren lassen

Momentan repliziere ich alle Neuerungen auf ein Produktivsystem für den ersten "heißen" Test