All posts by Rene

XLT – Start-and-Go Feature

Ich muss mich heute einfach mal über das Start-And-Go Feature von Xceptance Load Test (XLT) freuen. Früh im Hotel habe ich mich zum Cloud Service verbunden, den Lasttest hochgeladen und gestartet. Danach habe ich das Notebook abgeklemmt und bin Frühstücken gegangen.

Eine Stunde später sass ich im Büro, habe mein Notebook hochgefahren und mich wieder zur Cloud verbunden. Teststatus abgerufen und da der Test durch war, einfach die Ergebnisse runtergeladen.

Es ist echt praktisch, wenn man nicht ortsgebunden für einen Test ist und das Tool einen nicht zwingt, ständig mit den Testmaschinen verbunden zu sein. So machen auch die üblichen Netzunterbrechungen im Hotel oder via UMTS keine Probleme mehr.

Hatte ich schon erwähnt, dass ich beim letzten Mal vom Flughafen, ca. 30 min vor dem Boarding noch mehrere Lasttests laufen hatte? Auch sehr praktisch, dass XLT mit einer Shell auskommt und man den Controller ohne Probleme auf eine Drittmaschine verlagern kann, die man dann via Shell steuert.

Bei der heutigen Sicherheitslage in Rechenzentren bekommt man meist ja nur einen SSH-Zugang mit eigenem Schlüssel und sonst nichts. Aber genau dafür ist XLT gemacht. Mit wenig Ressourcen, viel zu erreichen.

Sparen beim String bauen

Viele Java-Programmiere denken oft beim Schreiben Ihres Codes wenig über Müll nach. Natürlich nimmt man zum Bauen eines Strings aus vielen kleinen Puzzleteilen einen StringBuilder. Den StringBuffer nimmt man nicht mehr, weil der im Regelfall unnötig synchronisiert ist. Schliesslich löst das im Java Memory Model ab JDK 5 eine Synchronisation mit dem Hauptspeicher aus (JSR-133), die wir überhaupt nicht wollen.

Einen kleinen Trick für unnötige Objekt-Erzeugung und damit für weniger Müll im System, gerade wenn immer wieder Strings gebaut werden müssen, ist die korrekte initiale Größe des StringBuilders. Ein new StringBuilder() reserviert zunächst nur ein Array mit 16 Characters. Wenn wir also recht viel zusammenbauen, muss mehrmals eine neues grösseres Array (2 * ggw. Grösse + 1) erzeugt und der Inhalt umkopiert werden.

Wer also weiss, dass er ca. 100 Zeichen aneinanderhängt, der lässt sich gleich einen StringBuilder mit Grösse 120 geben – new StringBuilder(120) – und spart damit das Anlegen von drei Arrays und drei Copy-Operation ein. Gerade bei intensiven Operationen mit Strings macht das eine Menge aus.

Wer würde schon bei einem Umzug zuerst mit dem kleinsten Karton anfangen und dann wegwerfen, weil nicht alles reinpasst? Man schätzt doch am Anfang schon vernünftig ab, wie groß der Karton sein sollte.

Java Concurrency – A Tutorial

Heute habe ich eine wunderbare Webseite zum Thema Java Concurrency gefunden. Jakob Jenkov hat hier viele interessante Themen zur parallelen Programmierung mit Java zusammengefasst. Ein Bookmark wert und in einer ruhigen Minute unbedingt mal lesen.

Java Concurrency – A Tutorial

Java was one of the first languages to make multithreading easily available to developers. Java had multithreading capabilities from the very beginning. Therefore, Java developers often face the problems described above. That is the reason I am writing this trail on Java concurrency. As notes to myself, and any fellow Java developer whom may benefit from it.

LinkedIn-Architektur

Wer gern mal wissen möchte, wie moderne grosse Webseiten laufen, der kann sich hier die LinkedIn-Architecture anschauen und durchlesen. Und wieder ist Lucene die Search-Engine der Wahl. Interessant ist der LinkedIn-Network-Graph, der in Memory gehalten wird… 12 GB RAM.

Einzig die Behauptung

Garbage Collection pauses were killing them. [LinkedIn said they were using advanced GC’s, but GC’s have improved since 2003; is this still a problem today?]

kann ich nicht glauben. Deswegen wurde die Graph-Engine in C geschrieben. Ich denke mal, da war komplett etwas falsch, wenn der GC austickt.

Warum nicht jeder IT-Meldungen schreiben kann

Heute berichtet Golem über “Daten von 4,5 Millionen Bankkunden in den USA verloren“. In einem weiteren Satz heisst es dann:

Der US-amerikanischen “Bank of New York Mellon” sind rund 4,5 Millionen Kundendatensätze verloren gegangen.

Wenn man die Meldung liest, dann merkt man, dass hier nicht von Datenverlust im Sinne von “Alles futsch, auch Backups helfen nicht mehr” die Rede ist, sondern von Daten, die sich durch schlichte Unachtsamkeit an anderen, als den vorgesehenen Plätzen befinden.

Der Unterschied liegt darin, dass die 4,5 Millionen immer noch ein Konto mit einem Betrag haben, aber jemand ausserhalb der Bank weiss nun eventuell davon. Im Falle eines Datenverlustes hätten die 4,5 Millionen Kunden kein Konto mehr.

Merke: Überschriften von IT-Artikeln sind oft mehr als irreführend.

Lufthansa Zentralrechner hat gestreikt

Manchmal ist es doch gar wunderlich, dass sich die alten Zentralrechner Architekturen immer noch halten. So hat es letzte Nacht die Lufthansa erwischt, die nach Backuparbeiten ihr IT-Rückrat verloren hatte.

Die Informatiker der Fluggesellschaft hatten eine Routine-Sicherung der Daten gemacht, alles wieder aufgespielt und waren gerade dabei, die Rechner hochzufahren. Da gerieten die Daten im Computersystem kräftig durcheinander.

Mehr dazu bei N-TV.

P.S. Der wirklich Grund würde mich interessieren, denn eigentlich spielt man Backups nicht auf Livesysteme zurück… schliesslich heisst das Ding Backup und nicht Datenrefresh.