RackBlogger

Nicht alles wird teurer. Eben traf eine Mail von SWITCH ein, mit der Mitteilung dass ab November die Domains rund 20% günstiger werden.
Das ist doch mal schön.

Wir werden diese Preissenkung selbstverständlich auch an die Kunden weitergeben. Da fällt mir ein, von SWITCH hab ich noch ca. 10 ungeöffnete Briefe hier herumliegen (alles aus den letzten Tagen) - die muss ich alle noch kurz prüfen und dann in die Buchhaltung geben… Besonders kosteneffizient erscheint mir das zwar nicht, für jede Transaktionen einen C5-Brief zu verschicken - aber es schaut schon schick aus

Gestern Abend kam ein Freund zu Besuch und überreichte mir noch ein kleines (nachträgliches) Geburtstagsgeschenk zum Thema “Chef sein”:

Das Bill-Gates-Buch ist zwar schon älter (wenn ich das richtig verstanden habe wurde das als Remittende verschenkt), aber ich werde trotzdem mal einen Blick reinwerfen. Vielleicht kann ich ja noch was lernen…

Es ist vollbracht: mod_fastcgi läuft zusammen mit unserer seCGI-Wrapper-Umgebung. Auf Deutsch: für spezielle Anwendungsfälle können wir nun gezielt bei einzelnen Kunden die PHP-Scripts über mod_fastcgi ausführen lassen - ohne dabei auf die gewohnte sichere Ausführungsumgebung zu verzichten. Ein kleiner Eintrag in der httpd.conf genügt hierfür.

Im Hintergrund hat das schon etwas Arbeit mit sich gebracht… das mod_fastcgi-Modul musste angepasst werden, damit es die “richtigen” Daten über den Benutzer etc. erhält und möglichst nahtlos in die bisherige Konfiguration integrierbar ist. Aber der Aufwand hat sich gelohnt. Manche Scripts laufen somit bis zu 10x schneller

Da ein Server bei zu großzügiger Konfiguration aber auch schnell ins Schwitzen geraten kann, wird mod_fastcgi vorerst nur für spezielle Websites eingesetzt, die ohnehin schon eine höhere Last verursachen. Für kleine Websites mit gelegentlichen Script-Aufrufen wäre fastCGI sogar langsamer als der aktuelle PHP-CGI-Aufruf (der Starten der fastCGI-Prozesse dauert etwas länger als ein PHP-CGI-Aufruf).

Die Tests sind jedenfalls heute abgeschlossen worden, und morgen wird das ganze dann für die ersten Websites freigeschaltet. Ich freu’ mich schon…

Eben habe ich im aktuellen IHK-Magazin die neuen Handelsregister-Einträge durchgeblättert. Aufgefallen ist mir der hier:

Gegenstand des Unternehmens: Telefondienstleistungen, der Betrieb eines Call-Centers, der An- und Verkauf von Telekommunikationsanlagen, Handyverträgen und Prepaidkarten, die Herstellung von Döner und der Verkauf von Dönerprodukten […]

Ich glaube das nennt man dann “Cross-Marketing”
Da wo ich heute Abend ein Lahmacum gegessen habe gab es übrigens keine Handies.

Am Wochenende habe ich mein “Reise-Notebook” (ein ultrakompaktes Sony Vaio) neu installiert und abschließend auch für die mobile Internetnutzung über mein Handy konfiguriert. Bei der Gelegenheit habe ich dann auch mal wieder nachgeschaut, was die Nutzung von GPRS in meinem aktuellen Tarif überhaupt kostet. Ich weiß ja dass das teuer ist, aber 9,70 EUR pro Megabyte!? Das sind schlappe 9700,- EUR pro Gigabyte

Es gibt natürlich besondere Datentarife, z.B. mit 30 MB für 9,90 EUR monatlich, aber das brauche ich nicht wirklich wenn ich den GPRS-Internetzugang nur gelegentlich mal in Notfällen nutzen will. Auch eine Datenflatrate für 25-30 EUR wäre da eigentlich unnötig.

Interessant finde ich in dem Zusammenhang, dass es z.B. von WIND ein für Prepaidkarten buchbares Daten-Paket gibt, mit welchem man für 8 EUR innerhalb von 30 Tagen bis zu 97,6 MB im Heimatnetz (also in Italien) “surfen” kann, und selbst in Netzen der Roaming-Partner noch 19,5 MB.
Das heißt, mit der italienischen SIM-Karte kann ich in Deutschland, Österreich usw. für 8 Euro 19,5 MB übertragen - das ist etwa das Zwanzigfache im Vergleich zu meinem “normalen” Mobilfunktarif.
Irgendwie beschleicht mich das Gefühl, dass die deutschen Mobilfunktarife nach wie vor viel zu hoch sind…

Am Wochenende schrie eine MySQL4-Datenbank über Nagios um Hilfe: die Server-Last war auf knapp über 10 angestiegen. Also - kurz per SSH auf den Server und Problem lokalisiert: mit “show processlist” zeigt MySQL eine Liste aller aktiven Prozesse (klingt irgendwie einleuchtend)

Nun, in dieser Liste befanden sich etwa 15 Instanzen der selben Abfrage: select count(*) from xxx where month(date)=5 and year(date)=1997 and textfeld = ‘yyy’; (Spaltennamen geändert)

Also habe ich mir die Tabelle mal näher angesehen. Darin sind etwas über 200.000 Einträge verzeichnet - aber kein Index. Das heißt, die o.g. Abfrage durchsucht jedesmal alle 214.361 Datensätze (nennt sich dann “Full Table Scan”). Ganz leicht lässt sich das sehen, wenn man sich den Ausführungsplan für den SQL-Befehl ausgeben lässt (einfach ein DESCRIBE vor das SELECT setzen).

Ich war dann mal so frei, einen Index über die Spalte mit den Textschlüsseln zu erzeugen. Ergebnis: die Abfrage kann komplett über den Index bearbeitet werden - es ist nur noch ein Zugriff auf die Datensätze notwendig (für den Zieldatensatz). Das entspricht einer Optimierung von 214361:1

Der Kunde freute sich dann auch über meine ausführliche Mail zu dem Thema:

sorry und gleichzeitig vielen Dank für Ihre Erklärung.

Was wäre ich nur ohne Sie. Sollte mir vielleicht irgendwann mal etwas professionelle Unterstützung suchen.

Ach - dafür sind wir doch gerne da. Der vom Kunden angebotene Dienst wächst aber auch erheblich - ich vermute mal dass zum Zeitpunkt der Erzeugung o.g. Tabelle nicht abzusehen war, dass diese mal so anwächst…

Vorhin traf eine KK-Anfrage für eine .de-Domain ein, deren Kunden wir nicht erreichen können (die Postanschrift ist inzwischen ungültig, eine aktuelle Mailadresse oder Telefonnummer liegt uns auch nicht vor) und bei dem die letzten zwei Lastschriften auch geplatzt sind.

Naja, nun lassen wir uns mal vom KK-Antragsteller die Authorisierung des Domaininhabers schicken, geben die Domain dann wunschgemäß frei und schicken die Rechnungen gleich hinterher…

Beim fröhlichen Patchwochenende ist mir wieder aufgefallen, dass Debian Linux ein Problem damit hat, wenn man für das /tmp-Verzeichnis das noexec-Flag setzt. Dieses sorgt dafür, dass keine Dateien in diesem Verzeichnis ausgeführt werden dürfen - eine durchaus gängige Sicherheitsmaßnahme gegen Rootkits & Co.

Manche Pakete entpacken allerdings das eine oder andere Script ins /tmp-Verzeichnis und wollen es dort ausführen, was dann zu hässlichen Fehlermeldungen bei APT führt.

Einziges Workaround: zum Beginn einer Wartung das /tmp-Verzeichnis ohne noexec-Flag remounten, dann Software aktualisieren, dann wieder mit noexec mounten…