<p>Vielen Dank an alle Zuhörer meines Vortrages und das tolle Feedback. Mir hat es viel Freude gemacht Euch die Geheimnisse der Just in Time Compilation in Java näher zu bringen. Ich habe damit begonnen Euer Feedback einzuarbeiten und den Code und die „Erklärungsslides“ auf Github (<a href="https://github.com/CodingFabian/jit-talk">https://github.com/CodingFabian/jit-talk</a> ) angepasst.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Hrpt2kHoQvyJ0NLgYXvK"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Hrpt2kHoQvyJ0NLgYXvK" alt="jit-talk-javaland" width="300" height="169" /></a> </p><p>Für Alle die meinen Vortrag auf der JavaLand leider nicht sehen konnten gibt es eine zweite Chance: Auf der JAX in Mainz werde ich am 23. April eine 60 minütige Version vortragen. Ich hoffe sie passt etwas besser, denn 45 Minuten waren leider zu knapp bemessen. Insgesamt war die JavaLand ein sehr tolles Event. Es gab super Vorträge, ein klasse Rahmenprogramm, Achterbahnen, gutes Catering und natürlich viele alte und neue Gesichter zum ausführlichen Networking.<br /> Nächstes Jahr ist wieder eine JavaLand, reserviert Euch Eure Tickets rechtzeitig 🙂</p>

Mein Just In Time Compiler Vortrag auf der JavaLand

<p>Im Rahmen der Nürnberg Web Week habe ich auf der Web Insights einen Vortrag über jede Menge WPO Themen gehalten. Er dient quasi als Überblicksvortrag der diverse Themen motiviert und in einen Zusammenhang setzt. Als Techniker fühlte ich mich etwas wie ein Exot auf der sonst sehr SEO-lastigen Konferenz. Dennoch war es eine tolle Veranstaltung! Falls es Detailfragen zu einzelnen Techniken oder Best Practices gibt zögert bitte nicht Kontakt mit mir aufzunehmen 🙂</p><p></p>

Web Performance Optimization auf der Webinsights

<div> <img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/jScVEL7HTIiUqGTQRvm6" alt="jcrete-folks" width="300" height="199" />(Foto von Stephen Chin)</div><p>Vom 24. bis zum 29. August fand auf der griechischen Mittelmeerinsel Kreta die JCrete statt. Dies war die vierte jährliche Unkonferenz, welche von Heinz Kabutz und Kirk Pepperdine ins Leben gerufen wurde.  Dieses Jahr fand die Veranstaltung in der Orthodox Academy of Krete statt. Wie der Direktor des OAK in seiner ungewöhnlichen Eröffnungsrede erläuterte verbindet die Abkürzung der Akademie sie eng mit Java, das in erster Version von James Gosling nach einer Eiche „Oak“ benannt wurde.<br /> <br /><br /> Dieses Event machen viele Faktoren zu einer der aussergewöhnlichsten Konferenzen:</p><ul><li>Es ist keine Konferenz, sondern eine Unkonferenz. Das Programm wird von allen Teilnehmern gemeinsam gestaltet und geplant.</li><li>Die Teilnahme erfolgt ausschließlich auf Einladung. Jeder Teilnehmer muss etwas zur Unkonferenz beizutragen haben.</li><li>Jeden Tag gibt es familienfreundliche Freizeitaktivitäten, wie zum Beispiel Exkursionen zu Stränden, Sehenswürdigkeiten oder gemeinsames Abendessen.</li></ul><p><span></span></p><h2>Sessions</h2><div> <img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Ixm2pATQsmIzdWenKlwW" alt="session-planning" width="300" height="223" />(Foto von Andres Almiray)</div><p>In großer Runde wurden Ideen und Vorschläge für Sessions von jedem Teilnehmer vorgestellt. Aus den so gesammelten Sessions haben wir dann das Programm für die folgenden 4 Tage zusammengestellt. In Summe fanden 50 Sessions statt, verteilt über 4 Tage. Hinzu kamen Hacking-Sessions am Strand, in der Hotelbar oder der Kapelle.<br /> <br /></p><div> <img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/LeyLVHHS46uyMR9ZDnSQ" alt="sessions" width="300" height="229" />(Foto von Christoph Engelbert)</div><p>Sehr zu meiner Freude gab es viele Low-Level Java Sessions. So haben wir uns zu dem Benchmarking Framework JMH ausgetauscht, über Off-heap Datenstrukturen diskutiert und mehrfach JIT compilierten Assemblercode studiert.<br /> Am Freitag wurde insbesondere Hardware gehackt: Lego Mindstorms mit Stephen Chin oder Tinkerforge mit meinem Kollegen Sven Ruppert.</p><p>Das Niveau war den Teilnehmern entsprechend recht hoch. Auf regulären Konferenzen wären die Diskussionen und Vorträge wohl in die Kategorie „Fortgeschrittener“, wenn nicht sogar „Experte“ gefallen.</p><p>Die Dokumentation zu den Sessions wuchs nach und nach auf der Unkonferenz Webseite.</p><h2>Strände</h2><p><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/gFuf8QhXRz2VL0kdnD7h" alt="balos" width="300" height="225" /><br /> Wer im Spätsommer nach Kreta fliegt, der erwartet warmes Wetter und schöne Strände. So wurden wir auch nicht enttäuscht. „Clouds 1.0“ wurden keine gesichtet und es war tagsüber bis 36 Grad heiß. Dementsprechend suchten viele JCretans Abkühlung im Meer, so dass auf vielen Exkursionen Strände wie der berühmte Strand von Balos aufgesucht wurden.</p><div> <img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/VAEbvWcTAi0KMGFIQhgQ" alt="taxi-donkey" width="245" height="300" /></div><p>Alleine der Weg zum Strand von Balos ist ein Abenteuer: 10km unbefestigte „Hoppelpiste“, der sicherlich einige Stoßdämpfer der Leihwagen zum Opfer gefallen sind, sowie ein steiler Auf- und Abstieg zur Lagune sind zu bewältigen bevor man die Lagune genießen kann.<br /> Für bequemere Badegäste stehen Taxi-Donkeys zur Verfügung. Die im Rechts abgebildeten „Esel“ wollten uns allerdings nicht tragen.<br /> Wer glaubt, dass am Strand Urlaubsstimmung herrschte, irrt aber. Es wurden pausenlos Themen rund um Java diskutiert, ob auf der Sonnenliege oder beim Schwimmen.</p><p><br /></p><h2>Essen</h2><p>Da wir alle „Speaker“ waren, fand jeden Abend ein Speaker Dinner statt. Es wurden typische griechische und kretanische Spezialitäten von mit Heinz befreundeten Lokalbesitzern serviert. Mit rund 100 hungrigen Mäulern waren wir sicherlich auch eine große Attraktion für die beschaulichen Gaststätten. So dinierten wir am Dienstag Abend in dem kleinen Dörfchen Afrata, dessen Einwohner uns kurzerhand eine Tafel auf dem Dorfplatz aufbauten um uns bewirten zu können. Es war immer sehr lecker und es gab auch reichlich Raki — Yammas!<br /> <img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/qWg0NIGnQAqCFNcCLMTM" alt="dinner-thursday" width="300" height="225" /><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/4O9JjUmJTJuaAFcKWbVA" alt="dinner_thursday" width="300" height="225" /><br /> <img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/jQCNV1e5TEq4QlZh2esY" alt="dinner-sunday" width="300" height="224" /><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/1dn9haSSrKBGiEQRVfmg" alt="dinner-tuesday" width="300" height="213" /><br /> <br /></p><h2>Fazit</h2><p>Eine erstklassige „Konferenz“ in einer fantastischen Lokation. Umfassendes Bild und Videomaterial hat Stephen Chin auf seiner Nighthacking Webseite bereitgestellt.<br /> Ich komme sicher einmal wieder zur JCrete! Das Datum für nächstes Jahr steht auch schon fest: 20. bis 24. Juli 2015</p>

JCrete – Eine Java Unkonferenz auf den Stränden Kretas

<p>Strings verbrauchen jede Menge Speicher in allen Java Anwendungen. Insbesondere das char[], welches die einzelnen UTF-16 Zeichen enthält, trägt am meisten zum Gesamtverbrauch der JVM bei, da jedes Zeichen 2 Bytes verbraucht.<br /> Es ist nicht ungewöhnlich, dass 30% des Speichers von Strings verbraucht wird. Das liegt nicht nur daran, dass String das beste Format ist um mit Menschen zu interagieren, sondern dass auch die populären HTTP APIs viele Strings verwenden. Mit Java 8 Update 20 haben wir nun Zugriff auf ein neues Feature, genannt <em>String Deduplication</em>, mit dem der Speicherverbrauch reduziert werden kann. Es benötigt den G1 Garbage Collector und ist aktuell noch standardmäßig ausgeschaltet.<br /> String Deduplication nutzt aus, dass das char Array ein internes finales Feld in String ist und deshalb der JVM Freiraum gibt, es zu modifizieren.<br /> <span><br /> Verschiedene Strategien für String Deduplication wurden erwogen, aber die nun implementierte funktioniert wie folgt:<br /> Immer wenn der Garbage Collector einen String bearbeitet, speichert er den Hash des char Arrays zusammen mit einer Weak Reference auf das char Array. Sobald er einen String mit dem gleichen Hash findet, werden die char Arrays elementweise verglichen.<br /> Wenn beide übereinstimmen, wird der eine String modifiziert, so dass seine char Array Referenz auf das Array des anderen Strings zeigt. Das zweite char Array wird dadurch nicht mehr referenziert und kann garbage collected werden.</span></p><p>Der ganze Vorgang bringt natürlich einiges an Overhead mit sich, welcher durch enge Limits kontrolliert wird. So wird zum Beispiel ein String, für den eine Weile kein Duplikat gefunden wurde, nicht weiter betrachtet.</p><p>Wie funktioniert das nun in der Praxis? Zuallererst benötigen wir das kürzlich veröffentlichte Java 8 Update 20.</p><p>Dann kann folgender Code mit diesen VM Parametern gestartet werden: <code>-Xmx256m -XX:+UseG1GC</code></p><div>

```java5
public class LotsOfStrings {
 
  private static final LinkedList<String> LOTS_OF_STRINGS = new LinkedList<>();
 
  public static void main(String[] args) throws Exception {
    int iteration = 0;
    while (true) {
      for (int i = 0; i < 100; i++) {
        for (int j = 0; j < 1000; j++) {
          LOTS_OF_STRINGS.add(new String("String " + j));
        }
      }
      iteration++;
      System.out.println("Survived Iteration: " + iteration);
      Thread.sleep(100);
    }
  }
}
```

</div><p>Dieser Code wird nach 30 Iterationen mit einem OutOfMemoryError abbrechen.</p><p>Als Nächstes starten wir es mit aktivierter String Deduplication:<br /> <code>-Xmx256m -XX:+UseG1GC -XX:+UseStringDeduplication -XX:+PrintStringDeduplicationStatistics</code></p><p>Der Code läuft nun signifikant länger und wird erst nach 50 Iterationen abbrechen.</p><p>Die JVM liefert nun auch Informationen darüber, was sie tut. Das sieht so aus:</p><div>

```bash
[GC concurrent-string-deduplication, 4658.2K->0.0B(4658.2K), avg 99.6%, 0.0165023 secs]
   [Last Exec: 0.0165023 secs, Idle: 0.0953764 secs, Blocked: 0/0.0000000 secs]
      [Inspected:          119538]
         [Skipped:              0(  0.0%)]
         [Hashed:          119538(100.0%)]
         [Known:                0(  0.0%)]
         [New:             119538(100.0%)   4658.2K]
      [Deduplicated:       119538(100.0%)   4658.2K(100.0%)]
         [Young:              372(  0.3%)     14.5K(  0.3%)]
         [Old:             119166( 99.7%)   4643.8K( 99.7%)]
   [Total Exec: 4/0.0802259 secs, Idle: 4/0.6491928 secs, Blocked: 0/0.0000000 secs]
      [Inspected:          557503]
         [Skipped:              0(  0.0%)]
         [Hashed:          556191( 99.8%)]
         [Known:              903(  0.2%)]
         [New:             556600( 99.8%)     21.2M]
      [Deduplicated:       554727( 99.7%)     21.1M( 99.6%)]
         [Young:             1101(  0.2%)     43.0K(  0.2%)]
         [Old:             553626( 99.8%)     21.1M( 99.8%)]
   [Table]
      [Memory Usage: 81.1K]
      [Size: 2048, Min: 1024, Max: 16777216]
      [Entries: 2776, Load: 135.5%, Cached: 0, Added: 2776, Removed: 0]
      [Resize Count: 1, Shrink Threshold: 1365(66.7%), Grow Threshold: 4096(200.0%)]
      [Rehash Count: 0, Rehash Threshold: 120, Hash Seed: 0x0]
      [Age Threshold: 3]
   [Queue]
      [Dropped: 0]
```

</div><p>Netterweise liefert uns die Ausgabe auch die laufenden Gesamtsummen, so dass wir nicht selber alle Werte addieren müssen.<br /> Die obige Ausgabe enthält Daten über die vierte Ausführung von String Deduplication. Sie benötigte 16ms und bearbeitete 120.000 Strings.<br /> Alle wurden als „neu“ klassifiziert, was bedeutet, dass sie noch nie analysiert wurden. Diese Zahlen werden natürlich in echten Anwendungen ganz anders aussehen. Dort werden Strings übersprungen werden oder schon einen Hash haben (der Hash eines Strings wird ja bekanntermaßen lazy berechnet).</p><p>Im obigen Beispiel wurden alle Strings dedupliziert, was insgesamt 4.5MB Speicher freigegeben hat.<br /> Der <em>Table</em> Bereich liefert Statistiken über die interne Verwaltungstabelle. Im <em>Queue</em> Abschnitt wird aufgelistet, wie viele Strings aus der Warteschlange entfernt wurden. Wenn viele Strings zu deduplizieren sind, kann sich diese Warteschlange aufstauen. Zur Overheadreduzierung werden dann dort Elemente entfernt.</p><p>Was ist eigentlich mit String Interning? Ich hatte bereits darüber gebloggt, <a href="/wissens-hub/blog/speicher-sparen-mit-string-interning-in-java">wie gut String Interning Speicher sparen kann</a> . In der Tat ist String Deduplication dem String Interning sehr ähnlich, mit der Ausnahme, das nicht ganze String Instanzen geteilt werden, sondern nur die char Arrays.</p><p>Das Hauptargument, welches die Autoren des <a href="http://openjdk.java.net/jeps/192">JDK Enhancement Proposal 192</a>  anführen, ist, dass Entwickler oft entweder nicht wissen wo eine gute Stelle zum String Interning wäre, oder dass sie darauf keinen Zugriff hätten, da es hinter Frameworks versteckt ist. Wie ich in dem Blog Eintrag beschrieb, ist es für Interning wichtig zu wissen wo Strings, wie z. B. Ländernamen, häufig verwendet werden.<br /> String Deduplication betrifft zudem Strings anwendungsübergreifend und auch Dinge wie XML Schemas, URLs, jar Namen und so weiter, welche auf den ersten Blick gar nicht nach Duplikaten aussehen.</p><p>Im Gegensatz zu String Interning, welches im Anwendungsthread erfolgt, erfolgt die String Deduplication asynchron und nebenläufig während der Garbage Collection. Dies ist auch der Grund, warum das Codebeispiel oben ein <code>Thread.sleep()</code> benötigt. Ohne würde die GC überlastet und String Deduplication würde gar nicht ausgeführt werden. Aber in einer echten Anwendung ist das natürlich kein Problem, da dort ausreichend Zeit für GC und auch für String Deduplication ist.</p>

String Deduplication – Ein neues Feature in Java 8 Update 20

<p>Am Donnerstag den 21. August habe ich einen Vortrag auf der RheinJUG gehalten.<br /> Thema des Vortrages war eine Neuauflage meines JavaLand Vortrages mit der zentralen Fragestellung ob wir Java Profilern eigentlich vertrauen können. Neu in dieser Version ist die Betrachtung von <a href="https://github.com/RichardWarburton/honest-profiler">Richard Warbutons Honest Profiler</a> . Demnächst gibts auf der RheinJug Seite auch die Videoaufzeichnung für alle Daheimgebliebenen.</p><p></p>

Sagt mein Profiler die Wahrheit – RheinJug

<p>Auf der diesjährigen JAX in Mainz habe ich diese Frage in einem Talk erörtert und dabei gezeigt welche Probleme und Mechanismen bei einem Profiler alle Anwendung finden. Anhand von einigen Code Beispielen habe ich dann gezeigt wie man die Effekte erkennen und beeinflussen kann. Leider findet sich der Live Anteil nicht in den Slides, aber die nächste Gelegenheit den Talk zu hören kommt bestimmt 🙂</p><p></p>

Sagt Mein Profiler die Wahrheit?

<div><div><div><p>Klicken Sie auf den unteren Button, um den Inhalt von de.slideshare.net zu laden.</p><p><a href="#">Inhalt laden</a> </p></div></div><div></div></div><p>Mein Vortrag stellt anschaulich dar welche Vorteile SPDY bietet, warum es wahrscheinlich Teil von HTTP/2.0 wird und wie einfach SPDY jetzt schon genutzt werden kann. Ich habe ihn heute im Rahmen der WebTechConference in Mainz gehalten.</p><p>Dazu der passende Liveberichterstattungsartikel in der IT Republik: <a href="http://it-republik.de/php/news/Ob-SPDY-haelt-was-Google-verspricht-065129.html">Ob SPDY hält, was Google verspricht?</a> </p><p>PS: Dieses Blog und die Webseiten von codecentric laufen übrigens schon seit Anfang 2012 mit mod_spdy ohne Probleme und deutlich spürbaren Geschwindigkeitsschub.</p><p><br /></p>

SPDY – http Reloaded – Vortrag von der WebTechConference2012

<div><div><div><div><div><p>Klicken Sie auf den unteren Button, um den Inhalt von www.slideshare.net zu laden.</p><p><a href="#">Inhalt laden</a> </p></div></div><div></div></div></div></div><div>Gestern habe ich auf dem Kölner <a href="http://www.meetup.com/cologne-germany-high-performance-website-optimization-group/events/51518852/">Web Performance Meetup</a>  einen Vortrag mit Demo über das SPDY Protokoll gehalten. Vielen Dank für Eure Teilnahme und die gute Diskussion!<br /> Vielen Dank auch an Tobias Baldauf (<a href="https://twitter.com/#!/tbaldauf">@tbaldauf</a> ) und <a href="http://www.eco.de/">eco, Verband der deutschen Internetwirtschaft e.V.</a>  für das Ausrichten des Abends.<p>Fotos gibt es auf der MeetUp Seite, und einen Termin für das <a href="http://www.meetup.com/cologne-germany-high-performance-website-optimization-group/events/58506562/">nächste Meetup</a>  gibt es auch schon: 26. April.<br /> Thema dann wird unter anderem sein: „Varnish“ von Dennis Benkert (<a href="https://twitter.com/#!/denderello">@denderello</a> ).<br /> Die Folien für meinen Vortrag über SPDY sind auf slideshare: <a href="http://www.slideshare.net/fabianlange/the-spdy-protocol" target="_blank">The SPDY Protocol</a> <br /> Viel Spaß beim Ausprobieren!</p></div><p><br /></p>

Web Performance Optimization Meetup in Köln: Das SPDY Protokoll

<p>Attila Szegedis Vortrag über „<a href="http://gotocon.com/dl/goto-amsterdam-2011/slides/AttilaSzegedi_JVMPerformanceOptimizationsAtTwittersScale.pdf">lessons learned about the JVM</a> “ überraschte mich insbesondere dadurch dass er relativ ausgiebig darauf einging, wie viel Speicher eigentlich durch Daten belegt wird. Dies ist für Enterprise Java Entwickler eher untypisch. Doch er hatte einige gute Anwendungsbeispiele aus seiner Zeit bei Twitter.</p><h2>Speicherverbrauch von Daten</h2><p>Frage: Wie viel Speicher benötigt eigentlich der String „Hello World“ ?<br /> Antwort: 62/86 Bytes (32/64 bit Java)!<br /> Dies teilt sich auf in 8/16 (Object Header für String) + 11 * 2 (Zeichen) + [8/16 (Object Header char Array) + 4 (array Länge) aufgefüllt auf 16/24] + 4 (Offset) + 4 (Count) + 4 (HashCode) + 4/8 (Referenz aufs char Array). [Auf 64Bit ist das String Objekt auf 40 aufgefüllt].</p><h2>Das Problem</h2><p>Stellen wir uns vor, wir haben jede Menge Locations, welche an unseren Tweets hängen und die Position des Users beschreiben. Die Implementierung könnte dann etwa so aussehen</p><div>

```java5
class Location {
	String city;
	String region;
	String countryCode;
	double long;
	double lat;
}
```

</div><p>Wenn wir nun alle Orte aller jemals gemachten Tweets laden, so ist klar, dass dies ziemlich viele String Objekte erzeugt. Und bei der Größe von Twitter ist es auch sehr wahrscheinlich, dass diese Strings zu einem großen Teil aus Duplikaten bestehen. Attila sagte in seinem Vortrag, dass diese Daten nicht in einen 32 GB Heap passten. Also ist die Frage: Wie bekommen wir die Daten kleiner, so das sie alle in den Speicher passen?<br /> <span><br /> Schauen wir uns zwei Lösungen an, die sogar kombiniert werden können.</span></p><h2>Attilas Lösung</h2><p>Da es eine mehr oder weniger gut versteckte Abhängigkeit der Daten zueinander gibt kann man, sobald man sie entdeckt hat, den Speicherbedarf ohne technische Tricks reduzieren. Wir können eine einfache Normalisierung der Daten durchführen:</p><div>

```java5
class SharedLocation {
	String city;
	String region;
	String countryCode;
}
class Location {
	SharedLocation sharedLocation;
	double long;
	double lat;
}
```

</div><p>Dies ist eine elegante Lösung, da Städte selten ihre Region oder ihr Land wechseln. Diese Kombination ist also eigentlich immer eindeutig. Und diese Darstellung ist dennoch flexibel genug um Abweichungen abbilden zu können. Dies ist insbesondere bei von Benutzern eingegebenen Daten sinnvoll. Nach der Normalisierung belegen mehrere Tweets aus „Solingen, NRW, DE“ nur eine SharedLocation.<br /> Jedoch würde „Ratingen, NRW, DE“ immer noch 3 weitere Strings im Speicher anlegen, anstatt nur den neuen „Ratingen“ zur erstellen. In dem Fall von Twitter hat nach diesem Refactoring die Datenmenge in 20GB Heap gepasst.</p><h2>String Interning</h2><p>Was aber, wenn man entweder das Modell nicht verändern kann (oder will), oder man in dem Fall von Twitter auch keine 20GB Heap gehabt hätte?<br /> Die Antwort ist String Interning, was dafür sorgt, dass jeder String nur ein einziges Mal im Speicher bleibt.<br /> Leider gibt es einige Verwirrung über den Sinn von String interning. Viele Entwickler fragen ob dies denn den Vergleich zweier Strings beschleunigt, da dann die Strings ja sogar identisch sind. Dies ist zwar der Fall (wie bei allen Objekten)</p>

```

// java.lang.String
public boolean equals(Object anObject) {
  if (this == anObject) {
    return true;
  }
  //...
}

```

<p>Jedoch ist die Performance von „equals“ nicht der Grund aus dem man Interning verwenden sollte. Es ist dafür gedacht Speicher zu sparen.</p><blockquote><p>Verwendet String.intern() nur auf Strings die häufig vorkommen und auch nur um Speicher zu sparen</p></blockquote><p>Die Effizienz von Interning ist durch das Verhältnis von Dubletten zu einmaligen Strings bestimmt. Und es hängt auch davon ab wie einfach der Code an den stringerzeugenden Stellen zu modifizieren ist.</p><h3>Also, wie geht das nun?</h3><p>String Interning verwendet eine Instanz eines Strings (der also schon im Heap existiert) und prüft ob eine identische Kopie in der StringTable existiert.<br /> Diese StringTable ist so etwas wie ein HashSet das den String in der Permanent Generation speichert. Der alleinige Zweck dieser Table ist eine einzige Instanz pro Zeichenkette am Leben zu halten. Falls der String dort schon ist, wird diese Instanz zurückgeliefert. Ansonsten wird diese Zeichenkette dort gespeichert:</p><div>

```c
// OpenJDK 6 code
JVM_ENTRY(jstring, JVM_InternString(JNIEnv *env, jstring str))
  JVMWrapper("JVM_InternString");
  JvmtiVMObjectAllocEventCollector oam;
  if (str == NULL) return NULL;
  oop string = JNIHandles::resolve_non_null(str);
  oop result = StringTable::intern(string, CHECK_NULL);
  return (jstring) JNIHandles::make_local(env, result);
JVM_END
 
oop StringTable::intern(Handle string_or_null, jchar* name,
                        int len, TRAPS) {
  unsigned int hashValue = hash_string(name, len);
  int index = the_table()->hash_to_index(hashValue);
  oop string = the_table()->lookup(index, name, len, hashValue);
 
  // Found
  if (string != NULL) return string;
 
  // Otherwise, add to symbol to table
  return the_table()->basic_add(index, string_or_null, name, len,
                                hashValue, CHECK_NULL);
}
```

</div><p>Als Ergebnis existiert jeder String nur ein Mal.</p><h3>Interne Strings richtig verwendet</h3><p>Die richtige Stelle zur Verwendung von String Interning ist der Ort an dem Zeichenketten aus externen Quellen, z.B. Datenbanken, gelesen werden. Alle Strings die bereits hartcodiert im Quelltext stehen werden durch den Compiler zu automatisch internen Strings.<br /> Ein Beispiel sieht so aus:</p><div>

```java
String city = resultSet.getString(1);
String region = resultSet.getString(2);
String countryCode = resultSet.getString(3);
double city = resultSet.getDouble(4);
double city = resultSet.getDouble(5);
 
Location location = new Location(city.intern(), region.intern(), countryCode.intern(), long, lat);
allLocations.add(location);
```

</div><p>Alle neu erstellten Location Objekte werden den internen String verwenden. Die temporären Strings werden anschließend durch die Garbage Collection entfernt.</p><h3>Wie effektiv ist String Interning</h3><p>Am besten verwendet man zur Bestimmung der Sinnhaftigkeit von Interning einen Heap Dump eines recht vollen Heaps. Es kann sogar einer von einem OutOfMemoryError sein.<br /> Wenn man ihn dann in Eclipse MAT öffnet und den <code>java.lang.String</code> aus dem Histogram auswählt, kann man im Kontextmenü „Java Basics“ und „Group By Value“ wählen<br /> <img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/yRA2soALRoeR4IVdSLkV" alt title="Mat-find-duplicate-strings" width="752" height="475" /><br /> Je nach Größe des Heaps kann dies nun eine lange Zeit dauern. Am Ende kommt ein Ergebnis wie dieses heraus, dass man entweder nach Anzahl Objekten oder nach Belegtem Speicher sortieren kann:<br /> <img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/yr6iXCVhSU2IxpW0qrfD" alt title="Mat-duplicate-strings" width="728" height="476" /><br /> In dem Screenshot sieht man eine erstaunliche Menge von zwei Millionen leerer Strings! Diese belegen unglaubliche 130 MB Speicher. Als nächstes folgt JavaScript und diverse technische Strings, wie die keys die hier für Lokalisierung verwendet werden. Und es gibt auch einige fachlich motivierte Strings in hoher Anzahl.<br /> Bei den fachlichen Strings lässt sich wahrscheinlich noch am einfachsten feststellen wo sie erstellt werden. Für alle Anderen müssten wir die Option „Merge shortest Path to GC Root“ verwenden um die Codestellen zu finden wo sie erzeugt werden.</p><h3>Kompromisse</h3><p>Warum macht man denn nicht aus allen Zeichenketten interne Strings? Weil es den Code verlangsamt! Hier ein kleines Beispiel:</p><div>

```java5
private static final int MAX = 40000000;
public static void main(String[] args) throws Exception {
	long t = System.currentTimeMillis();
	String[] arr = new String[MAX];
	for (int i = 0; i < MAX; i++) {
		arr[i] = new String(DB_DATA[i % 10]);
		// and: arr[i] = new String(DB_DATA[i % 10]).intern();
	}
	System.out.println((System.currentTimeMillis() - t) + "ms");
	System.gc();
	System.out.println(arr[0]);
}
```

</div><p>Dieser Code erstellt stark referenzierte String Objekte. Am Schluss geben wir auch noch ein Element aus, da sonst das ganze Array „arr“ wegoptimiert werden könnte. Anschließend laden wir nur 10 verschieden Strings aus unserer Datenbank. Ich verwende hier „new String()“ um die temporären Strings zu simulieren. Am Schluss führe ich noch eine Garbage Collection durch, so das alle temporären Ojekte nicht betrachtet werden.</p><p>Diesen Code habe ich auf einem 64bit Windows, JDK 1.6.0_27, i5-2520M CPU mit 8GB Ram laufen lassen. Dazu habe ich die Parameter <code>-XX:+PrintGCDetails -Xmx6G -Xmn3G</code> gesetzt. Hier die Ausgaben:<br /> <b>Ohne intern()</b></p><div>

```bash
1519ms
[GC [PSYoungGen: 2359296K->393210K(2752512K)] 2359296K->2348002K(4707456K), 5.4071058 secs] [Times: user=8.84 sys=1.00, real=5.40 secs] 
[Full GC (System) [PSYoungGen: 393210K->392902K(2752512K)] [PSOldGen: 1954792K->1954823K(1954944K)] 2348002K->2347726K(4707456K) [PSPermGen: 2707K->2707K(21248K)], 5.3242785 secs] [Times: user=3.71 sys=0.20, real=5.32 secs] 
DE
Heap
 PSYoungGen      total 2752512K, used 440088K [0x0000000740000000, 0x0000000800000000, 0x0000000800000000)
  eden space 2359296K, 18% used [0x0000000740000000,0x000000075adc6360,0x00000007d0000000)
  from space 393216K, 0% used [0x00000007d0000000,0x00000007d0000000,0x00000007e8000000)
  to   space 393216K, 0% used [0x00000007e8000000,0x00000007e8000000,0x0000000800000000)
 PSOldGen        total 1954944K, used 1954823K [0x0000000680000000, 0x00000006f7520000, 0x0000000740000000)
  object space 1954944K, 99% used [0x0000000680000000,0x00000006f7501fd8,0x00000006f7520000)
 PSPermGen       total 21248K, used 2724K [0x000000067ae00000, 0x000000067c2c0000, 0x0000000680000000)
  object space 21248K, 12% used [0x000000067ae00000,0x000000067b0a93e0,0x000000067c2c0000)
```

</div><p><b>Mit intern()</b></p><div>

```bash
4838ms
[GC [PSYoungGen: 2359296K->156506K(2752512K)] 2359296K->156506K(2757888K), 0.1962062 secs] [Times: user=0.69 sys=0.01, real=0.20 secs] 
[Full GC (System) [PSYoungGen: 156506K->156357K(2752512K)] [PSOldGen: 0K->18K(5376K)] 156506K->156376K(2757888K) [PSPermGen: 2708K->2708K(21248K)], 0.2576126 secs] [Times: user=0.25 sys=0.00, real=0.26 secs] 
DE
Heap
 PSYoungGen      total 2752512K, used 250729K [0x0000000740000000, 0x0000000800000000, 0x0000000800000000)
  eden space 2359296K, 10% used [0x0000000740000000,0x000000074f4da6f8,0x00000007d0000000)
  from space 393216K, 0% used [0x00000007d0000000,0x00000007d0000000,0x00000007e8000000)
  to   space 393216K, 0% used [0x00000007e8000000,0x00000007e8000000,0x0000000800000000)
 PSOldGen        total 5376K, used 18K [0x0000000680000000, 0x0000000680540000, 0x0000000740000000)
  object space 5376K, 0% used [0x0000000680000000,0x0000000680004b30,0x0000000680540000)
 PSPermGen       total 21248K, used 2725K [0x000000067ae00000, 0x000000067c2c0000, 0x0000000680000000)
  object space 21248K, 12% used [0x000000067ae00000,0x000000067b0a95d0,0x000000067c2c0000)
```

</div><p>Wir sehen also, dass die Differenz durchaus signifikant ist. Mit intern() benötigte der Code 3,3 Sekunden länger. Jedoch war die Speicherersparnis enorm. Am Ende benötigten wir lediglich 253472K(250M) Speicher. Ohne intern() belegten die Strings ganze 2397635K (2.4G). Dies ist schon ein beachtlicher Unterschied und zeigt anschaulich welchen Effekt String.intern() zu welchem Preis haben kann.</p>

Speicher sparen mit String Interning in Java

<p>Kürzlich besuchte ich einen Kunden um dessen Anwendungsmonitoring mit AppDynamics weiter zu verbessern. Bei meiner Ankunft wurde ich mit folgenden Worten begrüßt:<br /> „Super, dass Du da bist, Fabian. Wir können Dir ganz interessante Dinge aus dem Monitoring zeigen“. Normalerweise sind Leute aus dem Betrieb sehr besorgt, wenn sie mir so etwas sagen. Doch in diesem Fall waren sie sehr entspannt, fast schon fröhlich. „Wir hatten einen großen Produktionsausfall am Samstag als wir die neue Software live genommen haben. Nichts ging mehr!“  Oh jeh!? Was war passiert? Und warum sind die trotz des Ausfalls so gut gelaunt? Niemand mag Produktionsausfälle am Wochenende. „Ja, das war schon ein langer Samstag, aber immerhin haben wir ein Monitoring was uns gesagt hat was los war“.</p><p>Nun, schauen wir uns mal an was an diesem Samstag so passiert ist, und was das Problem war, welches den Ausfall verursacht hat.</p><h2>Ein Überblick über die Situation</h2><p>Hier ein Bild von dem was an dem Samstag um 8 Uhr morgens vorgefallen ist.<br /> <img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/CaJu5zmQVimPDE76lgXW" alt title="thread-pool-exhausted" width="700" height="475" /><br /> <span><br /> Für alle diejenigen die AppDynamics nicht kennen, hier eine kurze Einweisung in die Oberfläche:</span></p><ul><li>Der größte Bereich ist die sogenannte „Application Flow Map“. AppDynamics erkennt alle Server automatisch und überwacht ihre Kommunikation miteinander.</li><li>Auf der rechten Seite gibt es einige Statistiken. Wir sehen „Stalls“ und „Abnormal Slow requests“. AppDynamics hat also auch bemerkt, dass etwas nicht so ist wie es sein sollte.</li><li>Unten sehen wir die historische Ansicht. Da es sich zum Zeitpunkt meiner Analyse um historische Daten älter als 2 Tage handelt, wurden sie schon auf Stundenlevel aggregiert. Zum Zeitpunkt des Ausfalls selbst lagen die Daten minütlich vor.</li></ul><p>Da wir zurückblicken sind die historischen Daten für uns am interessantesten.<br /> Wir sehen auf der linken Seite den Serverstart (blaue Icons auf grünem Balken). Die Last auf das System stieg schnell an (grüne Balken). Doch das System brach dann schnell zusammen. Die Antwortzeiten (blaue Linie) stiegen und die Anzahl der Requests ging auf 0 zurück. Die Server waren abgestürzt und mussten neu gestartet werden.<br /> Aber der Restart alleine half nicht. Erst die Korrektur des Problems später normalisierte die Lage 🙂</p><h2>Was genau war passiert?</h2><p>Die Server stürzten mit einem OutOfMemory Error ab. In unserer <a href="/en/knowledge-hub/blog/java-outofmemoryerror-a-tragedy-in-seven-acts">OutOfMemoryError Serie</a> , haben wir bereits einige Probleme diskutiert, doch hier ist ein Neues: „Unable to create native thread“.</p><p>Dieser Fehler ist in der Tat sehr interessant. Ausfälle mit einem solchen Fehler deuten eher auf Konfigurationsprobleme oder einem Fehler beim Threadmanagement hin, nicht auf inperformanten Code. Also schaute ich mir die Anzahl der Threads an, welche AppDynamics mitgemessen hat:</p><p><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/clka5Yq2QvC9LtKiz0hl" alt title="thread-pool-exhausted-2" width="700" height="433" /></p><p>Ouch. Das System hatte bereits 1800 Threads erzeugt als es abstürzte.<br /> Was erzeugt also diese Threads? Ich kannte das bereits von anderen Kunden, und auch dieser Kunde konnte anhand von einigen Stall-Snapshots schnell sehen was passiert war. Die JSP Kompilation war schuldig.<br /> Alle Applikationsserver haben die Option JSPs bereits beim Serverstart, oder erst wenn durch den Benutzer angefordert, zu kompilieren. Beide Optionen sind aber problematisch wenn der Server bereits unter hoher Last gestartet wird.<br /> Behoben wurde das Problem am Sonntag Morgen um 4. Jedoch musste das Betriebsteam nicht so lange aufbleiben, das sie bereits gegen Mittag einen qualifizierten Fehlerbericht an Oracle gesendet hatten. Die „Korrektur“ von Oracle erfolgte etwas später. Die notwendige Option selbst ist nirgendwo dokumentiert, zumindest nicht so, dass man sie finden kann ohne sie zu kennen.<br /> Hier ein Screenshot aus AppDynamics, der diese Konfigurationsänderung dokumentiert.<br /> <img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/VWpuxtzCRzWqaXqQ8PHd" alt title="thread-pool-exhausted-3" width="601" height="419" /></p><h2>JSP Compiler Threads auf Weblogic begrenzen</h2><p>Der geheime Schalter war eine Umgebungsvariable die gesetzt werden muss:</p>

```

BEA_COMPILER_NUM_THREADS = 1

```

<p>Natürlich ist 1 sehr pessimistisch. Jedoch scheint dies die weit bessere Option zu sein als „unbegrenzt“, was die Standardeinstellung zu sein scheint. Niemand sollte jemals unbegrenzt Threads erzeugen. Klassisch gesehen sollte man nur so viele Threads haben wie sich auch Prozessoren in dem Server befinden. Moderne JVMs können jedoch auch gut 10 mal so viele Threads verwalten, solange sie nicht alle die CPU benötigen. Doch hier hatten wir fast 100 Compiler Threads pro CPU.</p>

Analyse eines Produktionsausfalls durch Weblogic Compiler Threads

<p>In <a href="/wissens-hub/blog/java-memory-leaks-zur-laufzeit-aufspuren-5-akt">Akt 5 unserer OutOfMemoryError Tragödie</a> , sprach ich darüber, dass es leider keine freien Tools zur Laufzeit Speicheranalyse gibt. Da ich ein kommerzielles Tool besprochen hab, habe ich direkt negatives Feedback erhalten 🙁<br /> Kurz nachdem ich den Beitrag veröffentlich hatte wurde ich auf ein Produkt namens „plumbr“ aufmerksam gemacht. Plumbr ist aktuell in der Betaphase. Das heißt, es ist aktuell kostenlos erhältlich, und ihre Macher haben sogar öffentlich zur Diskussion eines Preises aufgerufen. Trotzdem müssen wir akzeptieren, dass es keine kostenlose Lösung gibt. Das ist nicht meine Schuld, also seid mir nicht deshalb böse 🙂</p><p>In diesem kurzen Update zeige ich wie plumbr das gleiche Leak, welches ich bereits mit AppDynamics gezeigt hab, findet.<br /> <span></span></p><h3>Installation</h3><p>Plumbr ist genauso einfach zu installieren wie AppDynamics. Das Downloadpaket enthält Dateien für verschiedene Platformen, also ist direkt klar, dass es sich um einen JVMTI native Agenten in Kombination mit einem Javaagenten handelt. Nach dem Entpacken muss ich nur folgende Zeilen in die <i>catalina.bat</i> meines Tomcat 7 schreiben um den Agenten zu aktivieren:</p><div>

```bash
SET PATH=C:\Tools\plumbr\plumbr\win\64;%PATH%
set CATALINA_OPTS=-agentlib:plumbr -javaagent:C:\Tools\plumbr\plumbr\plumbr.jar
```

</div><h3>Memory Leaks Schnell Entdeckt</h3><p>Plumbr arbeitet sehr schnell! Ich deployte meine leakende Anwendung und startete mein Lastskript. Und schon nach wenigen Minuten erschien diese Meldung:</p><p> <img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/N2RcZxrQIqQh9XjVOqfS" alt title="plumbr-found-leak" width="677" height="234" /></p><p>Also musste ich nur noch den generierten Bericht öffnen:</p><p> <img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/vxIS0wvYQJEy95HsdYCS" alt title="plumbr-found-leak-2" width="700" height="748" /></p><p>Tadaa! Das Leak wurde korrekt identifiziert. Auch wird uns die wichtigste Information geliefert, nämlich wo das Leak eigentlich herkommt:</p>

```

The objects are created at
  de.codecentric.memleak.leak.StringQueueLeak.leak(de.codecentric.memleak.domain.Bookmark):58

```

<p>Vergleichen wir diese Information mit AppDynamics, so liefert plumber etwas kürzere Call Stacks. Auch fehlen die Aufrufzahlen, dennoch ist dies genau die Information die wir benötigen um das Leak zu identifizieren und zu beheben. Bonus: Es ist super simpel dargestellt.</p><h3>Weitere Verbesserungen</h3><p>Interessanterweise findet Plumbr 3 Leaks, während AppDynamics nur eines fand. Das zweite und dritte sind Objekte der Derby Datenbank:</p><p> <img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/78OgUJmQWyiZtUuOTdxA" alt title="plumbr-finalizer" width="700" height="460" /></p><p>Plumbr geht also aktuell davon aus, dass Referenzes aus dem java.lang.ref.Finalizer ein Memory Leak sind. Es gibt in der Tat einige Kontroversen darüber ob es sich wirklich um Memory Leaks handelt (z.b. in dieser <a href="http://stackoverflow.com/questions/8355064/is-memory-leak-why-java-lang-ref-finalizer-eat-so-much-memory">Diskussion auf stackoverflow</a> ). Ich habe diese Beobachtung an das plumber Entwicklerteam geschickt und kurz darauf Antwort erhalten: Zwar gehen sie davon aus, dass Finalizer ein Problem sind, jedoch wollen sie in der nächsten Version die Handhabung verändern um false positives zu reduzieren.</p><p>Ich denke plumbr ist eine wirklcih interessante Lösung. Es löst ein sehr spezifisches Problem auf elegante Art und Weise. Es ist schnell und konnte in meiner Testanwendung keinen spürbaren overhead erzeugen. Allerdings muss ich noch Tests in echten Anwendungen durchführen.</p>

Java Memory Leaks zur Laufzeit ermitteln – Nachtrag

<p><a href="/wissens-hub/blog/java-heapdumps-erzeugen-und-verstehen-4-akt">Der Akt 4 unserer Serie über OutOfMemoryError</a>  schloss mit dem Ausblick auf bessere Verfahren zum Aufspüren von Memory Leaks. Wir haben beschrieben, dass man in HeapDumps zwar große Objekte finden kann, die Aussagekraft über Leaks aber oft nur dann hoch ist, wenn ein OutOfMemoryError aufgetreten ist. Um dann in einer post-mortem Analyse etwas finden zu können sollte unbedingt der Parameter <code>-XX:+HeapDumpOnOutOfMemoryError</code> verwendet werden.</p><p>Doch dieses Verfahren ist nicht immer gut geeignet um Memory Leaks zu finden. Zum einen muss man warten bis ein Fehler auftritt, zum anderen führt ein sehr langsam wachsendes Memory Leak vielleicht gar nicht zu einem OutOfMemoryError, weil die Server, und damit die JVMs, sowieso regelmäßig für Deployments oder gerade zur Bekämpfung von Speicherproblemen neu gestartet werden.</p><p>Das Verfahren solche „schleichenden“ Memory Leaks zu finden ist deutlich komplizierter und aufwändiger als eine post-mortem Analyse. Mittels mehrerer, zeitlich versetzten, Dumps ist es zwar möglich wachsende Strukturen über Zeit zur erkennen, in der Praxis ist dies aber häufig sehr mühselig und oft kaum informativer als einzelne Dumps, da die Vielzahl von normalen Schwankungen zwischen Dumps die wirklich interessanten Delta doch deutlich überlagert. Zudem muss man zur Analyse auch die das Memory Leak verursachenden Use Cases kennen, um das Problem gezielt nachstellen zu können. Ferner ist es in Produktion zudem fast unmöglich einen vollen Heapdump zu ziehen, da das System, je nach Heap Größe, mehrere Sekunden bis Minuten still steht.</p><p>Besser ist es zur Laufzeit des Programms den Heap und die darin enthaltenen relevanten Objekte dauerhaft zu überwachen. So kann herausgefunden werden welche Objektstrukturen über eine längere Zeit weiter wachsen. Und da das Programm ja noch läuft, kann ferner auch ermittelt werden welcher Code mit dieser Objektstruktur interagiert. Dies ist mit HeapDumps nicht möglich, da keinerlei Codeinformationen enthalten sind.</p><p><span></span></p><h2>Das Konzept</h2><p>Das bei der Laufzeitanalyse durchzuführende Muster ist vergleichsweise simpel:</p><ul><li>Ermittle alle vom Programm angelegten Objekte.</li><li>Beobachte diese Objekte und vermerke ihre Größe.</li><li>Alarmiere bei „verdächtigem“ Verhalten.</li><li>Liefere zu Diagnosezwecken Inhalt und Codestellen.</li></ul><p>Leider bietet jeder der Punkte für die Praxis eine Vielzahl von Tücken, so dass es kaum Implementierungen einer derartigen Speicherüberwachung gibt. Schon das Ermitteln aller Programmobjekte ist nicht einfach. In Akt 4 habe ich empfohlen sich bei der Suche auf eigene Packages, wie z.B. <code>de.codecentric.memoryleak</code> zu konzentrieren. Doch was machen wir wenn es Standardklassen sind, die den Platz verbrauchen? Während eine Testanwendung noch überschaubar ist, bieten echte Anwendungen mehrere Millionen Objekte. Wie können sinnvoll Daten über diese komplexen Strukturen gespeichert werden? Und was ist überhaupt ein verdächtiges Verhalten? Bis zu welcher Größe und Lebensdauer sind Objekte „normal“?</p><h2>Die Implementierung</h2><p>Als Beispiel für dieses Verfahren wird hier das <a>Leak Detection Feature</a>  der <a href="http://www.appdynamics.com/">APM Lösung AppDynamics</a>  vorgestellt. Es handelt sich dabei neben dem Introscope Leak Hunter um die einzige mir bekannte Implementierung einer Leakerkennung, welche keine Art von Heap Dumps verwendet. Sollte einem Leser eine andere ähnlich funktionierende Lösung bekannt sein, so würde ich mich über Kommentare freuen!</p><h3>Annahmen</h3><p>Wie schon zu erahnen ist, ist die oben skizzierte Lösung nicht realistisch umsetzbar. Es müssen vereinfachende Annahmen getroffen werden. Für Java Programme gelten eine Reihe von Merkmalen welche man nutzen kann. Ein Merkmal, nämlich die Altersverteilung von Objekten, machen sich zum Beispiel wie in <a href="/wissens-hub/blog/java-speicher-konfiguration-und-uberwachung-3-akt">Akt 3</a>  beschrieben, die Garbage Collectoren zu Nutze indem sie Generationen verwalten.</p><p>AppDynamics trifft folgende Annahmen:</p><ul><li>Alle Objekte zu überwachen ist sinnlos. Die Erfahrung zeigt, dass ein Großteil der Memory Leaks darauf zurückzuführen ist, dass Objekte in Collection Strukturen wie Listen und Maps (z.B. Caches) abgelegt und dort vergessen werden.<br /> Deshalb überwacht AppDynamics nur diese Klassen.</li><li>Es müssen nur die Collections überwacht werden mit denen der laufende Code überhaupt interagiert. Collections die z.B. einmalig vom Application Server angelegt und seitdem nicht wieder genutzt werden fallen so heraus.</li><li>Von den aktiven Collections müssen nur diejenigen überwacht werden, welche eine Mindestanzahl von Objekten enthalten. Dies folgt aus der Eigenschaft eines Leaks stetig zu wachsen.</li><li>Die großen, aktiven Collections können bereits ein Leak sein, wirklich relevant für die Stabilität wird es jedoch erst wenn der belegte Speicher eine gewisse Größe einnimmt.</li><li>Die vorgenannten Kriterien treffen dauerhaft auf die Collections zu.</li></ul><p>Dabei geht AppDynamics bei der Suche nach Leaks in dieser Reihenfolge vor. So wird erreicht, dass die zusätzliche Belastung für die JVM reduziert wird. Zudem hat AppDynamics Verfahren entwickelt, um die Größe von Objektbäumen sehr schnell und mit sehr wenig Overhead zu berechnen, auch bei hoher Last.<br /> Trotzdem ist bei der Speicheranalyse immer mit höherem Overhead zu rechnen.</p><h2>Mein Open Source Collection Analyzer</h2><p>Da es sich bei AppDynamics um eine kommerzielle Lösung handelt, wollte ich mich selber mal an einer Implementierung eines derartigen Verfahrens machen.<br /> Meine Implementierung eines rudimentären <a href="https://github.com/CodingFabian/JavaCollectionAnalyzer">Java Memory Analyzers</a>  findet sich auf Github.</p><p>Das Grundprinzip ist einfach realisiert. Der Analyzer besteht nur aus 2 Java Klassen.</p><h3>CollectionAnalyzerAspect</h3><p>Ich treffe die gleiche Annahme wie AppDynamics und interessiere mich hier für Collections. Ich könnte auch andere Klassen nehmen die ich für Leakverdächtig halte:</p><div>

```java5
@Before("   call(* java.util.Map.put(..)) &&
            !this(de.codecentric.performance.memory.CollectionAnalyzerAspect)")
public void trackMapPuts(final JoinPoint thisJoinPoint) {
	Map target = (Map) thisJoinPoint.getTarget();
	CollectionStatistics stats = getStatistics(target);
	stats.recordWrite(getLocation(thisJoinPoint));
	stats.evaluate(target.size());
}
```

</div><p>Dieser Pointcut fügt meinen Code also vor allen Aufrufe von <code>Map.put()</code> ein. Da ich selber aber auch eine Map verwende um mir gewisse Daten zu speichern, muss ich mich selbst ausnehmen um Rekursionen vorzubeugen. Als Nächstes hole ich mir das Statistikobjekt für diese Collection um dann den schreibenden Zugriff zu protokollieren und eine Auswertung durchzuführen.<br /> Hier bin ich schon gleich den ersten Kompromiss eingegangen. Sinnvoller wäre es die Auswertung periodisch nebenläufig durchzuführen anstelle die Ausführung dafür zu pausieren.<br /> Ein interessantes Problem habe ich noch: Wie kann mich mir merken welche Collection das ist, die ich mir da gerade anschaue? Ich verwende den „identityHashCode“, wohlwissentlich, dass dies nicht 100% zuverlässig ist.</p><div>

```java5
int identityHashCode = System.identityHashCode(targetCollection);
```

</div><h3>CollectionStatistics</h3><p>Nun, da ich für jede Collection weiß, wie oft welche Methoden aufgerufen werden, was mach ich damit?</p><div>

```java5
public void evaluate(int size) {
	if (size >= DANGEROUS_SIZE) {
		System.out.printf("\nInformation for Collection %s (id: %d)\n", className, id);
		System.out.printf(" * Collection is very long (%d)!\n", size);
		if (reads == 0)	System.out.printf(" * Collection was never read!\n");
		if (deletes == 0) System.out.printf(" * Collection was never reduced!\n");
		System.out.printf("Recorded usage for this Collection:\n");
		for (String code : interactingCode) {
			System.out.printf(" * %s\n", code);
		}
	}
}
```

</div><p>Ich konnte leider nicht die Frage beantworten wann die Größe einer Collection eigentlich „schlimm“ ist. Also verwende ich der Einfachheit halber erst mal eine hartkodierte Länge der Collection. Es währe sicherlich auch eine gute Idee über eine WeakReference in dem DominatorTree der Collection die <a href="http://www.javaspecialists.eu/archive/Issue142.html">Deep Size zu berechnen</a> , aber das ist leider recht aufwändig.</p><p>Neben der Größe finde ich auch zwei weitere Dinge interessant:</p><ul><li>Wurde diese Collection ausgelesen?</li><li>Wurde etwas aus dieser Collection gelöscht?</li></ul><p>Beides sind typische Antipattern für Caches. Wenn niemand aus einer großen Liste löscht oder liest, dann warne ich deswegen. Zuletzt gebe ich noch alle Aufrufstellen aus. Eine nützliche Information!</p><h3>Ein Testlauf</h3><div>

```bash
Information for Collection java.util.ArrayList (id: 1813612981)
 * Collection is very long (5000)!
 * Collection was never reduced!
Recorded usage for this Collection:
 * de.codecentric.performance.LeakDemo:19
 * de.codecentric.performance.LeakDemo:17
 * de.codecentric.performance.LeakDemo:18
 
Information for Collection java.util.ArrayList (id: 1444378545)
 * Collection is very long (5000)!
 * Collection was never read!
 * Collection was never reduced!
Recorded usage for this Collection:
 * de.codecentric.performance.LeakDemo:18
 
Information for Collection java.util.HashMap (id: 515060127)
 * Collection is very long (5000)!
 * Collection was never read!
 * Collection was never reduced!
Recorded usage for this Collection:
 * de.codecentric.performance.LeakDemo:19
 
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
	at de.codecentric.performance.DummyData.(DummyData.java:5)
	at de.codecentric.performance.LeakDemo.runAndLeak(LeakDemo.java:17)
	at de.codecentric.performance.DemoRunner.main(DemoRunner.java:12)
```

</div><p>Es funktioniert!</p><h3>Overhead</h3><p>Zu jeder Collection alle Zugriffspfade zu speichern ist enorm Speicherintensiv. Wahrscheinlich sollte ich diese nur sammeln, wenn die CollectionStatistics auf ein Leak schließen lassen. Durch AspectJ werden meine Pointcuts auch immer angewandt. In echten Umgebungen mit hunderttausenden solcher Collections ist das sicher nicht gut. Hier müsste dynamische Bytecodeinstrumentierung verwandt werden. Auch führe ich keine zeitliche Betrachtung durch.</p><p>Wie man gut sehen kann ist die Idee einfach umgesetzt, benötigt aber für Produktionstauglichkeit einiges an Gehirnschmalz. Wer Lust hat kann gerne via <a href="https://github.com/CodingFabian/JavaCollectionAnalyzer">GitHub</a>  Patches senden.</p><h2>Memoryanalyse einer Beispielanwendung mit AppDynamics</h2><p>Schauen wir uns nun am Beispiel von AppDynamics an wie eine etwas professionellere Lösung arbeitet.</p><h3>10:43 – Application Server Restart</h3><p>Startet man die AppDynamics Leak Detection ist nicht unmittelbar ein Ergebnis sichtbar. Im Hintergrund werden die Collections analysiert. Nach einiger Zeit tauchen jedoch möglicherweise leakende Collections auf.</p><h3>11:00 – Collection erkannt</h3><p><img title="01-collection-detected" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/PyeaEYQQTCpkvaTIwnYK" alt width="700" height="155" /></p><p>Die <code>java.util.LinkedList</code> hier erachtet AppDynamics als interessant. Mit 56.881 Einträgen ist sie in der Tat schon recht umfangreich. Da es aber noch keine Langzeitinformationen gibt ist sie nicht als „potentially leaking“ markiert.</p><h3>11:10 – Collection potentially leaking</h3><p><img loading="lazy" title="02-collection-leaked" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/5bgOFCCZR8KsmVEPme4K" alt width="700" height="53" /></p><p>Nach etwas Zeit ist diese Liste weiter gewachsen. Mit 98.850 Einträgen ist sie schon fast doppelt so groß wie auf dem letzten Bild. Die internen Heuristiken markieren sie jetzt als „potentially leaking“.</p><h3>11:17 – Das Leak wächst weiter</h3><p><img loading="lazy" title="03-leak-overview" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Qg8ssQpcQt2Vu6XoXgnw" alt width="695" height="370" /></p><p>Die Übersichtsansicht zeigt, dass das Leak weiter wächst. Garbage Collections würden hier ebenfalls eingetragen um Effekte von SoftReferences sehen zu können.</p><h3>11:30 – Ein Speicherleck enthüllt</h3><p><img loading="lazy" title="04-leak-content" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/1FJTA7ARaOOxH2OEZ53J" alt width="694" height="384" /></p><p>Die Content Inspection zeigt den Inhalt der Collection. In diesem Fall sind es 118.990 <code>java.lang.String</code> Objekte mit einer Gesamtgröße von 20MB.<br /> AppDynamics erlaubt es auch diese Collection und ihren Inhalt als Dump zur genaueren Analyse wegzuschreiben.</p><h3>11:38 – Der Schuldige wird identifiziert</h3><p><img loading="lazy" title="05-leak-creator" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/1UyjyhOnRYyOOLWQ4F0o" alt width="695" height="330" /></p><p>Mittels einer Access Tracking Session stellt AppDynamics fest, wer das Speicherleck verursacht. Während man bis hier hin auch irgendwie mittels Heap Dumps kommen könnte, ist diese Auflistung der Aufrufhierarchien etwas Besonderes. LinkedLists mit Strings hätten viele Stellen im Code nutzen können, aber diese leakende LinkedList wird in der „newbookmark“ Business Transaktion verwendend.<br /> Die <code>BookmarkDaoImpl</code> fügt in Zeile 50 Strings in diese Liste ein. Lesenden, oder gar Code der Objekte aus der Liste entfernt, konte AppDynamics nicht feststellen.</p><p>Somit liefert AppDynamics alle Informationen die man für ein Analyse und Behebung von Memory Leaks benötigt:</p><ul><li>Potentiellen Memory Leak Objektstrukturen werden angezeigt.</li><li>Man wird über die Gefahr eines Memory Leaks automatisch informiert.</li><li>Die Inhalte der Objektstrukturen können analysiert werden.</li><li>Die Business Transaktion(en) (Use Case) die für das Leak verantwortlich ist (sind), werden identifiziert.</li><li>Alle Zugriffsmethoden auf das potentielle Leak werden angezeigt.</li></ul><p>Die Entscheidung, ob etwas tatsächlich ein Memory Leak ist, liegt aber weiterhin beim Entwickler.</p><h2>Fazit</h2><p>Es ist möglich Java Memory Leaks zur Laufzeit ohne die Erzeugung von Heap Dumps zur Laufzeit zu identifizieren und zu beheben. Die Information über die Codepfade ist äußerst wertvoll bei der Korrektur eines Leaks. Leider gibt es keine frei verfügbaren Produkte die bei der Leaksuche auf diese Art helfen. Eine Eigenimplementierung ist wie beschrieben nicht zu empfehlen.<br /> Allerdings bietet AppDynamics eine 30 Tage Testversion an, so dass jeder die beschriebenen Funktionen selber testen kann.</p>

Java Memory Leaks zur Laufzeit aufspüren (5. Akt)

<p>Die <a href="http://markmail.org/message/sxjtefpayanbqfe5">Abstimmung</a>  ist vorrüber: <a href="http://harmony.apache.org/">Apache Harmony</a> , eine offene Java Implementatierung, wird eingestellt.</p><p>Nachdem IBM bereits seine Unterstützung an Harmony eingestellt hat und zum <a href="http://openjdk.java.net/">Open JDK</a>  gewechselt ist, hat das Interesse an Harmony stark nachgelassen. Verstärkend kamen die endlosen Querelen um das Technology Compatibility Kit (TCK) und die Google VM Dalvik, die auf Harmony basiert, hinzu. Es stand also nicht mehr wirklich gut um Harmony.</p><p>Zwar ist es traurig, dass es keine Java Implementierung bei Apache geben wird, jedoch ist es wenigstens gut zu sehen, dass die Open JDK entwicklung nun ernsthaft vorangetrieben wird.</p>

Apache Harmony ist tot – Lang lebe Open JDK

<p>Als wir vor 3 Monaten über den Relaunch unserer Homepage nachdachten, kannten wir schon einige, für uns wichtige, Eckdaten:</p><ul><li>Benutzung von Cloud Infrastruktur</li><li>Schnelle Antwortzeiten</li><li>flexible Standardsoftware</li><li>Benutzerfreundliches Redaktionssystem</li></ul><p>Zwar hatten wir in der Vergangenheit <a href="http://www.opencms.org/en/">OpenCMS</a>  für die Homepage benutzt, jedoch entschieden wir uns für den Relaunch für <a href="http://wordpress.org/">WordPress</a> . WordPress war bei uns schon seit Jahren als Blogsoftware im Einsatz und überzeugte vor allem durch seine Benutzerfreundlichkeit und Funktionsumfang. Es ist ein einfaches, aber doch sehr mächtiges System, welches bereits in der Standardkonfiguration ausreichend Funktionalität liefert. Dazu ist es sehr gut mit einfachen eigenen oder schon fertigen Plugins zu erweitern.</p><p>Aber in diesem Beitrag soll es nicht um die Entscheidungsfindung zu WordPress gehen, sondern darum wie wir eine durchschnittlich gut besuchte Homepage und Blog gratis betreiben, ohne dafür Geschwindigkeit und Antwortzeiten zu opfern.</p><p><span></span></p><p>Gratis? – Ja!</p><p>Amazon bietet Neukunden eine kostenlose „micro tier“ für ein Jahr: <a href="http://aws.amazon.com/free/">aws.amazon.com/free</a> . Neukunden sind dabei neu erstellte Accounts. Ok, zwar gratis, aber ziemlich begrenzt: Eine virtuelle CPU, 613 MB Ram und man muss Amazon Linux verwenden.</p><p>Nach Start dieser micro instanz wird automatisch ein 8G EBS eingebunden. Dorthin installierte ich dann auch alle notwendigen Dienste für WordPress:</p><div>

```bash
sudo yum install httpd mysql mysqld php php-mysql
```

</div><p>Zwar sah alles nach der Einrichtung von WordPress ganz nett aus, doch die Performance war relativ schnell am Boden, sobald mehrere Benutzer die Seite besuchten.<br /> Die erste Aktion war es APC zu installieren. APC ist ein PHP Bytecodecache und –optimizer und sollte immer bei PHP Seiten eingesetzt werden:</p><div>

```bash
sudo yum install php-pecl-apc
```

</div><p>Die Situation besserte sich schon etwas, jedoch benötigten wir mehr um die Seite stabil zu betreiben.</p><p>Bei der Arbeit mit den gratis micro Instanzen lernte ich zwei Dinge:</p><ul><li>„Steal Time“! nie zuvor sah ich diesen Wert so extrem hoch:<div>

```bash
Cpu(s): 2.0%us, 0.3%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 97.7%st
```

</div><p>Dies bedeutet, dass das System die CPU nutzen möchte, diese aber nicht vom Hypervisor zur Verfügung gestellt bekommt.</p></li><li>EBS ist manchmal echt langsam!</li></ul><p>Der Prozess der unter diesen Umständen am meisten zu leiden hatte war der mysqld, also kümmerte ich mich zuerst um ihn.</p><p>Ich wendete die <a href="http://www.codinghorror.com/blog/files/matt-mullenweg-wordpress-mysql-recommendations.txt">WordPress mysql tuning Empfehlungen</a>  von Matt Mullenweg an, jedoch zeigten sie keinen merklichen Erfolg.<br /> Es war einfach nicht möglich wegen der CPU und IO Begrenzungen aus Mysql gute Performance herauszubekommen. Und in MySQL kann man auch nicht viel cachen, da kaum Speicher zur Verfügung steht.</p><p>Also musste ich den Zugriff auf MySQL reduzieren und suchte nach einem guten WordPress Caching Plugin. Und in der Tat es gibt sogar relativ viele:</p><p><img title="wp-cache" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/kD9CePqpTn20Yci23XEO" alt width="582" height="309" /></p><p>Ich wählte das Quick Cache Plugin (mittlerweile gibt es das nicht mehr, eine Alternative wäre Total Cache) und wurde mit einer drastischen Verbesserung belohnt. Zusätzliche Besucher verursachten kaum mehr Last, da diese alle gecachte Versionen sahen.</p><p>Leider funktionierte dies nicht für eine größere Anzahl an gleichzeitig arbeitenden Redakteuren, da Caching bei Redakteuren ausgeschaltet ist. Und da Amazon die volle CPU Nutzung auf kurze „Bursts“ limitiert, mussten Redakteure manchmal für 30 Sekunden warten. Um dies zu verbessern, limitierte ich die CPU Nutzung durch den Mysqld Prozess:</p><div>

```bash
wget http://centos.alt.ru/repository/centos/5/i386/cpulimit-1.2-1.el5.i386.rpm
rpm -i cpulimit-1.2-1.el5.i386.rpm
nohup sudo cpulimit -v --exe mysqld --limit 50 &
```

</div><p>Nun da CPU und IO Nutzung weitgehend durch cleveres Caching optimiert waren, konnte ich mich an die Feinjustierung der httpd.conf machen um sicherzustellen, dass der Server die richtige Anzahl von gleichzeitigen Requests verarbeitet. Da wir mod_prefork einsetzen schaute ich nach der durchschnittlichen Speicherbenutzung der Apache Workerprozesse. Um diese zu optimieren entfernte ich noch einige unnötige Module und gelangte so auf etwa 25 bis 35MB Speichernutzung pro Prozess. Mysql nutzte rund 80MB, also wählte ich 15 Worker Prozesse, welche dann zusammen fast den gesamten Speicher nutzten.</p><div>

```bash
StartServers 15
MinSpareServers 15
MaxSpareServers 15
ServerLimit 15
MaxClients 15
MaxRequestsPerChild 500
```

</div><p>MaxServersPerChild ist dabei wichtig, damit die Prozesse in regelmäßigen Abständen neu erstellt werden. Gerade bei so knapp bemessenem Speicher könnte ein leakender Prozess sich negativ auswirken.</p><p>15 gleichzeitige Verbindungen klingt nach einem sehr geringem Limit, also musste ich sicherstellen, dass die Serverkommunikation auf ein Minimum reduziert wird.</p><h2>Web Performance Optimization</h2><p>Da der Server nun solide aufgestellt war, fanden sich die einfach zu erreichenden Optimierungen auf der Browserseite. Der Standardoutput eines WordPress Themes mit einigen Plugins ist relativ umfangreich und unübersichtlich. Da ich das Theme nicht großartig anpassen wollte, und ich auch den Code der Plugins nicht modifizieren konnte ohne ihn bei Upgrades wieder zu brechen, benötigte ich eine bessere Alternative.</p><p>Und diese Alternative ist das fantastische mod_pagespeed Modul für den httpd von Google.</p><div>

```bash
sudo rpm -i mod-pagespeed-*.rpm
sudo service httpd restart
```

</div><p>Der Effekt war signifikant. Die durch mod_pagespeed gesetzten aggressiven Cachingeinstellungen verhinderten fast alle Serveranfragen, wodurch die wenigen Worker Prozeses entlastet wurden. Auch die automatisch reduzierten Bildgrößen waren sehr bemerkbar. Besonders in einem Content Management Systemen, wo man relativ wenig Einfluss auf die von Autoren hochgeladenen Bilder hat, ist die automatische Rekomprimierung sehr effektiv.<br /> Jedoch muss mod_pagespeed dafür selbst die Bilder Anfragen, sie werden dann weiterhin bei jedem Seitenaufruf lokal geladen um den Cache auf Gültigkeit zu prüfen:</p><div>

```bash
46.137.99.225 - - [07/Aug/2011:03:54:37 +0200] "GET /wp-content/uploads/2011/07/wanted-memory.png HTTP/1.1" 200 116616 "-" "Serf/0.7.2 mod_pagespeed/0.9.18.6-886"
```

</div><p>Hier kommt mod_expires ins Spiel:</p><div>

```bash
ExpiresActive On
ExpiresDefault "access plus 10 days"
```

</div><p>Die sinnvolle Gültigkeitszeit für ein Bild hängt dabei natürlich von der Art der Bilder ab. Niemals sich ändernde Bilder können Jahre gecached werden, andere vielleicht nur Minuten. Als Startpunkt ist eine Woche sicherlich garnicht schlecht. Da es hierbei auch nur im den lokalen mod_pagespeed Cache handelt kann man diesen zur Not auch löschen.</p><p>Um das Theme dann doch noch etwas zu entrümpeln entfernte ich viele Einstellungen über die functions.php:</p><div>

```php
remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wlwmanifest_link');
remove_action('wp_head', 'feed_links_extra', 3);
remove_action('wp_head', 'feed_links', 2);
remove_action('wp_head', 'remote_login_js_loader');
function remove_generator() { return ''; }
add_filter('the_generator', 'remove_generator');
```

</div><p>WordPress liefert standardmäßig eine eigene jQuery Javascript Bibliothek aus, aber um noch mehr von Caching zu profitieren und weitere Requests zu sparen nutzen wir einfach die jQuery Bibliothek aus dem Content Delivery Network von Google.<br /> Ausserdem laden wir nicht mehr die l10n.js, da wir sie nicht benötigen:</p><div>

```php
function init_scripts() {
wp_deregister_script( 'jquery' );
wp_register_script( 'jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js');
wp_deregister_script('l10n');
}
 
if (!is_admin()) {
add_action('init', 'init_scripts');
}
```

</div><p>Die meisten dieser Optimierungen werden jedoch nicht für die Administrationsseiten durchgeführt. Die Adminseiten sind so komplex, dass Seiteneffekte schwer zu überschauen sind.</p><p>Das Resultat meiner Bemühungen ist eine pagespeed Bewertung von www.codecentric.de von 95/100.</p><p>Für einen einzelnen Benutzer sollte die Seite in weniger als einer Sekunde komplett geladen sein. Für viele Benutzer wahrscheinlich sogar in unter 300ms.</p><p>So, wie skaliert das Ganze nun? Um das herauszufinden führte ich ein Benchmark gegen unsere alte dedizierte Maschine und die neue EC2 Micro Instanz durch. 4 echte CPUs gegen eine virtuelle. 2GB Ram gegen 613 MB. Faierweise muss ich sagen, dass ich nie die alte Homepage derartig optimiert habe.<br /> Für das Benchmark verwende ich <a href="http://httpd.apache.org/docs/2.0/programs/ab.html">apachebench</a> , zuerst mit 5 gleichzeitigen Benutzern und 50 Requests für die Homepage.</p><p>Alt:</p><div>

```bash
Requests per second:    3.07 [#/sec] (mean)
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        9   71 424.8      9    3014
Processing:   989 1513 461.3   1352    3420
Waiting:      597  865 344.2    768    2861
Total:       1004 1584 603.1   1373    4287
```

</div><p>Neu:</p><div>

```bash
Requests per second:    18.04 [#/sec] (mean)
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       38   44   4.4     44      52
Processing:   183  224  47.3    220     493
Waiting:       58   89  41.4     80     335
Total:        222  268  49.5    265     544
```

</div><p>Trotz der längeren Connect Zeit in das Amazon Datacenter in Dublin, sind die Ergebnisse beeindruckend.</p><p>Da ich bereits wusste, dass der Server nur 15 parallele Requests verarbeiten kann, versuchte ich 45 Requests mit jeweils 20 Anfragen.</p><div>

```bash
Requests per second:    50.00 [#/sec] (mean)
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       39   42   4.8     43      78
Processing:   300  839 116.7    869    1181
Waiting:      179  711 115.2    742    1049
Total:        340  881 116.8    912    1225
```

</div><p>Auch mit so hoher Last sind die Antwortzeiten relativ stabil unter einer Sekunde. Cool!</p><h3>Ist „micro“ genug?</h3><p>Ich bin mir relativ sicher, dass uns eine Micro Instanz lange ausreichen wird. Aber es gab doch ein Problem, welches ich zum Anlass für folgenden Tweet nahm:<br /> <a href="http://twitter.com/#!/CodingFabian/status/100558375905001472"><img loading="lazy" title src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/rsJ2nYqvRdisO7zAolZM" alt width="499" height="220" /></a> </p><p>Als wir das DNS Update veranlassten passierte etwas unheimliches. Die Seite wurde echt langsam! Ich hatte keine Ahnung wieso, hatte ich doch alles geprüft.<br /> Aber unwissentlich hatten wir einen distributed denial of service (DDoS) Angriff ausgelöst. Als ich in das <em>access_log</em> sah, fand ich heraus wer der Schuldige war.<br /> Sämtliche mir bekannte Suchmaschinen indexierten unsere Seite und Blog. Hinzu kamen noch jede Menge mir bis dahin unbekannter Suchmaschinen und Crawler. Um dem Ganzen die Krone aufzusetzen hatten wir im internen Chat und via e-Mail den Relaunch bekanntgegeben. Also luden zusätzlich noch über hundert codecentrics die Seite.<br /> Und alle Caches waren noch kalt 🙁</p><h3>Rettung durch die Cloud!</h3><p>Da es sich um Amazon Server handelt, konnte ich diese Situation ganz einfach lösen. Ich stoppte die Instanz, stellte sie von t1.micro auf m1.small und startete sie wieder.<br /> Die Maschine kam schnell wieder hoch und wies sich durch ein kleines Script automatisch die virtuelle IP wieder zu. Ich drehte noch schnell die Apache Worker Prozesse auf 50 hoch und schon lief die Seite akzeptabel.<br /> Dieser gesamte „Upscaling“ Prozess dauerte keine 30 Sekunden, und war kaum bemerkbar für die Benutzer, welche sowieso schon etwas unter der Performance litten.<br /> Der Server war zwar immer noch stark belastet, aber die Antwortzeiten waren auf stabilen 1-2 Sekunden.</p><p>Nach vier Stunden war der Spuk vorbei. Die Suchmaschinen waren davongezogen und die codecentrics im Wochenende.<br /> 30 Sekunden später war der Server wieder eine t1.micro, und gratis. Kosten für diese Peak Load: 16 cents.</p><p>Ich bin mir sicher, dass wir eine derartig hohe Last lange Zeit nicht mehr haben werden. Und falls doch? Dann können wir in weniger als einer Minute hochskalieren.<br /> Beispielsweise an Freitagen, wo viele Mitarbeiter Blogbeiträge schreiben, oder Inhalt für die Homepage einstellen.</p><p>ich hoffe, Ihnen hat mein Erfahrungsbericht nützliche Informationen geliefert. Falls Sie in die Cloud gehen wollen, oder sie Performance im Browser oder auf dem Server optimieren wollen, kontaktieren Sie uns doch einfach.</p>

Hosting einer Hoch Performanten Homepage in der Cloud

<p>Eine Einführung in das Thema <a href="/leistungen">Web Performance Optimization</a>  gab ich am 11. Oktober auf der <a href="http://webtechcon.de/">Web Tech Conference</a> . Zielpublikum der Konferenz waren Webentwickler aller Art. Jedoch waren durch die zeitgleich stattfindende <a href="http://phpconference.com/">International PHP Conference</a>  überdurchschnittlich viele PHP Entwickler anwesend.<br /> Der Vortrag war gut besucht, und das Feedback ok. Einige Teilnehmer bemängelten die fehlende Tiefe. Der Vortrag war zwar bewusst als Einstieg angelegt, aber ich werde wohl beim nächsten Mal etwas mehr Details aufnehmen.<br /> Vielen Dank an den <a href="http://software-support.biz/">Software und Support Verlag</a>  für die Organisation dieser Konferenz.</p><div><strong><a href="http://www.slideshare.net/fabianlange/web-performance-optimization-web-tech-conference-2011-talk" target="_blank">Web Performance Optimization – Web Tech Conference 2011 Talk</a> </strong><div><div><div><p>Klicken Sie auf den unteren Button, um den Inhalt von www.slideshare.net zu laden.</p><p><a href="#">Inhalt laden</a> </p></div></div><div></div></div><div>View more <a href="http://www.slideshare.net/" target="_blank">presentations</a>  from <a href="http://www.slideshare.net/fabianlange" target="_blank">Fabian Lange</a> </div></div>

Vortrag „Web Performance Optimization“ auf der Web Tech Conference 2011

<p>In <a href="http://www.slideshare.net/fabianlange/web-performance-optimization-web-tech-conference-2011-talk">meinem Vortrag</a>  über Web Performance Optimization auf der Web Tech Conference erwähnte ich mod_pagespeed als super funktionierende automatische Lösung um Requests von CSS und JavaScripts zu reduzieren und so Webseiten schneller zu machen. Doch dann fiel mir beim Betrachten der Statistiken von www.codecentric.de auf, dass mod_pagespeed gar nicht korrekt funktionierte.</p><p>Eigentlich sollten mehrere CSS Dateien zu einer zusammengefügt werden, doch ich fand diese Anweisungen im HTML:</p><div>

```html4strict
<link rel='stylesheet' id='login-css' href='wp-admin/css/login.css,qver=20110610.pagespeed.cf.ZqFxSZoD1J.css' type='text/css' media='all'/>
<link rel='stylesheet' id='colors-fresh-css' href='wp-admin/css/colors-fresh.css,qver=20110703.pagespeed.cf.ldpZyBlEpG.css' type='text/css' media='all'/>
```

</div><p>Ok, das ist zumindest schonmal die von Pagespeed verarbeitete, d.h. minifizierte, Version der CSS Dateien. Ohne Pagespeed sähe die Stelle so aus:</p><div>

```html4strict
<link rel='stylesheet' id='login-css' href='wp-admin/css/login.css?ver=20110610' type='text/css' media='all'/>
<link rel='stylesheet' id='colors-fresh-css' href='wp-admin/css/colors-fresh.css?ver=20110703' type='text/css' media='all'/>
```

</div><p>Diese zwei Zeilen sollte eigentlich von dem Filter „combine_css“ zu einer Zeile zusammengefasst werden. Die Dokumentation beschreibt aber, dass dies in der Tat nicht immer passiert:</p><blockquote><p>The CSS Combine filter operates within the scope of a „flush window“. Specifically, large, or dynamically generated HTML files may be „flushed“ by the resource generator before they are complete. When the CSS combiner encounters a flush, it will emit all CSS combinations seen up to the point of the flush. After the flush, it will begin collecting a new CSS combination.</p></blockquote><p>und</p><blockquote><p>IE Directives containing CSS links form a „barrier“ for the CSS combiner. Multiple CSS elements found before an IE directive are combined together immediately before the IE directive. Multiple CSS elements found after are also combined, but the combination does not span across the IE directive, as that would affect the order that the browser sees the CSS elements.</p></blockquote><p>Jedoch ist hier weder eine IE Direktive, noch sind die beiden Zeilen nicht im gleichen „Flush-Fenster“. Warum funktioniert es also nicht?<br /> <span><br /> Es gibt tatsächlich eine, leider nicht dokumentierte, weitere Bedingung:</span></p><blockquote><p>Tags können nur zusammengefasst werden wenn dadurch keine Information verloren geht.</p></blockquote><p>Welche Information dies in diesem Beispiel wäre, kann man relativ leicht feststellten: Die beiden Identifier „login-css“ und „colors-fresh-css“ könnten dann nicht weiterexistieren. Es wäre ja denkbar, dass diese Identifier von JavaScript Code verwendet würden, um das CSS zu modifizieren oder andere Dinge zu tun.</p><p>Aber wo kommen diese IDs eigentlich her? Brauchen wir sie? Und wie können wir sie loswerden?</p><p>WordPress besitzt eine Funktion namens „<a href="http://codex.wordpress.org/Function_Reference/wp_enqueue_style">wp_enqueue_style</a> “ mit der Plugin- und Themeentwickler Styles dynamisch in den head-Bereich einfügen können. wp_enqueue_style nimmt als ersten Parameter ein sogenanntes handle. Genau dieses handle verwendet WordPress um sie als ID zu verwenden.<br /> In der Regel braucht man die ID nicht, da es keinen standardmäßig vorhandenen Code gibt, der über die ID der Styles an die Style-links geht. Und selber wird man wahrscheinlich auch keinen Code schreiben, der IDs auf Style link Tags benötigt. WordPress fügt die ID der vollständigkeit halber an.<br /> Damit mod_pagespeed die CSS Dateien zusammenfügen kann, muss sie jedoch weg. Das ganze geht am einfachsten über WordPress Filter. Es gibt nämlich einen Filter der für den fertigen Style Link Tag aufgerufen wird: „style_loader_tag“.</p><div>

```php
function remove_style_id($link) {
        return preg_replace("/id='.*-css'/", "", $link);
}
add_filter('style_loader_tag', 'remove_style_id');
```

</div><p>Dies würde dann in folgendem HTML resultieren:</p><div>

```html4strict
<link rel='stylesheet' href='wp-admin/css/login.css?ver=20110610' type='text/css' media='all'/>
<link rel='stylesheet' href='wp-admin/css/colors-fresh.css?ver=20110703' type='text/css' media='all'/>
```

</div><p>Und es wird nun in der Tat korrekt zusammengefasst:</p><div>

```html4strict
<link rel="stylesheet" type="text/css" href="wp-admin/css/login.css,,qver==20110610+colors-fresh.css,,qver==20110703,Mcc.35EZfaJvqU.css.pagespeed.cf.I5odih6TFY.css" media="all"/>
```

</div><p>Abschließend bleibt noch zu erwähnen, dass die gleiche Einschränkung auch für „media“ gilt. Bietet man Styles für verschiedene Medien an, können diese ebenfalls nicht zusammengefasst werden. Hier sollte man entsprechend prüfen ob man die Unterscheidung braucht, alle CSS den richtigen media-Typ haben und gegebenenfalls das media Attribut entfernen.</p>

WordPress und Mod_Pagespeed – Warum combine_css nicht funktioniert

<p>Deadlocks sind üble Fehler für Programmierer. Sie treten niemals in der Entwicklungsumgebung auf, sondern nur in Produktion. Und weil sie die Produktion beeinträchtigen, werden sie von den Betriebsteams schnell durch Neustarts beseitigt. Leider gehen dabei auch wertvolle Hinweise auf die Ursache verloren.</p><p>Als Entwickler hat man so fast nie die Gelegenheit ein Deadlock in Aktion zu sehen.</p><p>Wäre es nicht toll diese Informationen zur Analyse zu haben? Etwas das so aussieht:<br /> <img title="deadlocks" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/vU9SCMlxSLyhtRhnqNZp" alt width="611" height="164" /><br /> Gute Nachrichten! Ich habe mir dieses Bild nicht ausgedacht, sondern aus <a href="http://www.appdynamics.com/">AppDynamics</a>  entnommen. AppDynamics erkennt Deadlocks in Produktionsumgebungen automatisch und bietet so alle Informationen zur Beseitigung der Problemursache.</p><p><span><br /> Für den folgenden kurzen Screencast habe ich das „Dining Philosophers“ Problem genutzt, welches in einer abgewandelten Variante von Dr. Heinz Kabutz in seinem <a href="http://www.javaspecialists.eu/archive/Issue194.html">letzten Newsletter</a>  behandelt wurde. Heinz war kürzlich mit seinem Java Specialists Master Course bei codecentric in Düsseldorf und hat mir davon erzählt. Ich hatte schon länger vor das Feature zu demonstrieren, nur nie Zeit ein Deadlock zu programmieren. Danke Heinz 🙂</span></p><div></div><p>Sobald der AppDynamics Agent in einer JVM läuft, beobachtet er die Thead Aktivität und diagnostiziert Deadlocks völlig automatisch. Es ist keinerlei Konfiguration notwendig, und verursacht keinen nennenswerten Overhead, weshalb es sich insbesondere für Produktionsysteme eignet.</p><p>Da die Informationen für die Entwickler von AppDynamics gesichert werden, kann der Server problemlos neu gestartet werden. Die notwendigen Diagnoseinformationen stehen weiterhin zur Verfügung. Diese nützliche Funktion hat uns schon in einigen Java Performance Troubleshooting Einsätzen geholfen.</p><p><img loading="lazy" title="monitors" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/prlXYJnkQhispckX6WIf" alt width="633" height="473" /></p><p>Für mich ist diese Deadlockerkennung ein Geheimtipp in AppDynamics. Das Feature ist leider nicht sofort zu erkennen, da es keinerlei Konfiguration bedarf und nur im Fehlerfall in Erscheinung trifft. Aber eigentlich ist es ja auch nicht schlecht, dass man solche Dinge nicht einstellen muss.</p>

Automatische Java Deadlock Erkennung mit AppDynamics

<p>Im 2. Akt dieser <a href="/wissens-hub/blog/java-outofmemoryerror-eine-tragodie-in-sieben-akten">Serie</a>  haben wir <a href="/wissens-hub/blog/java-memory-leaks-und-andere-ubeltater-2-akt">Java Memory Leaks</a>  vorgestellt. Dort wurde auch erläutert wie Memory Leaks in Java entstehen können und was Sie von klassischen Memory Leaks unterscheidet. Dieser Beitrag soll aufzeigen, wie man sich die Objekte im Heap im Detail anschaut. Inklusive der Referenzen zwischen den Objekten, um potentielle Java Memory Leaks zu identifzieren.</p><p>Das einfachste Werkzeug zur Analyse von Speicherproblemen sind so genannte Java Heapdumps, die man beispielsweise im Fehlerfall durch die JVM  Option <code>-XX:+HeapDumpOnOutOfMemoryError</code> automatisch erzeugen kann. In diesem Fall wird der Dump vor dem Beenden der JVM erzeugt – dabei spricht man dann auch von einer „Post mortem“ Analyse. Natürlich kann man diese Dumps auch manuell zur Laufzeit erzeugen, aber dazu später mehr.</p><p>Während wir uns in diesem Akt mit Heapdums beschäftigen, werden wir im nächsten Akt sehen welche anderen Alternativen es gibt um verlorenem Speicher auf die Spur zu kommen.</p><p><strong>Java Heapdumps</strong></p><p>Unter einem Heapdump versteht man eine textuelle oder binäre Abbildung des Java Heaps, die i.d.R. in eine Datei geschrieben wird. Aus den Informationen in einem Heapdump lassen sich mit verschiedenen Werkzeugen die gesamten Objekte, inklusive ihrer Referenzen untereinander, rekonstruieren. Es fehlt allerdings die Information in welchem Heap Bereich sich die Objekte befanden. Dies ist eigentlich schade, haben wir doch in <a href="/wissens-hub/blog/java-speicher-konfiguration-und-uberwachung-3-akt">Akt 3</a>  gelernt welche Bedeutung die Bereiche haben können. Diese Information ist jedoch zum Finden von Java Memory Leaks in Heapdumps eher uninteressant.</p><p><strong>Gesucht: Lebendig oder Tot</strong></p><p><img title="Wanted Memory" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/MjyaXvknSA26RtvH7HOU" alt width="199" height="267" />Heapdumps können zwei Arten von Objekten enthalten:</p><ul><li>Nur lebendige Objekte (also Objekte welche über eine GC Root Referenz erreichbar sind)</li><li>Alle Objekte (also inklusive den nicht mehr referenzierten Objekten)</li></ul><p>Da die lebendigen Objekte über verschiedene VM interne Mechanismen, wie Markierungslisten oder GC Roots, zu ermitteln sind, ist ein Heapdump mit ausschließlich lebendigen Objekten relativ schnell durch die JVM erstellbar.</p><p>Soll der Heapdump jedoch auch die nicht mehr referenzierten Objekte beinhalten, so dauert die Erzeugung viel länger und benötigt auch wesentlich mehr Speicherplatz.<br /> <span> In der Regel reichen die lebendigen Objekte auch schon für die Suche nach Memory Leaks aus. Nicht mehr referenzierte Objekte sind höchstens in der Betrachtung von Objekt Cycling oder GC Thrashing interessant. In diesen Fällen möchte man nicht nur nach Leaks suchen, sondern auch nach Objekten von denen unnötig viele erzeugt wurden.</span></p><p><strong>Heapdumps erzeugen</strong></p><p>Wie schon anfangs angedeutet, lassen sich Heapdumps auf zwei Arten erstellen. Doch der Erstellungsprozess eines Dumps führt zu einem Stillstand der Anwendungen, weil die Ausführung während der Erzeugung des Dumps gestoppt wird. Dies ist deshalb sinnvoll, weil sich ansonsten der Zustand des Heaps während der Erzeugung ändern würde. Deshalb ist von der übermäßigen Nutzung dieser Funktionalität in einem produktivem System abzuraten.</p><ol><li>Durch die JVM Option <code>-XX:+HeapDumpOnOutOfMemoryError</code> wird sobald die JVM sich mit einem OutOfMemoryError beendet ein Heapdump geschrieben.<br /> Es gibt keinen Grund diese Option nicht zu verwenden. Die JVM ist schon abgestürzt, und negative Performance uninteressant. Lediglich die Größe der Heapdumps stellt manche Server vor ein Problem.<br /> Da der Heapdump aber oft die einzige Informationsquelle über den Absturz ist, sollte er auf jeden Fall erzeugt werden. Nach einem Absturz sollte der Server Admin den Dump sichern, damit eine Post-mortem Analyse stattfinden kann, Leider werden sie häufig aus Platzgründen einfach gelöscht.</li><li>Mit dem der JVM beliegendem Werkzeug jmap kann ein Heapdump von der Kommandozeile erzeugt werden:

```
jmap -dump:live,format=b,file=<filename> <PID>
```

<p>Die Option live bewirkt, dass nur lebendige Objekte gedumped werden und kann auch weggelassen werden, will man den gesamten Heap sehen. Als Format bietet sich „b“ für „binär“ an. Es gibt auch eine ASCII Version, die auch manuell ausgewertet werden könnten – dies ist in der Praxis auf Grund der Datenmenge aber meist nicht möglich.</p></li></ol><p><strong>Heap, zeig was in Dir steckt!</strong></p><p>Es gibt eine ganze Reihe von Werkzeugen mit denen Heapdumps offline untersucht werden können. Jedoch lohnt ein Vergleich hier nicht, da es einen konkurrenzlosen Gewinner gibt:<br /> <a href="http://www.eclipse.org/mat/">Eclipse Memory Analyzer Toolkit (Eclipse MAT)</a> </p><p>Eclipse MAT kann Heapdumps verschiedenster Formate und Größen lesen, verarbeiten, analysieren und auswerten. Das Ganze mit einer hervorragend zu bedienenden, leider machnmal etwas zu mächtigen, Benutzeroberfläche und: völlig kostenlos. Ein wesentlicher Vorteil ist auch, dass MAT den Heapdump beim ersten Laden indiziert, so dass zum einen sehr große Heaps analysiert werden können und zum anderen die Analyse sehr schnell ist. Gerade ältere Tools hatten oft das Problem, dass der Heapdump zur Analyse komplett in den Arbeitsspeicher geladen wurde und man i.d.R. das 1,5-fache des Heaps zur Analyse benötigte. D.h. ein Heap von 2GB Größe benötigte 3 GB Heap zur Analyse.</p><p><img loading="lazy" title="Common Heap Objects" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/MMs7JK7TdqcujCN7CAYw" alt width="332" height="480" />Schaut man mit Eclipse MAT in einen Heap Dump hinein findet man viele Objekte. Üblicherweise solche:</p><ul><li>char[]</li><li>java.lang.Object[]</li><li>java.lang.Class</li><li>java.lang.String</li><li>byte[]</li><li>java.util.HashMap</li><li>java.util.HashMap$Entry</li><li>short[]</li><li>int[]</li><li>java.util.ArrayList</li><li>java.lang.Integer</li></ul><p>Diese Objekte werden immer in großer Anzahl zu finden sein. Jetzt ist nur die Frage: Sind diese Objekte das Problem oder wie finde ich den Verursacher?</p><p> </p><p> </p><p> </p><p><strong>Umfangreiche Leaks</strong></p><p>Analysiert man einen OutOfMemoryError Heapdump post mortem, so kann in der Regel davon ausgegangen werden, dass das Memory Leak den Großteil des Speichers belegt hat. Doch wie groß ist das Leak? Im Heapdump sind alle Objektinstanzen vorhanden, Eclipse MAT zeigt auf dem <strong>Class Histogramm</strong> aber lediglich die Klassennamen, die Anzahl der Instanzen, sowie die Shallow Size. Bei der Shallow Size handelt es sich um die Größe aller primitiven Datentypen in der Instanz sowie die Referenzen auf andere Objekte. Interessant ist eher der <strong>Retained Heap</strong>, also die Gesamtgröße aller Objekte die von diesen Dominatoren lebendig gehalten werden. Um den Retained Heap anzuzeigen, muss MAT diesen erst errechnen, indem es alle Objektreferenzen verfolgt. Für die Suche nach MemoryLeaks ist in der Regel eine Sortierung nach <strong>Retained Heap</strong> hilfreich, weswegen MAT die Klassen mit den größten Retained Heaps in einem Tortendiagramm darstellt.</p><p>Ein prominentes Beispiel für viel <strong>Retained Heap </strong>aus Webanwendungen ist üblicherweise der</p>

```
org.apache.catalina.session.StandardManager
```

<p>Der fachliche Zweck ist klar: Benutzerdaten für die Zeit einer Sitzung festhalten. Doch häufig finden sich hier auch Frameworkinformationen, wie man an unserem <a href="/wissens-hub/blog/richfaces-session-speicherverbrauch-analyse-eines-memory-leaks">Eintrag über Ajax4JSF</a>  sehen kann.</p><p>Aber auch eigene, und leider fast immer nicht korrekte, Cacheimplementierungen tauchen häufig im Tortendiagramm auf und liefern relativ schnell den Verursacher eines Memory Leaks.</p><p><img loading="lazy" title="Large Objects in Heap" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/PDx6Lg96SQGv9P6LolYX" alt width="578" height="378" /></p><p>Um zu bestimmen wer diese Objekte erzeugt, was diese Objeket fachlich machen und ob sie begründet noch lebendig sind, sind die konkreten Objektinstanzen und ihre eingehenden und ausgehenden Referenzen hilfreich.</p><p>Um an die Instanzen zu gelangen wählt man im Kontextmenü List <strong>Objects with incoming References</strong>. Dies zeigt alle Instanzen und eine Baumstruktur mit allen Referenzen auf dieses Objekt. Diese Referenzen sind also dafür verantwortlich, dass das Objekt nicht Garbage Collected wurde. <strong>Outgoing References</strong> sind etwas weniger interessant, kann aber helfen die Instanz zu identifizieren, indem man sehen kann was in diesem Objekt enthalten ist. Sie sind auch dann hilfreich, wenn der Dominator selbst, wie z.B. im Falle des SessionManagers, normal ist, jedoch unerwartet viele Objekte referenziert werden.</p><p> </p><p><img loading="lazy" title="instance-details" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/OfWUbQUfSrqQnyEixRhx" alt width="526" height="405" /></p><p><strong>Schleichende Memory Leaks<br /> </strong></p><p>Will man Leaks schon finden bevor ein OutOfMemoryError auftritt, so kann man mit der eingangs beschriebenen Methode Snapshots erstellen. Jedoch können Snapshots keine Aussage darüber treffen ob der aktuelle Zustand gut oder schlecht ist. Nur wenn Strukturen stetig wachsen, kann sich der Verdacht auf ein Leak erhärten.<br /> Eclipse MAT bietet die Möglichkeit Heapdumps zu vergleichen und kann so wachsende Strukturen erkennen. Doch dafür bedarf es zweier Heapdumps zu gut abgestimmten Zeitpunkten. Mit ausreichend Last sollten schon einige Minuten zwischen den Dumps liegen, bei wenig Last eher Stunden. Nur so lassen sich wirklich deutliche Unterschiede fernab von „natürlichen Schwankungen“ feststellen.</p><p>Im folgenden Beispiel erkennt man zum Beispiel eine deutliche Erhöhung von XML bezogenen Objekten:</p><p><img loading="lazy" title="Heap Delta" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/JTP3C6y8S9uaaG653N5b" alt width="491" height="480" /></p><p><strong>Bessere Methoden</strong></p><p>Doch Snapshots zu vergleichen ist umständlich und im Extremfall sogar irreführend, und OutOfMemoryError in Produktion sind sehr ärgerlich. Nicht zuletzt fehlt uns nach der Analyse immer noch die Information an welchen Codestellen die Objekte erzeugt und dann wahrscheinlich nicht mehr dereferenziert werden.<br /> Gibt es also keine besseren Methoden?<br /> Aber sicher! Profiler und einige APM Werkzeuge können während der Laufzeit des Programms Statistiken mitführen und Zugriffspfade aufzeichnen. Die von diesen Programmen gelieferten Informationen sind oftmals schneller zielführend als ein Heapdump und werden der Hauptakteur unseres nächsten Aktes sein.</p>

Java Heapdumps erzeugen und verstehen (4. Akt)

<p>Ich bin eher dafür Bibliotheken früher zu aktualisieren. Ich finde der Gesamtaufwand ist niedriger als bei großen Migrationsprojekten. Und man erhält bereits früher den Wert von neuer Funktion oder auch Performanceverbesserungen.<br /> Aber natürlich muss man diese erst messen! Und genau das habe ich kürzlich für einen Kunden getan. Dieser Kunde wollte Drools 5.0.1 nach <a href="http://www.jboss.org/drools/">Drools 5.2</a>  aktualisieren.<br /> Zu meiner Überraschung war das Laden und Ausführen der Regelbasis viel langsamer in 5.2. In der Anwendung dieses Kunden gibt es einen Cache, welcher pro Regeldatei eine StatelessSession enthält. Bei Systemstart werden alle Regeln eingelesen, damit der Endbenutzer auch schon beim ersten Aufruf einer Berechnung schnelle Ergebnisse erhält. Doch das Laden vieler Regeln war bereits Grund für Besorgnis. Also hoffte ich auf Verbesserungen in 5.2 und wurde enttäuscht. Die ersten Unit Tests zeigten schon erhebliche Verzögerungen und benötigten 3 mal so lange wie noch unter 5.0.1. Natürlich ist die Ausführungszeit von Unit Tests nur eine recht ungenaue Metrik, doch muss man bei diesem Faktor nicht über Genauigkeit reden.<br /> Also begab ich mich auf Spurensuche und verband <a href="http://www.ej-technologies.com/products/jprofiler/overview.html">JProfiler</a>  mit meinen Unit Tests und führte 21 <a href="http://docs.jboss.org/drools/release/5.2.0.Final/drools-expert-docs/html/ch06.html#d0e6651">Drools Decisiontables basierend auf XLS</a>  aus. Das Ergebnis war durchaus interessant: <span> [singlepic id=348 w=320 h=240 float=center]<br /> Es ist offensichtlich was unser Performance Problem verursacht. ClassLoading ist hier der Flaschenhals. Ein einziger Aufruf ist zwar noch schnell, doch die ungeheure Menge macht einen entscheidenden Faktor aus. Aber es gibt noch einen interessanten Punkt. Könnt ihr ihn finden?</span></p><p>Genau: System.gc() wird 42 mal aufgerufen (eine verdächtige Zahl). <a href="/leistungen">JProfiler </a> behauptet dort werden 8% der Gesamtzeit verbraucht. Aber wir wissen ja, dass Garbage Collection auch weitere unerwünschte Nebeneffekte haben kann. Warum haben wir überhaupt so viel Garbage Collection? Gelistet sind ja sogar nur die expliziten Aufrufe und nichtmal die Gesamtaktivität.<br /> Wie ich schon häufiger beobachten konnte wirkt sich der <a href="/wissens-hub/blog/system-gc-aufrufe-konnen-schwere-folgen-haben">manuelle Aufruf von System.gc()</a>  schlecht aus (jedenfalls meistens).</p><p>[singlepic id=350 w=320 h=240 float=center]</p><p>Warum wird es überhaupt aufgerufen? Welcher Code ist dafür verantwortlich? JProfiler kann uns dies sehr einfach beantworten:</p><p>[singlepic id=352 w=320 h=240 float=center]</p><p>Auch das habe ich bereits häufiger gesehen. Für mich ein klarer Fehler in der verbreiteten <a href="http://jexcelapi.sourceforge.net/">Java Excel API</a> . Hier wird <a href="http://download.oracle.com/javase/6/docs/api/java/lang/System.html#gc%28%29">System.gc()</a>  nach jedem Lesen von Daten aufgerufen. Ich denke wirklich nicht, dass dies überhaupt Sinn macht. Und hier hätte ich einen weiteren Beweis dafür. Glücklicherweise gibt es in jxl eine Konfigurationsmöglichkeit die in WorkbookSettings beschrieben ist:</p>

```
/**
 * Flag to indicate whether the system hint garbage collection
 * is enabled or not.
 * As a rule of thumb, it is desirable to enable garbage collection
 * when reading large spreadsheets from  a batch process or from the
 * command line, but better to deactivate the feature when reading
 * large spreadsheets within a WAS, as the calls to System.gc() not
 * only garbage collect the junk in JExcelApi, but also in the
 * webservers JVM and can cause significant slowdown
 * GC deactivated using -Djxl.nogc=true on the JVM command line
 * Activated by default or by using -Djxl.nogc=false on the JVM
 * command line
 */
```

<p>Ok, versuchen wir es mal mit diesen Sytem Property. Schauen wir mal ob es einen Einfluss hatte</p><p>[singlepic id=349 w=320 h=240 float=center]</p><p>und hier die gesamte GC Aktivität mit dem nogc Flag</p><p>[singlepic id=351 w=320 h=240 float=center]</p><p>Zwar behob dies nicht das offensichtliche Classloading Problem, jedoch war dies eine „lowhanging fruit“. Die gesamte GC Aktivität hat abgenommen und die gesamte Ausführungszeit hat sich von 338 Sekunden auf 315 Sekunden verkürzt (beide Male im voll instrumentierten Profilemodus). Das ist zwar nett aber nicht besonders beeindruckend. Die wahre Qualität dieser Änderung zeigt sich auf dem Integrationstestsystem. Hier hat sich das initiale Laden des Caches von etwa 740 Sekunden auf etwa 240 Sekunden doch erheblich verkürzt. In einem echtem System kommen auf größeren Heaps natürlich andere Charakteristiken zu tragen als bei kleinen Unit Tests.</p><p>Doch ich denke ich kann noch mehr herausholen, wenn ich verstehe wie das Classloading zu korrigieren ist. Dies werde ich in einem zweiten Post genauer anschauen.</p>

Java Performance: Drools 5.2 mit Decisiontables – Teil I

<p><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/EFsnGOSdTr2UI32aqQ9X" alt title="enterprise_java_performance" width="194" height="232" />Endlich ein neues Buch zur Performance von Enterprise Java Anwendungen! Es wurde meiner Meinung nach auch Zeit, denn die bisherigen Standardwerke wie „<a href="http://www.amazon.de/gp/product/0596003773/ref=as_li_ss_tl?ie=UTF8&tag=exfuror&linkCode=as2&camp=1638&creative=19454&creativeASIN=0596003773">Java Perfomance Tuning</a> “ von Jack Shirazi, und „<a href="http://www.amazon.de/gp/product/0201722291/ref=as_li_ss_tl?ie=UTF8&tag=exfuror&linkCode=as2&camp=1638&creative=19454&creativeASIN=0201722291">Performance Solutions</a> “ von Connie Smith sind doch mittlerweile arg betagt. Andere hervorragende Bücher wie „<a href="http://www.amazon.de/gp/product/0321349601/ref=as_li_ss_tl?ie=UTF8&tag=exfuror&linkCode=as2&camp=1638&creative=19454&creativeASIN=0321349601">Java Concurrency in Practice</a> “ von Brian Goetz et al sind zwar noch einigermassen aktuell, gehen doch aber sehr in die Tiefe. Wenn man sich mit Performanceproblemen beschäftigt ist ein gutes Breiten- und Methodikwissen aber unerlässlich. Dies reicht von grundlegendem Verständnis von Betriebsystemen und Hardware, über JVM Implementierungen und Frameworks bis hin zu verteilten Architekturen und modernen Web Anwendungen. Und genau dieses Verständnis schafft „<a href="http://www.amazon.de/gp/product/3868020403/ref=as_li_ss_tl?ie=UTF8&tag=exfuror&linkCode=as2&camp=1638&creative=19454&creativeASIN=3868020403">Java Enterprise Performance</a> “ von Alois Reitbauer, Michael Kopp und Andreas Grabner.<br /> <span><br /> Alle Kapitel des Buches folgen einer einheitlichen Struktur: Beschreibung der Grundlagen, Diagnosemöglichkeiten und häufige Probleme.<br /> Beschrieben werden zum Beispiel die aktuelle Java Speicherverwaltung und Garbage Collection, wie wir es auch in unserer <a href="/wissens-hub/blog/java-outofmemoryerror-eine-tragodie-in-sieben-akten">OutOfMemoryError Tragödie</a>  tun. Die Herausforderungen von Datenbankzugriffen über O/R Mapper werden ebenso detailliert beschrieben wie zum Beispiel Serialisierung oder Remotingprotokolle.<br /> Der lockere Schreibstil des Autorenteams, sowie die passenden Bilder und Grafiken vermitteln sehr einfach die Grundlagen für Performance Troubleshooter. Zahlreiche Fußnoten geben wertvolle Links zu Hintergrundinformationen, sowie freien Werkzeugen zur Analyse.<br /> Nach größtenteils technisch motivierten Themen kommt die Behandlung von Performanceoptimierung als Prozess zu ihrem Recht. Hier werden Testszenarien ebenso beschrieben wie Behandlung von Performance in agiler Softwareentwickklung.</span></p><p>Zu bemängeln gibt es an dem 260 Seiten starken Werk wenig: Da Detailtiefe immer ein nicht triviales Problem ist kann man sich streiten ob vielleicht manche Themen etwas zu knapp behandelt sind. Unstrittig ist aber: farbige Grafiken wirken im Schwarz-Weiss Druck nicht besonders überzeugend; insbesondere wenn auf den grünen und roten Graphen verwiesen wird 🙂 Auch ist der Satz der Grafiken manchmal etwas unglücklich, kommen sie doch ohne Nummerierung daher und stehen teils vor, teils nach dem beschreibenden Text. <img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/c4ClkJjVQS2UNsAK9MWe" alt title="daumen hoch!" width="86" height="98" /></p><p>Für 35 Euro ist das Buch eine solide, praxisnahe Einführung in viele aktuelle Performancethemen. Daumen hoch!</p><p>Ein Wort in eigener Sache: am 14. Oktober ist mein Workshop zum Thema Enterprise Performance Troubleshooting geplant. Informationen bei mir oder auf unserer Schulungseite.</p>

Buchrezension: Java Enterprise Performance

<p><img title="performance-day" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/aAe4kFPgSquEjMOdN7LA" alt width="293" height="292" /> codecentric hatte die Ehre dieses Jahr am 3. Mai den Performance Day auf der JAX auszurichten. In den vergangenen Jahren war codecentric bereits mit anderen Aktionen zum Thema Performance unterwegs. So haben wir beispielsweise unter den JAX Teilnehmern eine großangelgte Performance Studie erstellt.<br /> Der Performanceday setzt weitere Akzente auf das immer wichtiger werdende Thema Performance. Neben der Kundenzufriedenheit sind auch finanzielle und ökologische Aspekte von Performance aktuelle Themen. Den zahlreich erschienen Besuchern wurde ein sehr abwechslungsreiches Programm geboten, welches neben Performance-Klassikern auch diese Gesichtspunkte beinhaltet.<br /> Kurze Details zu den Sessions:<br /> <span><br /> <strong>DevOps High Noon</strong><br /> <img loading="lazy" title="devops" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/9HcAzrywRgWOMek1tvVP" alt width="324" height="255" />Eröffnet wurde der Performance Day mit einem Duell. Agile Softwareentwicklung treibt den Konflikt zwischen der auf Veränderung bedachten Entwicklung und dem auf Stabilität bedachten Betrieb voran. Der agile Eisenbahner Agile „Dev“ Dave und der Sheriff Systemius „Ops“ Admin streiten über neue Weichen und Saloontimeouts. Nach ihrem Rollenwechsel erklären Patrick Peschlow und Rainer Schuppe was zu tun ist um gemeinsam an einem Strang zu ziehen und eine gute, stabile, schnelle und Moderne Softwarelösung von der Entwicklung in einen reibungslosen Betrieb zu bringen.</span></p><p><strong>Groovy Performance</strong><br /> Den dynamischen Scriptsprachen gehört mit Sicherheit ein Teil der Zukunft. Und Java ist weiter mit dabei, da viele die JVM als Laufzeitumgebung nutzen. Doch was sind die Fallstricke? Jochen Theodorou erläuterte in seinem Vortrag was zu berücksichtigen ist wenn man Performancekritischen Groovy Code schreibt. Mit etwas Rücksicht auf Spezifika von Groovy lassen sich manche Teile auf fast ähnliche Performance beschleunigen wie echter Java Code. Aber er zeigte auch, dass nicht optimaler Code doch durchaus sehr langsam sein kann. Als Fazit bleibt für mich, dass es keinen Grund gibt Groovy per se als langsam auszuschließen.</p><p><strong>Performance Forensics</strong><br /> Alois Reitbauer versetzt uns in die Rolle eines Ermittlers. Was ist geschehen? Warum ist die Anwendung langsam? Wo sind unsere Beweismittel, und wie kann man sie interpretieren?<br /> Zum Performancetroubleshooting gehört die Spürnase eines Kriminologen. In seinem Vortrag stellt Alois die wichtigsten Grundlagen einer erfolgreichen Analyse vor und zeigt wie leicht unvollständige Daten einen komplett falschen Schluss ziehen lassen.</p><p><strong>Performance Tuning JPA with Eclipse Link</strong><br /> Shaun Smith und Tom Ware präsentierten Themen wie das N+1 Query Problem und Caching aus der Sicht von EclipseLink. Diese grundsätzlichen Probleme von ORM Frameworks sind zwar je nach Framework unterschiedlich adressiert, doch sind inherente Probleme, welche sich nur selten wegoptimieren lassen und immer einen intelligenten Einsatz von ORM Frameworks erfordern. Gerade die „Vorteile“ von OR wie Datenreduktion durch Einführung von Relationen, können schnell zu erheblichen Problemen werden.</p><p><strong>Web Performance Optimization</strong><br /> Mein Vortrag zur Web Performance beschloss das Tagesprogramm des Performance Tages. Ich begann mit den Potentialen hinter Web Performance Optimierung und endete mit einer ganzen Reihe von einfach umzusetzenden Tipps und weiterführenden Themen. Ich hoffe es war für jeden der zahlreichen Zuhörer etwas informatives und im Alltag nützliches dabei.</p><div><strong><a href="http://www.slideshare.net/fabianlange/web-performance-optimization-jax-2011-talk">Web Performance Optimization – JAX 2011 Talk</a> </strong><div>View more <a href="http://www.slideshare.net/">presentations</a>  from <a href="http://www.slideshare.net/fabianlange">Fabian Lange</a> .</div></div><p>Ich hoffe der Performance Day und das Programm war für Euch genau das richtige. Falls Ihr Wünsche und Anregungen oder Fragen zu den Vorträgen habt, nutzt doch die Kommentarfunktion hier im Blog.</p>

JAX 2011 – Performance Day

<p>Gestern Abend hat <a href="http://www.axelfontaine.com/">Axel Fontaine</a>  auf der <a href="http://rheinjug.de/">RheinJUG</a>  seinen Vortrag über Continuous Delivery gehalten. Es war ein guter, kurzweiliger Vortrag dessen Kernaussagen sich relativ kurz zusammenfassen lassen.</p><blockquote><p>Continuous Delivery ist:</p><ol><li>Buildautomatisierung</li><li>Testautomatisierung</li><li>Deploymentautomatisierung</li></ol></blockquote><p>Er stellt fest, dass Build- und Testautomatisierung schon relativ weit sind, es aber bei Deployments noch viele manuelle Schritte gibt. Das stimmt mit Sicherheit. Allerdings können bestimmte Tests (z.B. Akzeptanztests) garnicht ohne Deploymentautomatisierung funktionieren. Dies zeigt wie integriert doch die Bereiche Entwicklung, Test und Betrieb in Wirklichkeit sind.<br /> Für mich besonders interessant: Obwohl er „<a href="http://en.wikipedia.org/wiki/Devops">DevOps</a> “ beschreibt, hat er es nie mit diesem Namen genannt.<br /> Als gute Referenz, für alle die den Vortrag nicht gesehen haben, oder gerne mehr Wissen wollen kann auch ich das Buch von Jez Humble empfehlen: <a href="http://www.amazon.de/gp/product/0321601912/ref=as_li_ss_tl?ie=UTF8&tag=exfuror&linkCode=as2&camp=1638&creative=19454&creativeASIN=0321601912">Continuous Delivery – Reliable Software Releases Through Build, Test, and Deployment Automation</a> <br /> Danke auch an die Organisation der RheinJUG, welche immer wieder interessante Vorträge auftreibt. Ich freue mich schon auf Erich Gamma!</p><p>Und noch etwas Werbung in eigener Sache am Rande 🙂<br /> Einen Vortrag mit ähnlichem Inhalt, jedoch vom Standpunkt der Performance aus tragen meine Kollegen Rainer und Patrick auf der JAX vor: <a href="http://jax.de/2011/sessions/?tid=1949#session-17874">DevOps High Noon</a> . Am gleichen Tag halte ich abends einen Vortrag über <a href="/wissens-hub/blog/web-performance-optimierung-ist-das-neue-seo">Web Performance Optimization</a> . Ich würde mich freuen viele Blogleser dort zu treffen.</p>

Continuous Delivery auf der RheinJUG

<p>Im vorhergehenden Akt haben wir gelernt <a href="/wissens-hub/blog/java-memory-leaks-und-andere-ubeltater-2-akt">wie Java und Java Memory Leaks Speicher verbrauchen</a> . Aus dem ersten Akt wissen wir, dass der Java Heap <a href="/wissens-hub/blog/java-outofmemoryerror-1-akt-das-java-memory-modell-stellt-sich-vor">in verschiedene Bereiche aufgeteilt ist</a> . Mit diesem Vorwissen wollen wir uns in diesem Akt ansehen, wie wir den JVM Speicher konfigurieren und die Nutzung zur Laufzeit überwachen können. Zwar gibt es, wie bekannt, verschiedene Bereiche, jedoch der interessanteste und relevanteste ist der Heap. In diesem Beitrag beschreibe ich die Eckpfeiler des Heaps, sowie die Möglichkeiten und Tools den Heap zu überwachen. Es gibt dazu einige JVM Befehle und insbesondere das Werkzeug VisualVM.</p><h2>Heapgröße: Minimum und Maximum</h2><p>Die Java Speicherverwaltung ist sehr clever. Sie versucht so wenig Speicher wie möglich zu verbrauchen und gleichzeitig zu gewährleisten, dass ausreichend Speicher zur Verfügung steht.<br /> <span>Zur Verdeutlichung dieses Verhaltens habe ich ein Beispielprogramm erstellt, welches nach und nach mehr Speicher verbraucht:</span></p><div>

```java5
ArrayList list = new ArrayList();
Thread.sleep(5000); // 5s to allow starting visualvm
for (long l = 0; l < Long.MAX_VALUE; l++) {
	list.add(new Long(l));
	for (int i = 0; i < 5000; i++) {
		// busy wait, 'cause 1ms sleep is too long
		if (i == 5000) break;
	}
}
```

</div><p>Natürlich führt es nach einiger Zeit unweigerlich zu: <code>Exception in thread "main" java.lang.OutOfMemoryError: Java heap space</code></p><p>Die beiden unten abgebildeten Graphen zeigen den Speicherverbrauch des Programms, gemessen mit VisualVM. Der gelbe Bereich zeigt den für Java zur Verfügung stehenden Speicher, während der blaue Bereich den aktuell genutzten Speicher darstellt. Der blaue Graph geht ab und zu zurück, da temporäre Objekte, welche bei der Vergrößerung der ArrayList erzeugt werden, durch den Garbage Collector wieder freigegeben werden können. Das linke Diagramm stellt das Standardverhalten der JVM dar. Nach Programmstart wird relativ wenig Speicher genutzt, doch nach und nach reserviert die JVM immer mehr Speicher. Es endet mit dem Maximalwert 128 Megabyte. Im Diagramm auf der rechten Seite hingegen sind die 128MB von Anfang an reserviert. Dies wird durch eine JVM Option bewirkt, welche wir gleich kennenlernen werden.</p><div><img title="Adaptive Heap Size" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/JdibrHKUTuKngi63ra8j" alt width="225" height="236" /><p>Adaptive Heap Size</p></div><p></p><div><img loading="lazy" title="Fixed Heap Size" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/IBxzU3tJSDSjrI8eQXb3" alt width="226" height="230" /><p>Fixed Heap Size</p></div><br /> <br /><br /> Ein interessanter Fakt ist die Tatsache, dass wir einen OutOfMemoryError erhalten, noch bevor der Speicher vollkommen erschöpft ist. Bis zur Auflösung dieses Mysteriums am Ende dieses Artikels kann der geneigte Leser selbst darüber nachdenken.<br /> Nun zurück zu den JVM Optionen. Es gibt hauptsächlich 2 Optionen, welche die Größe des JVM Heaps beeinflussen:<br /><p></p><ul><li><code>-Xmx128m</code> setzt den Maximalwert auf 128 Megabyte</li><li><code>-Xms128m</code> setzt den Startwert(Minimalwert) auf 128 Megabyte</li></ul><p>Für die Erhöhung des Maximalwertes gibt es offensichtlich gute Gründe, doch warum sollte man den Startwert verändern wollen? Dafür gibt es im Wesentlichen zwei Argumente:</p><ol><li>Die meisten Java Anwendungen sind Serveranwendungen, welche auf exklusiv für sie bereitgestellter Hardware laufen und den gesamten Speicher belegen dürfen. Die Anpassung reduziert somit den geringen Overhead für die dynamische Veränderung der Speichernutzung.</li><li>Viel wichtiger ist aber, dass durch das Abschalten der automatischen Heapvergrößerung die Beeinflussung und das Verständnis der internen Aufteilung des Heaps, welche ich als nächstes beschreiben werde, erleichtert wird. Auch Tuningmaßnahmen sind so besser abzuschätzen und durchzuführen.</li></ol><h2>Bereiche des Heaps: Tenured, Young und Permanent</h2><p>Der Heap selbst ist in 3 Bereiche unterteilt: <strong>Tenured </strong>(auch Old genannt), <strong>Young </strong>(auch New genannt), und <strong>Permanent </strong>(Perm).<br /> Wie im ersten Akt schon angedeutet, ist die Idee hinter der Aufteilung die Garbage Collection effizient gestalten zu können. So sollte der Permanent Bereich gar keine Garbage Collection benötigen (es kann aber eine konfiguriert werden), Old sollte nur selten garbage-collected werden, und im Young Bereich wird sehr viel Garbage Collection-Aktivität stattfinden.<br /> <img loading="lazy" title="Survivor Age Histogram" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Z0HfpYgDT1uEPnC4aBja" alt width="299" height="197" />Aus diesem Grund sind die Garbage Collection Algorithmen so entworfen, dass Young Colections möglichst schnell durchgeführt werden können. Rechts ist ein Diagramm aus der <a href="http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html#1.1.%20Generations|outline">Oracle Dokumentation</a>  abgebildet, welcher die typische Altersverteilung von Objekten zeigt. Viele Objekte leben nur sehr kurz und einige für eine gewisse Zeit und überleben 2-3 Young Generation Collections (auch Minor Collections genannt). Aus diesem Grund kopiert die Young-Collection die überlebenden Objekte in sogenannte Survivor Spaces. Dort bleiben sie biss sie „alt genug“ sind und in den Old Bereich verschoben werden. Der genauen Funktionsweise ist geschuldet, dass zwei <strong>Survivor</strong> Spaces existieren, von denen einer immer leer ist. Der verbleibende Bereich der Young Generation wird <strong>Eden</strong> genannt.</p><h2>Statistiken über den Heap erhalten</h2><p>Wie ist nun der gesamte Speicher genau auf die Bereiche verteilt? Die JVM stellt uns verschiedene Informationen über Speichernutzung über die JMX Schnittstelle zur Verfügung. Darauf setzen verschiedene Kommandozeilenwerkzeuge auf. Hier ein Befehl der uns die aktuelle Auslastung der Speicherbereiche zeigt:</p><div>

```bash
jstat
```

</div><p>Am Beispiel meines aktuell laufenden Eclipse sieht dies wie folgt aus:</p><div>

```bash
C:\Users\fla>jstat -gcutil 4188
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT
  0,00   0,00   1,61  50,89  99,90     35    0,304   109   28,229   28,532
```

</div><p>Ok, es sieht so aus als würde die JVM nicht viel unternehmen. Eden ist fast leer, Old etwa zur Hälfte gefüllt. Perm ist fast randvoll. Die GC/GCT Messwerte sind in diesem Zusammenhang uninteressant.<br /> Doch wie groß sind die Bereiche nun? <code>jstat -gc</code> verrät uns dies:</p><div>

```bash
C:\Users\fla>jstat -gc 4188
S0C    S1C    S0U    S1U      EC       EU        OC         OU       PC     PU    YGC     YGCT    FGC    FGCT     GCT
1984,0 1984,0  0,0    0,0   16256,0   263,6    40388,0    20553,3   55808,0 55752,7     35    0,304  133    34,558   34,861
```

</div><p>Viele Zahle, alle in Kilobyte. Die Survivor Spaces sind jeweils 2MB, Eden ist bei 16MB, Old auf 40MB, Perm hat 55MB. In Summe kommt dies relativ nahe an die von Windows gemeldete Speichernutzung von 135MB. Die Differenz sind Speicherbereiche außerhalb des Heaps.</p><p>Eine ausführliche Information über alle Optionen und Ausgabespalten findet sich in der <a href="http://download.oracle.com/javase/1.5.0/docs/tooldocs/share/jstat.html#gc_option">offiziellen jstat Dokumentation</a> .</p><h2>Den Heap konfigurieren</h2><p>Was können wir einstellen, nun da wir wissen wie groß der Heap ist? Es existieren zwar relative viele Konfigurationsoptionen, doch werden diese eigentlich nur zur Optimierung der Garbage Collection eingesetzt. Denn alle Heap Bereiche sind gleich gut Objekte zu speichern, lediglich die Garbage Collection macht Unterschiede.</p><p>Ohne Konfiguration verwendet eine client-JVM folgende Berechnung für die Bereiche</p>

```
Heap = Tenured + Young
Tenured = 2 x Young
Young = Survivor x 2 + Eden
```

<p>Eine häufig durchgeführte Änderung ist die Permanent Generation mit <code>-XX:MaxPermSize=128m</code> zu vergrößern. Die initiale Größe kann dabei mit <code>-XX:PermSize=64m</code> gesetzt werden.<br /> Je nach Anwendung kann auch die Größe von New sinnvoll angepasst werden. Dies geht entweder als Verhältnis <code>-XX:NewRatio=2</code> (empfohlen, da das Verhältnis bei Größenänderung mitwächst), oder als feste Größe <code>-XX:NewSize=128m</code> oder <code>-Xmn128m</code> (einfacher zu verstehen, dafür unflexibel).<br /> Alle Verhältnisse werden als „eins von mir – N von dem anderen“ angegeben, wobei N der für die Option genutzte Wert ist. Als Beispiel: <code>-XX:NewRatio=2</code> bedeutet 33% des Heaps sind für New reserviert. 66% bleiben für Old.</p><p>Die Größe des Young Bereiches kann über <code>-XX:SurvivorRatio</code> verändert werden. Dies passt die Größe der Survivor Spaces an, ist aber in der Regel nicht besonders effektiv.<br /> Die Konfiguration einer typischen Webanwendung könnte wie folgt aussehen:</p><div>

```bash
-Xms2g -Xmx2g -XX:NewRatio=4 -XX:MaxPermSize=512m -XX:SurvivorRatio=6
```

</div><p>Insgesamt wird Java etwas mehr als 2,5GB benötigen. Der Old Bereich dürfte 1,6GB groß werden, Eden 300MB und die Survivor Spaces sind etwa 50MB groß.</p><h2>Den Heap überwachen</h2><p>Da die von der JVM gelieferten Informationen sehr umfangreich sind, ist die Kommandozeile ein eher ungeeigneter Weg die Werte auszulesen. Im folgenden Screencast demonstriere ich 3 weitere Werkzeuge:</p><ul><li><a href="http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html">JConsole</a> , JVM Bordmittel um JMX Metriken auszuwerten</li><li><a href="http://java.sun.com/performance/jvmstat/visualgc.html">Visual GC</a> , ein super GC Visualisierungswerkzeug, auch erhältlich als Pugin für VisualVM – bestens geeignet für Troubleshootings</li><li><a href="http://appdynamics.com/free">AppDynamics</a> , hervorragendes Langzeitmonitoring Werkzeug</li></ul><p></p><div> Unable to display content. Adobe Flash is required.</div><h2>Warum tritt der OutOfMemoryError trotz freiem Speicher auf?</h2><p>Mittlerweile sollte sich die Antwort auf diese Frage finden lassen. Schauen wir uns die letzte Ausgabe von Visual GC mal genauer an:<br /> <img loading="lazy" title="Visual GC" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/wDc7SAs4QoqfZt6558og" alt width="579" height="298" /><br /> Die Old Generation ist voll. Die Survivor Spaces sind leer, und Eden ist nur zu einem Drittel gefüllt. Also erhalten wir einen OutOfMemoryError, obwohl wir noch fast 30MB Speicher von unserem Xmx Limit von 128MB frei haben.<br /> Auch wenn wir nicht genau wissen was der Code gerade so treibt, es werden auf jeden Fall immer größer werdende Arrays erstellt welche die in der Schleife erzeugten Long Objekte aufnehmen.<br /> An dieser Stelle passiert genau das: <code>at java.util.Arrays.copyOf(Arrays.java:2760)</code>. Nun nehmen wir mal an, dass in Eden kein Platz mehr für das neue Array ist (in diesem Fall können wir sogar annehmen, dass das Array größer als 22 MB ist). Also würde Garbage Collection stattfinden um dafür Platz zu schaffen. Da aber in Old kein Platz mehr ist, können die Objekte aus Eden dort nicht hinverschoben werden. Darum wird der OutOfMemoryError geworfen.<br /> Daraus kann man ableiten, dass ein OutOfMemoryError nicht bedeutet, dass der gesamte Speicher voll ist. Jedoch ist wahrscheinlich einer der Teilbereiche derart gefüllt, dass Objekte nicht mehr verschoben werden können.</p><p>In unserem nächsten Akt wenden wir uns den Heap Dumps zu, mit denen wir uns ansehen können, welche Objekte denn in unserem Heap so rumlungern.</p>

Java Speicher – Konfiguration und Überwachung (3. Akt)

<p>Martin Fowlers Vortrag auf der Java Users Group in Köln hat mich dazu motiviert etwas aus einem meiner Projekte bei codecentric zu erzählen. Denn Martin sprach davon, dass der wahre Charme von DSLs die <em>Lesbarkeit</em> sei. Programmiert man in der „Sprache des Fachbereichs“ kann dieser ganz leicht prüfen ob die Logik richtig sein könnte. Diese Argumentation ist häufig viel treffender und hilfreicher als das sonst oft vorgebrachte Argument, dass doch der Fachbereich auch Code <em>schreiben</em> könne.<br /> Nun nahm sich Martin das Recht heraus, darüber zu schimpfen, dass Java keine lesbare Sprache sei. Mann müsse detektivisch Java code mühsam entziffern. Als Konsequenz daraus entwickelte er seine eigene Sprache und einen dazu passenden Parser. Diesbezüglich bemerkte er:</p><blockquote><p>Einige Leute denken, dass Parser programmieren schwierig sei, weil sie an der Universität keinen Compilerbau-Kurs belegt haben. Und diejenigen die an diesen Kursen teilnahmen wissen, dass Parser schreiben schwierig ist.</p></blockquote><p><span><br /> Also verwarf er seine selbstgeschriebene DSL, da sie erstaunliche Ähnlichkeit mit gültigem Ruby Code hat.<br /> Aber der springende Punkt ist, dass die eigentliche Formatierung nicht so wichtig ist, solange man klare Konzepte verwendet. Dann nämlich kann man seine DSL in einer Sprache wie Ruby schreiben, oder so wie wir, in <a href="http://www.jboss.org/drools">Drools</a> .<br /> Drools ist eine Regelmaschine und damit schon sehr gut auf die Auswertung von Zuständen vorbereitet.<br /> In unserem Projekt benötigten wir im wesentlichen 3 DSLs:</span></p><ol><li>Eine Empfehlungsermittlung, welche aus Profildaten Produkte empfiehlt.</li><li>Einen Validator, der Profile auf Konsitenz prüfen kann.</li><li>Einen Preisberechner, der Profildaten zur Preisermittlung verwendet.</li></ol><p>Diese 3 waren sich so ähnlich, dass wir vermuteten, dass wir eine Technologie für alle Fälle verwenden können. Und das obwohl die Unterschiede durchaus relevant sind: Die Empfehlung wertet Profildaten aus und versieht Produkte mit Empfehlungen, während die Validierung Fehler erzeugt. Die Berechnung verwendet Tabellen und Formeln und liefert Preise.</p><p>Ohne groß über Alternativen nachzudenken wussten wir, dass Drools die perfekte Technologie für uns war. Also mussten wir nur noch einen Weg finden unser Fachmodell in Drools zu integrieren.</p><p>Die 3 Anwendungsfälle lesen alle aus einem <em>Profil</em>. Dafür hatten wir bereits ein Domänenobjekt, allerdings wollten wir nicht auf die Werte über einfache Getter zugreifen. So wollten wir es möglich machen auf ein <em>Alter</em> zuzugreifen, obwohl wir im Profil nur ein <em>Geburtsdatum</em> mitführen. Deshalb erfanden wir für diese Zwecke einen Wrapper um unser Profil. Der Wrapper selbst erhält allerlei nützliche Methoden um aus der DSL in der Sprache des Fachbereiches Werte auszulesen.<br /> Die Ausgaben erfolgen in Drools über globale Objekte auf die Werte gesetzt werden können. Also müssen wir nur dafür sorgen, dass diese Objekte ansprechend benannt sind.<br /> Mit diesem Konzept und ein wenig Feintuning an der Benennung, entstand eine lesbare DSL. Unser Kunde kann die Empfehlungen und Validierungen lesen und prüfen und sogar die Preisberechnung mit aktuellen Werten befüllen.<br /> Urteilt selbst und teilt mir mit was ihr denkt. Ist doch eine recht überschaubare und einfache DSL?</p><p>Hier unsere <strong>Validierungs DSL</strong> mit Drools:</p><div>

```java5
global ValidierungsFehler fehler;
 
rule "Alter muss kleiner als 101 sein"
	when
	  Profil( alter > 100 )
	then
	  fehler.add("Wenn Sie älter als 100 Jahre sind, wenden Sie sich bitte an ihren persönlichen Berater.", Feld.Geburtsdatum);
end
 
rule "Das Geburtsdatum darf nicht in der Zukunft liegen"
	when
	  Profil( geburtsdatum > heute )
	then
	  fehler.add("Unsere Dienstleistung ist nur für bereits geborene Personen möglich.", Feld.Geburtsdatum);
end
```

</div><p>Und so sieht unsere <strong>Empfehlungs DSL</strong> aus:</p><div>

```java5
global Produktportfolio produkte;
 
rule "Kinder"
when
	Profil( alter <= 15 )
then
	produkte.empfehle( "PRODUKT_A", 5 );
	produkte.empfehle( "PRODUKT_B", 0 );
	produkte.empfehle( "ANDERES_PRODUKT", 3 );
end
```

</div><p>Und ein Screenshot unserer <strong>Preisberechnung</strong>. Es ist möglich die Implementierungsdetails auszublenden.:</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/oNfzxwgS3yBl5mQgCYXP"><img title="drools-pricing" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/oNfzxwgS3yBl5mQgCYXP" alt width="540" height="222" /></a> </p><p>Der Fachbereich ist sehr zufrieden mit dem Ergebnis. Sie können alles „programmierte“ prüfen und sogar die Tabellen an neue Preise anpassen.</p>

Pragmatische DSL in der Praxis, mit Java und Drools

<p>AppDynamics ist seit nicht mal einem Jahr mit ihrer Java Application Performance Management Lösung auf dem Markt und beeindruckt durch einfache Installation, einem selbst lernenden System und einem intuitiven Flex User Interface. Als bisher einziger Hersteller in diesem Bereich bietet AppDynamics eine kostenfreie Version mit reduziertem Funktionsumfang an.<br /> <a href="http://www.appdynamics.com/free">AppDynamics Lite</a>  ist nun in überarbeiteter Version erschienen. Die neue Version bringt folgende Neuerungen:<br /> <span></span></p><ol><li><strong>Verbesserte Performance</strong><br /> Ein Werkzeug, welches verspricht Performanceprobleme zu finden sollte natürlich schnell sein. Das Flash User Interface der Lite Version ist jetzt noch schneller und nutzt weiterhin die in Produktionssystemen bewährte Agententechnologie.</li><li><strong>Mehr Technologien out-of-the-Box unterstützt</strong><br /> Auch wenn es so scheint, erkennt AppDynamics Java-Anwendungen nicht durch Magie. AppDynamics muss die Technologien kennen, und die neue Version hat ihr Wissen um Frameworks stark erweitert. Selbst exotischere Komponenten, wie der Suchserver Solr oder Tibco RV, erscheinen nun von ganz alleine. Die Konfiguration mittels XML bleibt weiterhin der Pro Version vorbehalten.</li><li><strong>Vereinfachtes Handling</strong><br /> Problematisch war bisher das getrennte Durchstarten von Agent und Viewer. Dies wurde nun verbessert: Der Agent verbindet sich selbständig erneut wenn der Viewer neu gestartet wird, und man kann auch den Viewer starten ohne dass Agenten verbunden sind.</li></ol><p>Über die Benutzung von AppDynamics Lite hatte ich bereits einen Screencast aufgenommen, auf den ich an dieser Stelle verweisen möchte.<br /> </p><p>Ein weiteres <a href="/wissens-hub/blog/einfache-performanceanalyse-mit-appdynamics-lite">Video zur Installation</a>  von AppDynamics Lite hatte ich bereits vor einiger Zeit hier im Blog veröffentlicht.</p>

AppDynamics Lite – neue Version bleibt kostenfrei

<p>Bei der Durchführung von Lasttests auf einem Projekt bemerkte ich einen spontanen Abfall der Antwortzeiten. Je mehr Benutzer auf die Anwendung zugriffen, desto langsamer wurde sie. Die Anwendung wurde mit dem Struts 2 Java Framework erstellt und griff auf die Datenbank über Hibernate zu. Eigentlich eine ganz simple Anwendung, umso verwunderlicher waren für mich die schlechten Ergebnisse. Nach dem Studium der von <a href="http://www.appdynamics.com/free">AppDynamics</a>  aufgezeichneten Messwerte wurde mir aber schnell klar, dass es sich um ein Problem mit Freemarker, der in Struts2 nutzbaren Template Engine, handeln musste:</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/A4ka7v5KQI68JCRkZt7P"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/A4ka7v5KQI68JCRkZt7P" alt width="553" height="320" /></a> <span>Alle HotSpots gingen auf <strong>freemarker.cache.URLTemplateLoader.getURL()</strong> zurück, welches die abstrakte Definition einer in im Struts <strong>org.apache.struts2.views.freemarker.StrutsClassTemplateLoader</strong> implementierten Methode ist.</span></p><p>Also, was verursacht diese langen Wartezeiten? AppDynamics hat dankenswerterweise automatisch einige Threaddumps für uns gezogen, welche alle auf die blockierten Threads in <strong>sun.misc.URLClassPath.getLoader()</strong> hinweisen.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/dkv4cYfNRUa1Ergp77VK"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/dkv4cYfNRUa1Ergp77VK" alt width="540" height="382" /></a> <br /> Schaut man sich den Source Code davon an, erkennt man dass dieser Code auf die URLClassPath Instanz synchonisiert ist.</p>

```
private synchronized Loader getLoader(int index) {
```

<p>Eigentlich hatte ich nicht erwartet, dass dies ein Engpass sein könnte, doch ich fand einige Threads, welche ebenfalls dieses Lock nutzten, aber es für Classloading verwendeten. Dieses war leider durch Speicherallokation im Betriebssystem erheblich gebremst.</p><p>Die Art wie Freemarker/Struts2 Templates laden ist also bei genauer Betrachtung gar nicht falsch. Dennoch wird offensichtlich unnötig oft auf diese Ressourcen zugegriffen.</p><p>Normalerweise verändern sich Templates nicht sehr häufig, weswegen sich Caching besonders anbieten würde. Und in der Tat gibt es die Möglichkeit in Freemarker Templates für eine Zeit zu cachen:</p>

```
template_update_delay=60000
```

<p>Diese Einstellung kann man in Struts über eine Datei namens <strong>freemarker.properties</strong> vornehmen. Laut der Dokumentation von Struts wird der eingestellte Wert als die Anzahl von Sekunden verwendet, welche ein Template im Cache sein muss bevor es auf Aktualität überprüft wird. Also sollte dieser Wert hoch gewählt werden.</p><p>Die Dokumentation empfiehlt ferner eine Einstellung namens <strong>struts.freemarker.templatesCache</strong>, welche auf <strong>true</strong> gesetzt werden soll. Angeblich sei es notwendig die Templates aus dem Classpath in das Filesystem zu kopieren, da Freemarker andernfalls nicht korrekt das Änderungsdatum bestimmen könne. Auf den von mir getesteten aktuellen JVMs funktionierte dies jedoch tadellos.</p><p><strong>template_update_delay</strong> hat für das von mir getestete Projekt wunderbar funktioniert, dennoch frage ich mich warum überhaupt Templates erneut gelesen werden sollten. Auf echten Produktionssystemen würde ein einmaliges Laden völlig ausreichen. Zumal die Prüfung in <strong>freemarker.cache.TemplateCache</strong> mit nicht unerheblich viel Code verbunden ist.</p><p>Ich denke, es lohnt sich über eine eigene Implementierung der Klasse <strong>org.apache.struts2.views.freemarker.FreemarkerManager</strong> nachzudenken. Sie verbindet Struts2 mit Freemarker und versucht in der Standardimplementierung das Template zweimal aus dem Dateisystem zu lesen bevor der Classpath verwendet wird. Dieses Verhalten bietet zwar einige Flexibilität zur Entwicklungszeit, verursacht aber in Produktion unnötige Wartezeiten.</p><p>Nach der Veränderung der „Cache“-Einstellung verschwanden die HotSpots und die Anwendung lief deutlich schneller. Insbesondere der Classloader war kein Engpass mehr.</p>

Freemarker Template Caching – Analyse eines Struts2 Performance Problems

<p>Während Fernsehsender ihren Jahresrückblick bereits im alten Jahr aufzeichnen und ausstrahlen, folgen wir der agilen Tradition und schauen erst nach Abschluss des Jahres auf das Jahr 2010 zurück.</p><p><strong>Veränderungen in 2010</strong><br /> Wir haben unseren Wachstumskurs auch 2010 konsequent weiter verfolgt und beschäftigen jetzt über 100 Mitarbeiter. Doch nicht nur personell, sondern auch geographisch sind wir gewachsen und haben 3 neue Standorte hinzugefügt.</p><p><span>Im serbischen <a href="http://de.wikipedia.org/wiki/Novi_Sad" target="_blank">Novi Sad</a>  haben wir einen weiteren, agilen Nearshoring Standort aufgebaut. Schwerpunkt unseres neuen „Mobile Competence Centers“ ist die Entwicklung von mobilen „Apps“ für iOS und Android Smartphones und Tablets. Es gibt auch schon erste Success Stories, wie die Schaden App der VGH, welche es kurz vor Jahreswechsel in den AppStore geschafft hat: <a href="http://itunes.apple.com/de/app/vgh-automobil/id404553250?mt=8">VGH autoMobil</a> .</span></p><p>Mitte des Jahres haben wir zudem in <a href="http://de.wikipedia.org/wiki/Dordrecht" target="_blank">Dordrecht</a>  einen neuen Standort eröffnet, um den Benelux-Markt mit unserer Agilen Software Factory und Dienstleistungen von Performance Solutions zu erobern.</p><p>Den Bereich Performance Solutions haben wir zudem mit einem Standort in München deutlich verstärkt. Mit <a href="http://appdynamics.com/">AppDynamics</a>  konnten wir ein Startup als Partner gewinnen, das bahnbrechende Technologie mit konkurrenzloser Usability vereint. Über 50 Kunden in den ersten 6 Monaten nach Markteintritt sprechen für sich.</p><p>Auch die <a href="/leistungen">Agile Software Factory</a>  war 2010 wieder in vielen Projekten unterwegs und dennoch haben wir Zeit gefunden Innovation zu betreiben. So wurde codecentric Program Development Partner und Anbieter der Professional Scrum Developer Schulungen von scrum.org.</p><p>Auch trugen codecentric-Mitarbeiter zur Weiterentwicklung verschiedener Open Source Projekte, insbesondere zum Testautomationswerkzeug <a href="http://code.google.com/p/robotframework/">robotframework</a>  bei.</p><p>In den Projektteams selbst stand 2010 vor allem die kontinuierliche Verbesserung der Projekträume an. Verschiedene Arten von <a href="http://twitpic.com/2mpij0">Extreme Feedback Geräten</a>  wurden installiert um den Zustand des Projektes immer im Blick zu haben.</p><p>Technologisch gesehen ist die Bewegung in Richtung Cloud kaum aufzuhalten. Unser Kunde eismann ist dort im letzten Jahr sicher angekommen und weitere werden bestimmt auch dieses Jahr folgen.</p><p>Zum Austausch mit anderen „Agilisten“ gründeten wir im Herbst 2010 den Agilen Stammtisch in Düsseldorf, dessen erste drei Veranstaltungen bereits sehr gute Resonanz zeigten.</p><p>Unser Bereich <a href="/leistungen">Document Solutions</a>  hat 2010 ein Großprojekt gestemmt und die zentrale Erfassung und Bearbeitung von Beihilfeansprüchen für die Bundesländer Rheinland-Pfalz, Hessen und Nordrhein-Westfalen realisiert. Zur Bearbeitung der Ansprüche in Detmold wurden durch das nun gestiegene Datenvolumen 100 neue Arbeitsplätze geschaffen.</p><p>Unter der Flagge von meet the experts fanden auch 2010 bestens besetzte Veranstaltungen und Schulungen, wie zum Beispiel der Certified Scrum Master mit Boris Gloger, ein Workshop zu Akzeptanztests mit Elizabeth Hendrickson und der beliebte Java Specialists Master Course von Dr. Heinz Kabutz statt.</p><p><strong>Wissen</strong><br /> Das Kapital von codecentric ist das Wissen ihrer Mitarbeiter. Aus diesem Grund wurde 2010 nicht nur weiter in die 4+1 Woche investiert, sondern es wurden auch unternehmensweit Softskill- und Sprachkurse  ermöglicht.</p><p>Gefeiert wurde natürlich auch ordentlich, sowohl auf kleinen Events der Teams als auch firmenweit, wie auf der Kanutour im Sommer oder der Weihnachtsfeier, welche auch dieses Jahr wieder von großartigen Reden geprägt war.</p><p>Unsere Kompetenz zeigten wir 2010 wieder einmal auf unzähligen Messen und Kongressen, wie zum Beispiel in einer Keynote auf der W-JAX, den XP-Days, der OOP oder der gearconf. Diesen Trend wollen wir natürlich auch 2011 fortsetzen. So werden wir z.B. auf der JAX neben Vorträgen auch den <a href="http://jax.de/2011/specialdays/">Performance Day</a>  ausrichten. Wir freuen uns auf einen interessanten Meinungsaustausch mit euch vor Ort, oder, falls es euch die Umstände nicht erlauben auch über unsere neu gestalte Homepage und den von unseren Mitarbeitern belebten Blog.</p><p><strong>Apropos Blog</strong></p><p>Die Zugriffszahlen auf den Blog erfreuen uns sehr, besuchten uns 2010  doch über 50 Tausend Leser allein über das Web. Viele weitere lesen uns über unsere RSS Feeds. 2010 haben wir 95 Beiträge in Deutsch und 73 in Englisch verfasst. Zahlen, die wir in 2011 noch übertreffen wollen.</p><p>Als Projekt zur Ergänzung  des Blogs haben wir das Experiment podcast gestartet, welcher bereits 5 Episoden alt ist. Die Resonanz war durchweg positiv, wie auch das Feedback zu der <a href="http://www.facebook.com/more4fi">Facebookseite für Fachinformatiker</a> , welche wir unter dem Namen unserer Verbundausbildung „more4fi“ führen.</p><p>Wir haben uns 2010 den Spaß an der Arbeit auch nicht durch den Einbruch in unser wunderschönes Amtsgericht oder das Festsitzen im Tiefschnee auf dem Parkplatz vermiesen lassen und gehen hochmotiviert in das bereits gut gestartete neue Jahr.</p>

Eine Retrospektive auf 2010

<p>In dem letzten Teil meiner WPO Serie möchte ich mich der Clientseite zuwenden. Aktuell schauen wir zwar nur auf Browser, doch ich denke in Zukunft werden auch Apps von ähnlichen Optimierungen profitieren, sind doch manche sogar schon in HTML geschrieben.</p><p>Ein interessanter Aspekt von Browseroptimierung ist, dass es auf Annahmen basiert. Das ist eine nette Parallele zu SEO, welches fast ausschließlich auf Experimenten basiert, da niemand so recht weiß wie die Suchmaschinen bewerten. Deswegen nennen die meisten WPO Tools ihre Einschätzungen „Grade“ (Note). Genau wie in der Schule wissen wir nicht genau wie wir besser werden können, oder ob man noch deutlich besser als „sehr gut“ werden kann. Wir können nur versuchen uns zu verbessern. Dennoch gibt es ganz hilfreiche Werkzeuge, welche uns helfen können eine aktuelle Bewertung zu ermitteln und Ideen zur Verbesserung zu erhalten. Zwei Beispiele sind <a href="http://developer.yahoo.com/yslow/">YSlow</a>  von Yahoo und <a href="http://code.google.com/speed/page-speed/">PageSpeed</a>  von Google, welche beide einen Katalog von Best-Practices verwenden, um Webseiten zu überprüfen.</p><p>Alternativ kann man auch einen Aggregator wie <a href="http://www.webpagetest.org">webpagetest.org</a>  oder <a href="http://www.showslow.com">showslow.org</a>  verwenden, um verschiedene Tests ausführen zu lassen. Alle Werkzeuge bieten aber am Ende immer eine Art Checkliste mit Best-Practices und unser Abschneiden. Leider erhält man keine wirkliche Empfehlung wo man mit dem größten Effekt einfach optimieren kann.<br /> <span></span></p><h2>Requests verschwenden Zeit</h2><p>Abgesehen davon, dass wir nicht genau wissen wie sich das Antwortzeitverhalten einer Seite nach Anwendung von Best-Practices verbessern wird ist eines klar, unnötige Serveranfragen müssen vermieden werden. Sie kosten Zeit und Geld. Schauen wir uns die zwei Hauptbestandteile mal an:</p><ol><li>Verbindungsaufbau</li><li>Datenübertragung</li></ol><p>Natürlich kommt eine Datenübertragung nie ohne einen Verbindungsaufbau zustande. Die Datenübertragung kann im Wesentlichen mit zwei Mitteln eingedämmt werden.</p><ol><li>Komprimierung</li><li>Caching</li></ol><h3>Komprimierung</h3><p>Komprimierung ist leider oft vernachlässigt, obwohl sie einfach einzustellen ist. Dieser Umstand ist frühen Versionen des Internet Explorers geschuldet und eigentlich heute nicht mehr relevant. Die Komprimierung sollte nicht selbst programmiert werden, sondern dem Container überlassen werden. Den Apache konfiguriert man zum Beispiel so:</p>

```
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css
  text/javascript application/x-javascript application/javascript
  application/json application/xml text/x-component
</IfModule>
```

<p>Natürlich ist es auch sinnvoll seine Bilder zu komprimieren. Vor ein paar Tagen hat Kornel Lesinski ein nettes Tutorial über <a href="http://calendar.perfplanet.com/2010/png-that-works/">PNGs die funktionieren</a>  (englisch) veröffentlicht, in welchem er auch über die Probleme mit transparenten PNGs im IE 6 schreibt.</p><h3>Caching</h3><p>Caching zu aktivieren ist einfach, die korrekte Einstellung erfordert aber etwas mehr Zeit, denn es muss verhindert werden, dass kein veralteter Inhalt ausgeliefert wird. Zwar kann man versuchen das dynamische HTML zu cachen, aber die meisten Seiten würden schon vom Caching statischer Ressourcen profitieren. Falls man also vom CMS verwaltete Ordner wie „export“ oder ein Verzeichnis mit Bildern hat, dann kann man alle Ressourcen dort mit einer langen Gültigkeit versehen. Dies geht im Apache auch sehr einfach:</p>

```
<IfModule mod_expires.c>
 ExpiresActive On
 ExpiresDefault "access plus 10 years"
</IfModule>
```

<p>Will man ein Bild allerdings durch ein Neues ersetzen, so muss man zwangsweise einen neuen Namen vergeben, da es ansonsten nicht erneut heruntergeladen werden würde. Schließlich haben wir dem Browser mitgeteilt, dass es 10 Jahre gültig sei. Der übliche Lösungsansatz dafür ist eine Version oder einen Zeitstempel mit in den Dateinamen aufzunehmen. Problem gelöst! Dieser Vorgang kann entweder manuell oder automatisch durchgeführt werden, dazu später mehr.</p><h3>Verbindungsaufbau</h3><p>Bezüglich des Verbindungsaufbaus habe ich bereits in meinem zweiten Beitrag den Slow-Start Trick beschrieben. Allerdings kann man unnötige Verbindungen einfach vermeiden, indem man Ressourcen zusammenfasst, anstelle für jeden kleinen Inhalt eine neue Verbindung aufzubauen. Dies wird üblicherweise durch das Zusammenfassen von JavaScript realisiert, oder durch CSS-Sprites, eine Technik von den ersten Computerspielen, bei denen aus vielen kleinen Bildern eine große Collage erstellt wird, die einmalig runtergeladen wird und dann nur den benötigten Ausschnitt anzeigt. Der beste Ratschlag ist natürlich nichts einzubinden was nicht benötigt wird.</p><h2>JavaScripte verschwenden Zeit</h2><p>Browser erfüllen vielfältige Aufgaben, aber die welche am meisten Zeit benötigt ist das Parsen und Ausführen von JavaScript code. Dies ist auch der Grund dafür, dass Browserhersteller ihre JavaScript Engines kontinuierlich verbessern. Als Folge davon ist es ungewiss wie lange so großartige Benchmarks wie das JavaScript Loop Benchmark (englisch) von Greg Reimer noch ihre Gültigkeit bewahren. Ich persönlich sehe das Hauptproblem in der Menge von schlechtem JavaScript code im Internet. Dieser wird von Entwicklern vorbehaltlos kopiert anstelle korrekten Code selbst zu programmieren. JavaScript ist eine mächtige Sprache, und es schockiert mich zu sehen wie schlecht mit ihr umgegangen wird (ok, ich habe das leider auch schon getan).</p><p>Aus dem verlinkten Benchmark kann man ablesen wie leicht es ist fatale Fehler einzubauen. Eine clevere Anwendung der Sprachfunktionen führt die Schleife in 15 ms aus. Fehlerhafte Anwendung benötigt dazu 3203ms (Beispiel: HTML Collection (length=1000, looped 100 times), IE7).<br /> Hinzu kommt, dass JavaScript Ausführung in der Regel die Seitendarstellung blockiert. Diesen unschönen Effekt kann man häufig mit Werbebannern beobachten. Die Antwort dazu ist sogenanntes „Unobtrusive JavaScript“, welches das JavaScript an das Ende der Seite verlagert. Allerdings ist das Entfernen von sämtlichen inline JavaScript selten eine realistische Tuningmaßnahme.</p><p>Allerdings gibt es etwas was wir tun können und sollten: <strong>JavaScript profilen</strong>. Die Zeitmessspezifikationen der <a href="http://www.w3.org/2010/webperf/">W3C-Performance Working Group</a>  sind noch im Entwurfsstatus, jedoch existiert in der hervorragenden FireBug Erweiterung des Firefox ein Profiler. Die Chrome Developer Tools sind ebenfalls gut geeignet. Beide erlauben die Codeausführung zu messen und optimierbare Hotspots zu finden.</p><h2>Automatische Verbesserungen</h2><p>Kürzlich hat Google ein Apache Modul namens <a href="http://code.google.com/speed/page-speed/docs/module.html">mod_pagespeed</a>  veröffentlicht. Die Idee hinter mod_pagespeed ist, dass die Best-Practices einfach befolgt werden sollten, da sie keine Probleme verursachen. Allerdings sind manche manuell nicht so einfach umzusetzen, automaisch jedoch schon. Genau das macht mod_pagespeed, indem es HTML nachbearbeitet und Caching ermöglicht. Es funktioniert hervorragend auf nicht optimierten Seiten, aber es kann auch negativen Einfluss haben, da es zusätzlichen Code ausführt. Mein üblicher Rat gilt hier auch: Ergebnisse sollten mit Messungen verifiziert werden. Des weiteren gibt es noch kommerzielle Lösungen welche teilweise auch ein CDN mitliefern.</p><p>Eine etwas andere Art einer „automatischen Verbeserung“ ist das <a href="http://html5boilerplate.com/">HTML5 Boilerplate</a> , eine Webseitenvorlage, welche bereits die besten und bewährten Konfigurationen dokumentiert mitliefert. Ich kann nur empfehlen mal einen Blick darauf zu werfen, insbesondere halte ich den CSS Teil für sehr informativ.</p><h2>Zusammenfassung</h2><p>Es ist meine feste Überzeugung, dass der Einsatz der genannten Best-Practices Webseiten schneller macht. Allerdings ist es nicht so einfach die Änderung ausfindig zu machen, die mit 20% Aufwand 80% Verbesserung bringt. Die Werkzeugunterstützung ist leider noch begrenzt und Browser werden auch von Tag zu Tag schneller, so dass wir sowieso am Besten mit einem sauberen Design aufgestellt sind. Falls Sie gerne ausführlich zu dem Thema WPO beraten werden wollen, kontaktieren Sie uns einfach. Wir können herausfinden welcher Teil ihrer Applikation verantwortlich für längere Ladezeiten ist und finden so die Optimierungen, die für Sie den größten Effekt mit geringem Aufwand liefern.</p><p>Ich hoffe meine kurze Einführung in das Thema Web Performance Optimierung war aufschlussreich. Ich wünsche gesegnete Weihnachten!</p><p><strong>Meine WPO Serie:</strong></p><ol><li><a href="/wissens-hub/blog/web-performance-optimierung-ist-das-neue-seo">Web Performance Optimierung ist das neue SEO</a> </li><li><a href="/wissens-hub/blog/web-performance-optimierung-die-infrastruktur">Web Performance Optimierung: Die Infrasturktur</a> </li><li><a href="/wissens-hub/blog/web-performance-optimierung-serverseitige-software">Web Performance Optimierung: Serverseitige Software</a> </li><li>Web Performance Optimierung: Clients</li></ol>

Web Performance Optimierung: Clients

<p>In diesem Teil meiner Serie über WPO betrachte ich den traditionellsten Teil: Die auf dem Server laufende (selbst geschriebene) Software. Deswegen enthält die Optimierung also auch alle Software Design Entscheidungen und den entstandenen Quelltext. Hier gelieferte Beispiele sind an Java angelehnt, da ich mich größtenteils in diesem Umfeld aufhalte.</p><h2>Skalierbare Architekturen</h2><p>In meiner Zeit vor codecentric habe ich an einigen Projekten gearbeitet, welche (hoffentlich ohne mein Verschulden) in Probleme geraten sind und immer spät waren. Als ein Resultat wurden Systemtests und Skalierbarkeitstests gestrichen. Das war auch gar nicht so tragisch, da am Ende des Projektes geplante Tests sowieso keinen Probleme identifizieren können, die noch realistisch behebbar sind. Bei codecentric arbeiten wir an der stetigen Verbesserung unseres agilen Entwicklungsprozesses, um diesen Problemen entgegenzuwirken. Also denken wir über ein skalierbares Design schon ab dem ersten Tag nach. Die Frage „<em>Was müssen wir ändern, um 2 Server hinzuzufügen?</em>“ sollte idealerweise mit „<em>nichts</em>“ beantwortet werden. Wie kommt man also dahin? Einige der Faktoren für skalierbares Design habe ich in meinem <a href="/wissens-hub/blog/web-performance-optimierung-die-infrastruktur">Infrastruktur orientierten WPO</a>  schon angesprochen.<br /> <span><br /> Agile Methoden helfen sicher, aber auch ohne kann man mit Skalierbarkeit schon von Anfang an experimentieren. Dazu gehören rudimentäre Lastests durch die man die Verhaltensmuster der Anwendung unter Last studieren kann. Zwar würde ich sehr gerne diese Tests ständig ausgeführt und als Teil der Definition of Done sehen, jedoch denke ich, dass es sinnvoll ist, diese <em>überhaupt</em> früh durchzuführen.<br /> Allerdings wird durch Tests die Skalierung nicht magisch umgesetzt. Sie muss designt werden. Gernot Starke sprach auf unserem letzten Meet The Experts über das Problem von Softwarearchitekten etwas über gute Designs zu lernen. Sein Argument war, dass trotz den Veröffentlichungen der Designentscheidungen und Lösungen großer Firmen wie <a href="http://www.facebook.com/note.php?note_id=39391378919">Facebook</a> , <a href="http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster">Twitter</a> , <a href="http://www.infoq.com/articles/ebay-scalability-best-practices">Ebay</a> , Amazon und Google, diese nicht auf die Anwendungen anwendbar seien, welche wir tagtäglich entwickeln.<br /> Ich denke er hat recht. Und irrt sich zugleich. Ja, wir haben vielleicht keine hunderttausend Datenbankabfragen pro Sekunde. Allerdings kann ein Design, welches diese Extrema unterstützt besser funktionieren und skalieren als etwas, was ich mir selbst ausgedacht hätte. Und das gilt auch für kleinere Anwendungen, weswegen ich davon überzeugt bin, dass es Sinn macht, sich diese Beispiele anzusehen.</span></p><h2>Fremdsoftware regelmäßig aktualisieren</h2><p>Es ist nicht nur unser Design und unsere Programmierung, die die Performance des Gesamtsystems ausmacht. Oft sind eine Reihe von weiteren Softwareprodukten involviert. Ich nehme an, dass wir mindestens ein Dutzend externer Software als Teil unserer Anwendung oder Lösung verwenden. Das ist keineswegs schlecht, denn wir müssen diesen Code nicht schreiben und sparen so eine Menge Zeit. Auch müssen wir keinesfalls Experten in Regelsystemen, Netzwerkverbindungsverwaltung, Caches, Kodierung, Kompression oder vielem mehr sein. Wir können uns allein auf die Erstellung unserer Anwendung konzentrieren. Wenn wir also einer Reihe von guten Komponenten vertrauen, warum aktualisieren wir diese dann nicht regelmäßig? In den vergangenen Jahren hat fast jedes Produkt in jedem Release „Performance“ als Punkt auf der Änderungsliste gehabt. Wir nutzen dies aber viel zu selten, wofür es meiner Meinung nach 2 Gründe gibt:</p><ol><li>Angst vor Problemen mit Abwärtskompatibilität</li><li>Chaotische Drittanbietersoftwareverwaltung mit einem unflexiblen Prozess</li></ol><p>Zwei sehr triftige Gründe. Allerdings wird der erste Grund im Laufe der Zeit immer gravierender. Nach einer gewissen Zeit haben sich die kleinen Anpassungen zu einem großen Haufen angesammelt, den niemand mehr anfassen möchte. Ich empfehle deshalb oft auf Aktualisierungen zurückzugreifen, da man nur so Performanceverbesserungen von den externen Experten erhält. Interessanterweise existiert sogar ein Zusammenhang zwischen der Angst vor dem Wechsel und dem (Performance) Gewinn. Applikations-Server, Datenbanken, UI Frameworks und Regelsysteme erhalten oft weitaus bessere Performanceschübe bei einem Upgrade als die Aktualisierung einer Minor-Version von Apache commons-lang. Aber die Angst ist größer, was wahrscheinlich daran liegt, dass sie größer und komplexer sind. Genau aus diesem Grund bieten sie aber für ihre Autoren ein gutes Optimierungspotential. Und wenn wir Angst vor dem Update einer Bibliothek haben. Warum setzen wir sie dann überhaupt ein?<br /> Das zweite Problem ist schwieriger zu lösen, und leider denken viele es würde ausreichen Maven auf das Problem zu werfen und es würde verschwinden. Allerdings ist es oftmals so, dass kein gründliches Abhängikeitsdesign durchgeführt oder das Problem einfach ignoriert wird. Zwar kann ein Buildmanagementsystem und die Deklaration von Abhängigkeiten und zum Beispiel OSGi als Laufzeitsystem das Thema technisch unterstützen, aber die Lösung muss in der Planung eines sauberen Vorgehens gefunden werden.</p><h2>Die Wahl des schnellsten Kommunikationsprotokolls</h2><p>Kommunikationsprotokolle sind sehr wichtig in verteilten Systemen. Jedoch treffen wir häufig nicht die richtige Entscheidung. Durch den SOA Hype bedingt, bauen wir alle Software, die SOAP Webservices verwenden. Die denkbar schlechteste Wahl – zumindest aus Performancesicht. Oft sind dann auch noch die Services falsch geschnitten, wodurch übermäßig große Datenmengen übertragen werden müssen oder unnötig viele Remoteaufrufe stattfinden. Nehmen wir an, wir haben ein gutes Design, dann kann das verwendete Protokoll trotzdem eine große Bedeutung haben. Es gibt einige öffentliche Benchmarks, wie das <a href="http://docs.jboss.org/jbossremoting/docs/benchmark/performance_benchmark.html">JBoss Remoting Benchmark</a> , oder das Java Benchmark von Daniel Gredler sowie viele andere. Idealerweise führt man natürlich das Benchmark selber auf eigenem Code durch.<br /> Im Falle von AJAX ist die Wahl einfacher, da es im wesentlichen nur 3 Protokolle gibt die alle über HTTP abgewickelt werden.</p><ol><li>XML – Doch auf Grund der enormen Datenmengen von fast niemandem verwendet.</li><li>JSON – Das beliebteste Protokoll. Oftmals handelt es sich nur um Schlüssel-Wert Paare. Kann schnell in native JavaScript-Objekte übersetzt werden.</li><li>JavaScript – Anstelle von lediglich Objekten wird ausführbarer JavaScript Code übertragen. Dies ermöglicht viele Tricks, ist aber oft ein Anzeichen eines zu generischen Interfaces.</li></ol><p>Eine interessante Alternative dazu werden <a href="http://dev.w3.org/html5/websockets/">WebSockets</a>  werden, welche in zukünftigen Browserversionen Unterstützung finden werden und schon jetzt durch Produkte wie Kaazing ermöglicht ist.</p><h2>Einblicke in die Anwendungsperformance</h2><p>Für WPO ist die Anwendung auf der Serverseite eine große schwarze Box, doch leider ist sie oft der Hauptverursacher für langsame Antwortzeiten. Dies kann nicht durch WPO Tricks optimiert werden, sondern benötigt Nachforschungen über ihre Ursache in der Anwendung. Dafür eignen sich Application Performance Monitoring Lösungen. Anders als traditionelle Systemüberwachung schauen sie in die Anwendung hinein, weshalb APM Lösungen oft auf eine Programmiersprache begrenzt sind. Für Java ist <a href="http://www.appdynamics.com/">AppDynamics</a>  die derzeit beste Lösung auf dem Markt, weswegen es auch in unserem Lösungsportfolio seinen Platz findet. Mit einer Monitoringlösung erhält man schnell die nötige Information um sich Quellen von Performanceproblemen genau anzusehen. Arbeitet man an der Behebung solcher Probleme sind Profiler auf den Entwicklermaschinen das geeignete Mittel, um sämtliche noch so kleinen Details über die untersuchte Transaktion zu erfahren und alternative Lösungsansätze gegeneinander zu bewerten. Für Java empfehle ich <a href="http://www.yourkit.com/">YourKit</a>  oder <a href="http://www.ej-technologies.com/products/jprofiler/overview.html">JProfiler</a> .</p><p>Leider schauen sich viele WPO Experten die Serverseite zu wenig an, obwohl sie oft einen wichtigen Anteil an der Gesamtperformance hat. Bei codecentric hingegen haben wir jahrelange Erfahrung in der Lösung solcher Probleme; von Design und Architektur bis Tief in die Codeebene. In der letzten Ausgabe dieser Serie werde ich dann über die am meisten gehypten Aspekte von WPO sprechen: Optimierungen im Browser.</p><p><strong>Meine WPO Serie:</strong></p><ol><li><a href="/wissens-hub/blog/web-performance-optimierung-ist-das-neue-seo">Web Performance Optimierung ist das neue SEO</a> </li><li><a href="/wissens-hub/blog/web-performance-optimierung-die-infrastruktur">Web Performance Optimierung: Die Infrasturktur</a> </li><li>Web Performance Optimierung: Serverseitige Software</li><li><a href="/wissens-hub/blog/web-performance-optimierung-clients">Web Performance Optimierung: Clients</a> </li></ol>

Web Performance Optimierung: Serverseitige Software

<p>In meinem letzten Beitrag beschrieb ich 3 Kernbereiche von WPO. Die Infrastruktur ist dabei der Bereich der Serverlandschaft. In diesem Blog beschreibe ich ihn etwas ausführlicher.</p><h2>Über Content Delivery Networks</h2><p>Wäre es nicht gut jemanden zu haben, der unseren Inhalt bereitstellen würde, idealerweise ganz nah bei unseren Kunden? Das ist die Aufgabe von Content Delivery Networks (CDN). Bisher wurden sie nur von großen Firmen mit weltweitem Kundenkreis genutzt. Aber auch lokal begrenzt können sie nützlich sein, da sie üblicherweise über die schnellstmögliche Netzanbindung verfügen und gegebenenfalls sogar IT Kosten senken können. Bilder auf einer anderen (Sub-)Domain anzubieten reduziert den Datentransfer, da weniger Header und Cookies mit jeder Anfrage gesendet werden. Diese Subdomains können auch auf spezialisierte Server verweisen. Ein Beispiel: ein httpd Server kann statische Bilder von einer RAM disk ausliefern, anstelle sie von einem Tomcat bei jedem Aufruf aus einem Archiv auspacken zu lassen. Außerdem können auch öffentliche CDNs wie zum Beispiel Google verwendet werden.<br /> <span>Ein sehr gutes Beispiel ist die Einbindung von JavaScript Bibliotheken von Google. Diese werden nicht nur von einem bestens angebundenen Netz bereitgestellt und kosten keine Serverkapizitäten, sondern sie maximieren auch den Effekt von Caching, da der Cache mit anderen Webseiten geteilt wird und so der Cache sogar bei Erstbesuchern gefüllt sein kann. Eine ausführliche Beschreibung über die Vorteile von Google als CDN hat Dave Ward sehr gut zusammengestellt.</span></p><h2>Verteilte Caches sind schnelle Datenbanken</h2><p>Hosting von statischen Inhalten ist aber nur ein Teil der Infrastruktur. Der andere Teil ist die Anwendung mit ihrer Geschäftslogik. Hier können natürlich keine vorgefertigten Antworten vorgehalten werden, sondern es muss sichergestellt werden, dass Antworten auch dann zügig ausgeliefert werden können wenn tausende Benutzer die Seiten verwenden. Sobald man nicht mehr mit einem einzigen Server auskommt werden die Dinge kompliziert. Dem entgegnet man am besten mit einem einfachen Design. Ein weit verbreitetes Problem in Java Anwendungen ist der pro Node gehaltene Zustand der Session. Die Folge davon ist, dass man Benutzer nicht einfach zwischen Server umschieben kann. Dieses „sticky Session“ genannte Problem wurde durch die Einführung von Replikationsmechanismen, welche den Zustand zwischen Nodes kopieren, bekämpft. Allerdings rate ich davon ab, dieses Verfahren als echte Lösung zu betrachten. Es verursacht eine Reihe von Problemen und kostet viel Zeit und Geld. Der dadurch herausgeholte technische Vorteil reicht aber nicht aus, um wirklich zu skalieren. Es wäre viel besser einen zustandslosen Server zu haben, welcher problemlos dynamisch gestartet oder gestoppt werden kann. Das Problem ist also: wohin mit dem Zustand? Ohne Frage ist Zustand sinnvoll.<br /> Schaut man zurück, so wurde der Zustand in die Session gelegt, da die zentrale Datenquelle, „Datenbank“ genannt, einfach viel zu langsam war und selbst nicht gut skalierbar ist. Nun fordere ich natürlich nicht den Zustand zurück in eine relationale Datenbank zu legen. Nein, ich würde sie sogar ganz aus meiner Architektur entfernen wollen. Zeitgemäße Lösungen für diese Herausforderung liefern sogenannte NoSQL Datenbanken, welche verteilt arbeiten und die Daten als einfache Schlüssel-Werte Paare speichern.<br /> Das klingt erstmal sehr einfach, ist aber sehr mächtig. Viele aktuelle Entwicklungen kommen viel besser ohne eine relationale Datenbank zurecht. Große Java NoSQL Datenbanken sind Hadoop und Cassandra.<br /> Session Informationen können auch einfach im Speicher eines verteilten Speicher caches wie MemCache liegen. Unter <a href="http://nosql-database.org/">nosql-database.org</a>  gibt es eine großartige Liste mit diesen Lösungen und Produkten.<br /> Nach diesem etwas längeren Exkurs zurück zum Thema. Es geht darum Anwendungen einfach skalierbar zu machen. Mit Anstieg der Last erreicht man zwangsläufig Grenzen an denen die Software auf vorhandener Hardware nicht länger linear skaliert. In diesen Situationen benötigt man zusätzliche Server. Idealerweise speziell dedizierte Server für API Aufrufe, Webservices oder Geschäftslogik. Server bei Bedarf starten zu können, und das sogar nahe beim Kunden ist der echte Wert der „Cloud“. Dies ist nicht möglich wenn man weiterhin komplizierte Failover und Replikationssysteme verwendet, wie man es heute noch in großen Firmen tut.</p><h2>Protokolltuning und seine Effekte</h2><p>Natürlich sollte schnelle Netzwerkausrüstung und Anbindung sowie eine sinnvolle Verteilung der physikalischen Hardware auch bei virtualisierten Umgebungen gegeben sein. Zwar bietet sich hier wenig Potential für Tuning, allerdings haben Firmen wie Google damit begonnen neue Netzwerkprotokolle wie <a href="http://www.chromium.org/spdy/spdy-whitepaper">SPDY</a>  zu erfinden, eigene, spezialisierte Netzwerkkarten zu bauen und auch die durch RFCs gesetzten Regeln zu dehnen. Ein Beispiel dafür ist das sogenannte „slow-start“ Feature von TCP. Wie viele RFCs, wurde TCP in den frühen Tagen der Netzwerke erfunden und wird weiterhin genutzt. Damals hatten die Clients schlechte Anbindungen an die Server, was zu der Folgerung führte, dass Server vor langsamen Clients beschützt werden müssen (und auch anders herum). Also begann man nur wenig Daten zu senden und erhöhte diese Frequenz langsam sobald sie quittiert wurden. Die Datenmenge welche initial, also ohne Bestätigung, gesendet werden darf, ist im sogenannten <em>initial window</em> in <a href="http://www.rfc-editor.org/rfc/rfc3390.txt">RFC 3390</a>  definiert. Sendet man nun aber mehr Daten kann man einige Roundtrips sparen, da keine Antwort des Clients zur vollständigen Datenübermittlung nötig ist. Durch diese Methode kann man unter 100ms Antwortzeiten gelangen und ermöglicht z.B. ein Sucherlebnis wie Google Instant. Eine gute Einführung in das Thema Slow-Start mit weiterführenden Links findet man in Ben Strong’s Blog über Slow Start (in Englisch).</p><p>Dies sind nur ein paar Ideen wie man auf der Infrastrukturseite die Performance von Webseiten optimieren kann. Zwar sind einige Ideen stark von der Anwendung abhängig, andere wie z.B. ein optimiertes Initial Window könnten auch von Hosten ihren Kunden als Premiumdienste angeboten werden. Zwar ist Infrastruktur nicht unser Fokus bei codecentric, trotzdem können wir insbesondere bei dem Entwurf der Anwendungen diese Optionen berücksichtigen und dafür sorgen, dass Anwendungen für eine bestmögliche Performance in der Infrastruktur designt sind. Wir sprechen ausserdem die Sprache von Betrieb und Entwicklung und können so bei der Integration unterstützen. Über die Optionen auf der Anwendungs- und Softwareseite schreibe ich in meinem nächsten Beitrag.</p><p><strong>Meine WPO Serie:</strong></p><ol><li><a href="/wissens-hub/blog/web-performance-optimierung-ist-das-neue-seo">Web Performance Optimierung ist das neue SEO</a> </li><li>Web Performance Optimierung: Die Infrastruktur</li><li><a href="/wissens-hub/blog/web-performance-optimierung-serverseitige-software">Web Performance Optimierung: Serverseitige Software</a> </li><li><a href="/wissens-hub/blog/web-performance-optimierung-clients">Web Performance Optimierung: Clients</a> </li></ol>

Web Performance Optimierung: Die Infrastruktur

<h2>Was ist Web Performance Optimierung?</h2><p>SEO ist der Weg Webseiten erfolgreich zu machen? Nicht mehr. Search Engine Optimization (Suchmaschinenoptimierung) war vor 10 Jahren nützlich, als Suchmaschinen Hilfe bei der Indexierung von unserem Webseiteninhalt benötigten. Heutzutage ist es eigentlich nur noch eine Herausforderung gute Inhalte zur Verfügung zu stellen, welche dann von den Suchmaschinen auf magische Weise gefunden werden. Insbesondere ist es interessant zu sehen, dass Webseiten mit gutem Inhalt aber „schlechter SEO“ besser bewertet werden als SEO-optimierte Seiten mit schlechtem Inhalt.<br /> Da es Kunden also einfach möglich ist die richtigen Inhalte zu finden, so liegt es an uns sicherzustellen, dass die Kunden auch zufrieden mit ihrem Besuchserlebnis auf unseren Webseiten sind. Andernfalls können sie leicht einen Wettbewerber finden.<br /> <span><br /> Der bedeutendste Faktor bei der Kundenzufriedenheit ist die Performance der Webseite. Also müssen wir sicherstellen, dass Webseiten schnell sind. Dies nennt man Web Performance Optimization = WPO. WPO bedeutet die diversen Herausforderungen von verteilten Webanwendungen zu meistern und die Inhalte so schnell wie möglich zum Kunden auszuliefern.<br /> Dies stellt diese nicht nur zufrieden sondern fördert auch mehr Umsatz, denn Studien haben gezeigt, dass Benutzer Seiten bevorzugen die schnell laden. Dies gilt insbesondere für Mobile Internetnutzung über Handy oder iPad. 2-3 Sekunden ist dabei die durchschnittlich tolerierte Wartezeit. Dann sucht sich der Kunde üblicherweise eine schnellere Alternative. Für die Zukunft geht der Trend auf Antwortzeiten deutlich unter 2 Sekunden.<br /> Als Seiteneffekt von verbesserter Performance kann man auch die damit verbundene Reduktion von Bandbreite und Strom sehen, welche zusätzlich die Kosten pro Verkauf reduzieren und den Gewinn erhöhen.</span></p><h2>Ist der Effekt von WPO auf Zufriedenheit und Umsatz messbar?</h2><p>Die angesprochenen Zahlen sind in der Tat real. Mehrere Firmen haben den Einfluss ihrer Performanceoptimierungen gemessen und veröffentlicht.</p><p>Das wohl beste Beispiel ist Google. Als Google den Suchmaschinenmarkt betrat war dieser eigentlich schon unter großen Firmen aufgeteilt. Dennoch verstand es Google die besten und schnellsten Suchergebnisse zu liefern. In nur wenigen Monaten wurde Google zur Nummer 1 der Suchmaschinen. Google arbeitet jeher an schnellstmöglichen Internetangebot und veröffentlichte vor kurzem Google Instant: Eine Suchmaschinenerweiterung die die Ergebnisse liefert noch bevor man aufgehört hat die Suche zu tippen.</p><p>Aber auch neben Google existieren große Internetfirmen, welche ihren Erfolg auf WPO stützen. Hier ein paar interessante Fakten (Quellen auf Englisch).</p><ul><li>Amazon: 100 ms Verzögerung verursachte einen messbaren <a href="http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html">Verlust im Ertrag</a> .</li><li>Google: 400 ms verursachen eine 0.59% Abnahme in den Suchanfragen pro Benutzer.</li><li>Yahoo!: eine 400 ms Verzögerung <a href="http://www.slideshare.net/stoyan/dont-make-me-wait-or-building-highperformance-web-applications">reduzierte den Traffic um 5-9%</a> .</li><li>Bing: 2 Sekunden langsamere Ergebnisse kosten 4.3% Ertrag pro Benutzer.</li><li>Mozilla machte die Firefox Downloadseite 2,2 Sekunden schneller und <a href="http://blog.mozilla.com/metrics/category/website-optimization/">erhielt dadurch 15.4% mehr Downloads</a> .</li><li>Google Maps reduzierte die übertragenen Daten um 30% <a href="http://news.cnet.com/8301-10784_3-9954972-7.html">und beobachtete einen 30% Anstieg an Kartenanfragen</a> .</li><li>Netflix, nutzen Appdynamics um ihre Performance zu überwachen und schalteten gzip auf ihren Servern ein. Dies alleine beschleunigte die Seiten um 13-25% und sparte 50% der Datenübertragung!</li><li>Shopzilla brachte die Ladezeiten von 7 auf 2 Sekunden. Dabei beobachteten sie eine 7-12 fache Erhöhung ihrer Realisierung eines Besuchers zu einem Kunden, einen Anstieg der Seitenaufrufe um 25% und sie konnten <a href="http://www.stevesouders.com/blog/2008/03/06/how-green-is-your-web-page/">50% ihrer Serverkapazitäten einsparen</a> , und damit Energiekosten reduzieren.</li><li>AOL beobachtete die Seitenaufrufe verschiedener Webseiten. Auf schnellen Seiten wurden 7-8 angeklickt, auf langsamen nur etwa die Hälfte.</li><li>Edmunds gelang es von über 10 Sekunden auf unter 2 zu kommen, welches in 17% mehr Seitenaufrufen resultierte. Der Ertrag der Webseite stieg um 3%.</li></ul><h2>Wie setzt man WPO um?</h2><p>3 Parteien haben die meisten Einflüsse auf die Verbesserung der Performance. Idealerweise geht man das Thema aber gemeinsam an, da sich die Bereiche auch überschneiden.</p><h3>Infrastruktur und Hosting Team</h3><p>Üblicherweise setzt man zur Bearbeitung von hoher Last eine Skalierungs- und Loadbalancingtechnologie ein. Allerdings gibt es im Detail viele verschiedene Optionen. Bei den großen Internetfirmen sind shared nothing Ansätze oft zu finden, während innerhalb von Firmen oft Failover und Replikationsstrategien genutzt werden.<br /> Content Delivery Networks (CDNs) können genutzt werden um den Inhalt näher zum Kunden zu bringen und von einer besseren Anbindung zu profitieren.<br /> Oftmals ist das Hosting an einen Dienstleister ausgelagert, welcher für seine Kunden hier individuelle Lösungen erstellen kann. Viele Optimierungen haben aber auch Auswirkungen auf die Anwendungsentwicklung. Hier profitiert man sicher von der DevOps Bewegung, welche diese Parteien zusammenbringt.</p><h3>System und Software Architekten</h3><p>Wenn wir über die Serverseite sprechen, dann bezieht das oft den Code ein, der die Webseiten und Ajax Antworten generiert. Dieser Bereich kann je nach Komplexität der Geschäftslogik sehr groß sein. Problemfelder sind hier Design- und Kodierfehler. Bei codecentric helfen wir seit Jahren Kunden diese Herausforderungen mit Java basierten Softwaresystemen zu lösen. In diesem Bereich ist sogar die Aktualisierung von Drittanbietersoftware wie Frameworks oder Applikationserver eine erwägenswerte Option. Nicht zuletzt gehört die richtige Wahl von Protokollen und Cachingstrategien zu großen Aufgabenfeldern.</p><h3>Web Entwickler</h3><p>Die übliche Annahme, dass ein Webclient leichtgewichtig ist stimmt nicht mehr für moderne Anwendungen. Markup, Javascript und CSS zu parsen und auszuführen kann ein langsamer Prozess sein. Komplexe Layouts und Code können Browserengines über Gebühr belasten. Insbesondere Mobile Endgeräte sind davon besonders betroffen, müssen sie mit weniger Leistung auskommen. Zwar haben Browserhersteller viele Verbesserungen in ihre Browser eingebaut, dennoch können sich Optimierungen drastisch auswirken.<br /> Entwickler müssen außerdem daran denken, die zu übertragenden Daten sinnvoll zu wählen. Diese müssen klein und schnell sein, sowie nicht unnötig erneut angefragt werden.</p><p>In den nächsten Ausgaben dieser Mini Serie werde ich über diese 3 Bereiche schreiben und sie mit Best Practices oder typischen Antipattern vorstellen. Auch gibt es für die Bereiche unterschiedliche Diagnose und Monitoringwerkzeuge.</p><p>Vielen Dank an <a href="http://twitter.com/coachwei">Coach Wei</a>  der mit <a href="http://blog.yottaa.com/2010/11/secret-sauce-for-successful-web-site-web-performance-optimization-wpo/">seinem Beitrag über WPO </a> mir viele Anregungen und Fakten geliefert hat.</p><p><strong>Meine WPO Serie:</strong></p><ol><li>Web Performance Optimierung ist das neue SEO</li><li><a href="/wissens-hub/blog/web-performance-optimierung-die-infrastruktur">Web Performance Optimierung: Die Infrasturktur</a> </li><li><a href="/wissens-hub/blog/web-performance-optimierung-serverseitige-software">Web Performance Optimierung: Serverseitige Software</a> </li><li><a href="/wissens-hub/blog/web-performance-optimierung-clients">Web Performance Optimierung: Clients</a> </li></ol>

Web Performance Optimierung ist das neue SEO

<p>Wie sinnvoll sich eine Performance Monitoring Lösung mit einem Profiler verbinden lässt, kann man ganz anschaulich an folgendem Beispiel feststellen.<br /> Bei meinem regelmäßigen Rundgang durch das bei uns in der Continuous Integration Umgebung mitlaufende <a href="http://www.appdynamics.com/free">AppDynamics</a>  fand ich einen interessanten HotSpot in iText.<br /> Mittels <a href="http://itextpdf.com/">iText</a> , einer früher komplett freien, mittlerweile teilweise kommerziellen Java Bibliothek, kann man sehr leicht PDFs auslesen. Dafür verwendet man einfach einen PDFReader:</p><div>

```java
PdfReader reader = new PdfReader(filename);
```

</div><p>Wirklich problemlos!<br /> Jedenfalls scheinbar. Den von mir gefundenen Hotspot kann man in folgendem Screenshot aus AppDynamics leicht selbst entdecken:<br /> <span><br /> [singlepic id=336 w=560 float=]</span></p><p>In diesem Fall gehen fast 20% der Gesamtzeit durch das Öffnen von 2 PDFs verloren. Meine Neugierde war geweckt. Was passiert dort?</p><p>Der Invocation Trace zeigt, dass im Constructor des PdfReader ein PRTokeniser erstellt wird, der ein RandomAccessFileOrArray erstellt. Dort wird dann entweder ein RandomAccessFile oder ein MappedRandomAccessFile erstellt. Letzteres liest über einen FileChannel die Datei direkt in den Arbeitsspeicher. Wenn das als langsam gefunden wurde, ist das vielleicht gar keine so gute Idee, dachte ich mir und begann meine Suche nach einer Alternative.</p><p>Also war ein kleines Microbenchmark für unsere Funktion, welche die in dem PDF enthaltenen Felder ausliest, geschrieben.<br /> Nach 3000 warmup Aufrufe folgten 10000 gemessene Aufrufe und ergaben 12,3 Sekunden auf meiner Maschine (Win 7 32bit, Java 1.6.20, -server).<br /> Um besser zu verstehen was passiert, ließ ich <a href="http://www.yourkit.com/">YourKit als Profiler</a>  mitlaufen. Dieser berichtete mir am Schluss:<br /> <img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cpATh8lpT6qfFaGlaoRN" alt title="YourKit sees iText issue" width="568" height="218" /></p><p>Die gesuchte Alternative zum Ausprobieren fand ich in einem Constructor, der ein RandomAccessFileOrArray entgegen nimmt, so dass ich dort eine andere Implementierung zum Dateiauslesen versuchen kann. Mit möglichst kleinen Schritten wollte ich mich dem Thema nähen und tat das was sonst der Code im „filename-Constructor“ tun würde:</p><div>

```java5
PdfReader reader = new PdfReader(new RandomAccessFileOrArray(filename), null);
```

</div><p>Doch zu meiner Überraschung stellte ich fest, dass nun die 10k Durchläufe weniger als die Hälfte der Zeit benötigten: 5,8 Sekunden. Und das obwohl ich doch nichts Anderes tat als vorher?<br /> Was war da passiert? Nun die Javadoc dieses Konstruktors des PdfReaders sagt es bereits:</p><div>

```java5
/**
* Reads and parses a pdf document. Contrary to the other constructors only the xref is read
* into memory. The reader is said to be working in "partial" mode as only parts of the pdf
* are read as needed.
**/
```

</div><p>Aha, interessant. Könnte für meinen Anwendungszeck des reinen Felderauslesens sogar erheblich performanter sein.</p><p>Bestätigt wird dies durch YourKit. Keine Spur mehr von den teuren Konstruktoren:<br /> <img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/kG01qymZSZqQkgiqfTnO" alt title="YourKit verifies changed performance profile" width="570" height="203" /></p><p>Ganz offensichtlich ist diese Variante wesentlich schneller. Zwar war dies nicht die Stelle nach der ich gesucht hatte, jedoch sollte man bei Performance auch gerne mal nach den tiefhängenden Früchten greifen. Zumal die Stelle an der die Korrektur erfolgt, oft nicht genau die im Profiler oder Monitor gesehene Stelle ist.<br /> Seit dieser Optimierung haben wir nie wieder eine langsame Codeausführung in unserem PDFServide entdecken können.</p><p>Ich denke dieses Beispiel zeigt ganz anschaulich wie man sinnvoll Performanceoptimierungen durchführen kann:</p><ol><li>Permanente Messung in Produktion und Test.</li><li>Analyse von Ausreißern und Anaomalien.</li><li>Evaluierung alternativer Implementierungen im Bereich der Anomalie mit einem Profiler.</li><li>Wenige einfache Änderungen mit großer Wirkung durchführen.</li><li>Weiter beobachten.</li></ol>

iText Performance Optimierung mit AppDynamics und YourKit

<p>Kürzlich sah ich bei einem unserer Kunden große Mengen erzeugten Garbages, welcher viele Garbage Collections verursachte. Zudem einen erheblichen Performanceverlust in Hibernate Code. Als ich mir die von AppDynamics aufgezeichneten langsamen Transaktionen ansah, wunderte mich dass der sonst üblicherweise langsame Datenbankzugriff sehr schnell war. Der langsame Teil war also in einem anderen Teil von Hibernate. Damit hatte ich nicht gerechnet, denn Hibernate ist doch eigentlich ein sehr gut optimiertes und viel eingesetztes Framework. Nach etwas eingehender Analyse konnte ich zum Glück Hibernate entlasten. Die aufgezeichneten Daten zeigten, dass die Zeit im <strong>org.hibernate.pretty.Printer</strong> verbraucht wurden. Aha! Das erklärt also die Unmengen von Garbage und den langsamen vermeintlichen Hibernate Code: Es hat debug sql/objekt Informationen erzeugt.<br /> Aber warum hat der Kunde dies nicht gesehen? Im Log waren tatsächlich keine Informationen vorhanden. Die Platten wären auch nach Minuten unter Produktionslast voll gewesen.</p><p><span></span></p><p>Die Antwort ist einfach, aber doch schockierend. Die folgende Log4J Konfiguration gibt bereits die ersten Hinweise.</p><p>Als Beispiel dient folgende bereits verräterisch benannte Klasse:</p><div>

```java5
package de.codecentric;
 
import org.apache.log4j.Logger;
 
public class PhantomLogger {
 
	private static final Logger LOG = Logger.getLogger(PhantomLogger.class);
 
	public static void main(String[] args) {
		System.out.println("Doing stuff");
		if (LOG.isDebugEnabled()) {
			LOG.debug(getDebugMessage());
		}
 
	}
 
	private static String getDebugMessage() {
		System.out.println("Expensive log generation here");
		return "Debug message";
	}
 
}
```

</div><p>Der Code läuft also mit Debug Level, welches in der Root-Kategorie definiert ist. Also liefert <strong>LOG.isDebugEnabled()</strong> true. Es passiert also die schwere Arbeit der Log-Erstellung. Strings werden erzeugt und Garbage produziert. Anschließend wird die Logmeldung an das arme Log4J weitergeleitet, welches wohl oder übel „debug“ für diese Kategorie akzeptieren musste. Log4J sucht nun nach einem Appender, findet einen und versucht die Logmeldung dorthin weiterzugeben. Der Appender schaut sie sich an, sagt „nein danke“ und schmeißt sie weg, da der Schwellwert auf Error gesetzt ist.</p><p>Was man daraus lernen kann: Versucht den Schwellwert der Appender als Regulator zu vermeiden. Oder stellt sicher, dass alle Kategorien maximal den detailliertesten Appender Level verwenden.</p>

Java Phantom Logging verursacht schwerwiegende Performanceprobleme

<p><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/PPw4Y9HRRlGEVegrymDD" alt width="319" height="81" />Mit der GearConf wächst eine wichtige deutschsprachige Konferenz für professionelle Softwareentwicklung weiter. Neben dem starken Fokus auf Werkzeuge, fanden auch die üblichen Themen im Zusammenhang mit Agilen Methoden ihren Platz. Ausgerichtet von Infaktum, fand dieses Jahr am 11. und 12. Oktober die Konferenz in dem freundlichen City Hostel in Düsseldorf, direkt am Rhein, statt.<br /> codecentric war mit einem Stand, sowie mit zwei Vorträgen von Andreas und mir vertreten.<br /> <span><br /> Andreas sprach über den effektiven Einsatz von JIRA. Da er mit technischen Problemchen zu kämpfen hatte, versprach er eine Reihe von Videos zu dem Thema. Ich habe sie schon gesehen und freue mich schon auf die Veröffentlichung hier im Blog.<br /> In meinem Vortrag sprach ich über Performance. Die Grundfrage die ich mir stellte war: Wie passt Optimierung auf bestmögliche Performance in den agilen Entwicklungsprozess. Meine Antwort: ganz einfach. Als Teil der Definition of Done.<br /> Die zweite Frage war: Mit welchem Werkzeug kann man dies erreichen. Meine Antwort: mit einem Werkzeug wie AppDynamics, welches wir auch die zwei Tage an unserem Stand zeigten.<br /> Aber ganz gleich welches Werkzeug man verwendet, man sollte effizient sein und sich um sämtliche Aspekte seiner Software, ganz im Sinne der Software Craftsmanship, kümmern.</span></p><p>Hier meine Vortragsfolien:</p><div><strong><a href="http://www.slideshare.net/fabianlange/agile-development-of-high-performance-applications">Agile Development of High Performance Applications</a> </strong><div>View more <a href="http://www.slideshare.net/">presentations</a>  from <a href="http://www.slideshare.net/fabianlange">Fabian Lange</a> .</div></div><p>Als Fazit bleibt: Gute Veranstaltung, viele gute Gespräche und Interesse an der Verbesserung der allgemeinen Softwareentwicklungsstandards.</p>

Messebericht von der GearConf – Gute Tools sind wichtig

<p>AppDynamics ist der aufgehende Stern am <strong>Application Performance Management</strong> Himmel.</p><p>Mirko beschreibt sehr schön in seinem Eintrag „<a href="/wissens-hub/blog/java-troubleshooting-in-produktion-vorstellung-von-appdynamics-lite">Java Troubleshooting in Produktion: Vorstellung von AppDynamics Lite</a> “ warum AppDynamics die richtigen Antworten auf fast alle Fragen in modernen verteilten Architekturen gibt.</p><p>Dabei ist ein wesentliches Versprechen von AppDynamics die <strong>Einfachheit</strong>. Einfache Installation, Einfacher Betrieb und schnelle Ergebnisse. Das klingt ungewöhnlich, und fast schon unglaubwürdig. Daß dies aber tatsächlich so ist zeigen folgende ungekürzte Screencasts.<br /> <span><br /> Die Installation von AppDynamics Lite, der kostenlosen Version der Monitoringlösung, ist wirklich kinderleicht. In diesem Screencast zeige ich die wenigen dafür notwendigen Schritte (Vollbildmodus ist unten rechts aktivierbar):</span></p><p></p><p>Direkt nach der Installation kann dann mit der Problemsuche begonnen werden. Im folgenden Screencast sind die Grundfunktionen erläutert und ich zeige wie man einer Problemursache auf den Grund gehen kann (Vollbildmodus ist unten rechts aktivierbar):<br /> </p><p>AppDynamics Lite ist sowohl für Entwicklungs als auch für Produktionsysteme geeignet. Es lässt sich in kürzester Zeit installieren, benötigt keine Konfiguration und liefert schon in dern ersten Minuten wertvolle Ergebnisse. Die kostenlose Lite Version ist auf <a href="http://www.appdynamics.com/free">appdynamics.com/free</a>  herunterladbar.</p>

Einfache Performanceanalyse mit AppDynamics Lite

<p>Für die Entwicklung von JSF basierten Webseiten ist das <a href="http://www.jboss.org/richfaces">Richfaces Framework</a>  ein gern genommenes Werkzeug. Es ist ein solides Framework mit umfassender Funktionalität, guter Dokumentation und einer Vielzahl von Komponenten. Mitgeliefert wird auch ein Ajax Framework namens <a href="http://en.wikipedia.org/wiki/Ajax4jsf">Ajax4JSF</a>  (auch a4j genannt). Deployt man nun eine solche Anwendung in das weite Internet in Produktion, so stellen viele Leute fest, dass der Speicherverbrauch stark ansteigt und in nicht mehr reagierenden Systemen oder OutOfMemoryError Abstürzen resultiert. Die Ursache hierfür ist ein Designproblem in JSF / A4J und kann leider nicht einfach behoben, jedoch aber umgangen werden. Beginnen wir aber zuerst mit einer Analyse des Problems in einer ansonsten gut funktionierenden Anwendung.<br /> <span></span></p><p><strong>Ursachenforschung</strong></p><p>Bei Speicherproblemen ist das Mittel der Wahl fast immer ein HeapDump um festzustellen was genau den Speicher belegt.<br /> Nachdem man nun einen solchen Dump in dem fabelhaften <a href="http://www.eclipse.org/mat/">Eclipse MAT</a>  geöffnet hat, so erhält man zum Beispiel ein Bild wie dieses:</p><p><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/PrUv6UURguqkBrkysica" alt width="538" height="441" /></p><p>Ouch. 1.8 GB der 2GB sind von Sessions belegt. Ich filtere dafür üblicherweise nach „StandardSession“ um die Apache Sessions einzeln zu sehen und mich leicht in diesen umsehen zu können. Besonderes Augenmerk lege ich darauf was relativ viel Speicher belegt (retained heap).</p><p><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/5KgIDVSSf2zc3ikVPReD" alt width="533" height="170" /></p><p>Schonwieder ouch… 10MB pro Session. Das kann nicht funktionieren. Nun es wäre möglich, daß ein unvorsichtiger Programmierer so viele Daten in die Session gelegt hat, doch dies stimmt nicht, wie wir leicht herausfinden können:</p><p><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/BeZWSJMkQZm4z1pkfYLA" alt width="590" height="435" /></p><p>Interessant! Fast der gesamte Speicher einer Session wird also von AjaxStateHolders belegt. Also, was genau macht dieses Ding eigentlich?</p><p><strong>Wie JSF und A4J arbeiten</strong></p><p>Ich beschreibe das Verhalten etwas vereinfachend. Bevor JSF das HTML für den Browser des Benutzers erzeugt, baut es eine interne Darstellung auf. Für jede Seite (oder View) wird diese interne Darstellung (auch Component Tree genannt) erstellt und durch den JSF lifecycle geschleust. Jegliche Benutzerinteraktionen werden dabei verarbeitet. Gibt es zum Beispiel eine Auswahlkomponente mit 3 Einträgen, so werden diese 3 Einträge gelesen und an den Component Tree gehängt. Die Komponente selber hält fest welcher Eintrag ausgewählt ist.</p><p>Nun wollen wir nicht, dass der Benutzer die Seite abschicken muss, um seine Auswahl zu tätigen, welches in einem Neuaufbau des Component Tree resultieren würde. Wir möchten dafür Ajax verwenden! Damit dies möglich wird, muss sich A4J an den Zustand der Komponenten erinnern wie er war als die Seite erzeugt wurde. Die Komponente und die 3 Einträge sind also bekannt und wenn der Benutzer eine auswählt, wird der Zustand der Komponente verändert und der Teil der Seite aktualisiert auf dem die Komponente angezeigt wird. Dies nennt man teilweise Seitendarstellung (partial page rendering).</p><p>Wie funktioniert nun dieses „Erinnern“? Ganz einfach: Es erzeugt einen AjaxStateHolder in der Benutzersession und hängt an diesen den Component Tree.</p><p><strong>Es wächst</strong></p><p>Ok, es ist also die aktuelle Seite und sein Component Tree. Das können zwar große Bäume sein, aber doch nur einer pro Benutzer? Dies ist leider nicht ganz richtig. A4J speichert mehr als nur einen View. Aber warum? Nun, Browser haben einen Knopf, der es erlaubt auf die vorherige Seite zurückzukehren. Klickt man diesen Knopf an, so wird aber nicht die Seite neu angefordert, sondern aus dem Browsercache dargestellt. Der Server weiß also garnicht, dass der Browser die letzte Seite anzeigt. Benutzt man dann Ajax Funktionalität, so muss der Server den Zustand kennen, der zu dem Zeitpunkt auf dem Server existiert hat. Woher soll der Server diesen Zustand noch kennen? Einfach: Dieser ist natürlich auch im AjaxStateHolder. Standardmäßig werden <strong>16 Views</strong> gespeichert. Und weil man während einer Sitzung an dem gleichen View mehrmals vorbeikommen kann, werden jeweils <strong>16 Varianten</strong> der Views erstellt.</p><p>Offensichtlich kann dies doch sehr viel werden. Und das pro User.</p><p><strong>Ein Lösungsansatz</strong></p><p>Leider gibt es keine Lösung. So funktioniert JSF und so funktioniert A4J.</p><p>Im Richfaces Bug Tracker gibt es auch ein Ticket zu dem Thema: RF-3878 – Session memory leak. Und die beste Antwort ist: Reduziere die Anzahl der gespeicherten Views.</p><div>

```xml
<context-param>
 <description></description>
 <param-name>com.sun.faces.numberOfViewsInSession</param-name>
 <param-value>1</param-value>
</context-param>
<context-param>
 <description></description>
 <param-name>com.sun.faces.numberOfLogicalViews</param-name>
 <param-value>1</param-value>
</context-param>
```

</div><p>Man verliert Teile der „Zurück“ Knopf Funktionalität, gewinnt aber Unmengen von Speicher.<br /> Die zweite Lösung ist die Component Trees drastisch zu reduzieren. Diese sind aber wahrscheinlich so groß weil es komplexe Strukturen und große Datenlisten gibt, welche sich sehr schwer reduzieren lassen können.</p>

Richfaces Session Speicherverbrauch – Analyse eines Memory-Leaks

<p>Es gibt viele Wege eine Reflection über einen vergangenen Sprint zu machen, und ab und zu probieren wir auch neue Ideen aus.<br /> So wurden wir in unserer letzten Reflection in die Rolle eines Künstlers versetzt und haben unsere Eindrücke des vergangenen Sprints in ein Bild gefasst.<br /> Was auf den ersten Blick merkwürdig erschien funktionierte aber überraschend gut. Das Bild stellt kompakt die wichtigsten Eindrücke zusammen und provoziert andere Emotionen also eine reine Liste über die zu verbessernden Dinge. Mal sehen ob wir dieses Mittel irgendwann wieder einsetzen.<br /> Als Beispiel möchte ich mein Bild zeigen und beschreiben. Die Bilder der Kollegen waren zwar auch interessant, jedoch möchte ich sie nicht ungefragt veröffentlichen. 🙂<br /> <span><br /> <img title="a_different_reflection" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/yLkbptXRSy2D7Re4hNhe" alt width="565" height="419" /></span></p><p>Man sieht den Langen Weg zum Ziel auf dem wir dem Ziel aber schon sehr nahe gekommen sind. Ich hoffe auf eine Belohnung für die super Sprints und wünsche mir deshalb einen Kuchen hinter der Ziellinie.<br /> Unter dem Weg sind sowohl unsere Architektur also auch der Zweck des Projekts zu erkennen (oder auch nicht). Die Architektur funktioniert gut, und der Kunde erkennt den Wert wo er früher noch Fragezeichen im Kopf hatte.<br /> Über dem Weg ist links oben unsere Teststabilität zu erkennen mit der ich offensichtlich nicht so glücklich bin. Maßnahmen wurden ergriffen um dies zu ändern.<br /> Auch unzufrieden bin ich mit unserem Burndown gewesen. Zwar passt es grundsätzlich, sollte aber unterhalb und nicht oberhalb der Linie liegen.<br /> Zufrieden war ich offensichtlich auch mit der Menge der umgesetzten Funktionalität und, dass diese echten Mehrwert in Form von Geld für unseren Kunden generiert.<br /> Abgerundet wird das Bild durch meinen Eindruck einer erneut super gelaufenen Produktpräsentation.</p><p>Was haltet Ihr von dieser Art der Reflection?</p>

Sprint Reflection mal anders

<p>Es passiert jedem Entwickler schon mal, daß man Hinweise aus der JavaDoc nicht besonders Ernst nimmt, oder gar überliest. Insbesondere wenn die angesprochenen Probleme lokal nicht (oder scheinbar nicht) auftreten.</p><p>Zum Beispiel aus dem<em> java.text.SimpleDateFormat</em>:</p><div>

```plain
 * Date formats are not synchronized.
 * It is recommended to create separate format instances for each thread.
 * If multiple threads access a format concurrently, it must be synchronized
 * externally.
```

</div><p>Vielleicht ist die Warnung auch nicht deutlich genug, dadurch daß dort steht: „It is recommended“.<br /> Deshalb sieht man leider häufig folgende Zuweisung welche zu Nebenläufigkeitsproblemen führen kann</p><div>

```java5
private static final SimpleDataFormat DATE_FORMAT = new SimpleDateFormat("yyyy.MM.dd");
```

</div><p>Schlimmer ist es hingegen bei <em>System.gc()</em>.<br /> <span><br /> Dort findet sich keine Warnung im JavaDoc:</span></p><div>

```plain
* Calling the gc method suggests that the Java Virtual
* Machine expend effort toward recycling unused objects in order to
* make the memory they currently occupy available for quick reuse.
* When control returns from the method call, the Java Virtual
* Machine has made a best effort to reclaim space from all discarded
* objects.
```

</div><p>Klingt sogar garnicht so schlecht. Jedoch sollte „suggests“ und „best effort“ einen stutzig machen. Falls man auf die Idee kommt System.gc() zu verwenden prüft man vielleicht was im großen weiten Internet dazu gesagt wird, in der Hoffnung auf Erklärungen zu stoßen was tatsächlich passiert. So finden sich auf <a href="http://stackoverflow.com/questions/2414105/why-is-it-a-bad-practice-to-call-system-gc">Stackoverflow gute Ausführungen</a> . Was es genau tut weiß aber keiner so genau, weshalb diese Anweisung so riskant ist.</p><p>Ich finde aber, daß ein Bild mehr sagt als viele Worte:<br /> <img title="avoid_system_gc" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/kJJPaZ0jQXK8imfjXk0V" alt width="594" height="363" /></p><p>Wir sehen ein relativ großzügig dimensioniertes System eines unserer Kunden mit 14 GB Heap. Diesem Kunden haben wir geholfen den Speicherverbrauch seiner Anwendung zu reduzieren, jedoch gibt es immer noch Pausenzeiten. Der oben abgebildete Graph stammt aus dem Garbage Collection Log und zeigt die Ursache für die Pausen. Die blaue Kurve unten zeigt Garbage Collection. Doch warum gibt es 13 Garbage Collection Spitzen mit bis zu 35 Sekunden, während die zahlreichen anderen Garbage Collections sehr sehr kurz sind?<br /> Die Antwort liegt in der Ursache für diese 13 Garbage Collections. Sie wurde alle durch ein <em>System.gc()</em> aufgerufen.</p><p>Der Aufruf von <em>System.gc()</em> unterbindet damit effektiv die Optimierungsmöglichkeiten der Garbage Collection und schlägt sich auf diesem System in relativ langen Pausenzeiten nieder.</p><blockquote><p>Anmerkung: Dieses System lief auf einer Sun 1.6.0.18 64 bit HotSpot Server VM. Als GC sind -XX:+UseConcMarkSweepGC und -XX:+UseParNewGC konfiguriert. System.gc() liefert keine deterministischen Ergebnisse und muss sich nicht zwangsläufig wie hier beschrieben verhalten. Allerdings <a href="http://stackoverflow.com/questions/2414105/why-is-it-a-bad-practice-to-call-system-gc/2415234#2415234">beobachten auch andere</a> , daß bei CMS und System.gc() auf jeden Fall ein Full GC durchgeführt wird.</p></blockquote><p>Sollte man im eigenen Code keine <em>System.gc()</em> Aufrufe finden, so verstecken sich diese in genutzten Bibliotheken. Unterbinden kann man sie aber über das Server Argument „-XX:+DisableExplicitGC“. Dieses Argument wird von SUN/Oracle empfohlen.</p>

System.gc() Aufrufe können schwere Folgen haben

<p>Wir bei codecentric haben hunderte von automatischen Builds die täglich laufen und.. manchmal auch fehlschlagen. Doch soll es hier nicht um faule Ausreden wie „ach das war doch nur ne kleine Änderung das sollte nicht schiefgehen“ gehen, sondern um die Fälle in denen der Build bricht weil.. nunja.. man weiß es halt nicht so richtig.</p><p>Klar sagt man schnell gern: Oh das muss kosmische Strahlung sein. Ich werfe den Build nochmal an. Aber wir wissen alle daß das nicht stimmen kann. Um wirklich effizient ein CI System nutzen zu können im Folgenden eine Liste von Ursachen von solch spontanen Buildfehlschlägen und wie man sie beheben kann.<br /> <span></span></p><ul><li>Ein Test führt <strong>Zeitberechnung</strong> durch, und sowohl im Testcode als auch im Produktionscode wird die Zeit genommen. Während das fast immer ohne erkennbare Unterschiede funktioniert, kann es ab und zu Abweichungen geben. Die Meldungen sehen dann merkwürdigerweise so aus: Time was 23:30:00 but expected 23:30:00 (die Milli- und Mikrosekunden werden von den üblichen toString Methoden nicht angezeigt.)</li><li>Code, Testcode oder das CI lassen nach Ausführungen Dateien liegen. Oft handelt es sich um Logdateien, manchmal Ergebnisse von Tests. Dies kann Ergebnisse verfälschen, weshalb unbedingt diese Dateien zu entfernen sind. Auch sollte unbedingt <strong>Festplatten Monitoring</strong> eingesetzt werden, da auf Buildservern die Platten schnell sehr voll werden (Hudson bietet Optionen zur Überwachung und zum Aufräumen)</li><li>Benutzer die sich auf dem CI Server einloggen können so versehentlich <strong>Ressourcen sperren</strong>, z.B. Dateien durch Öffnen, oder Ports durch manuelles Serverstarten. Oder sonstwas, womit keiner gerechnet hat. Deshalb sollte es auf Buildservern keine Benutzerlogins geben. Sämtliche Analysen sollten wenn überhaupt nur lesend erfolgen. Dennoch sollte den Entwicklern bewusst sein, daß je nach Tool selbst lesender Zugriff schon Schreibzugriff verhindert.</li><li>Es handelt sich nicht zwingend um einen Bug im Code oder Test wenn das Systemdatum den Ersten Januar 1970 anzeigt. Natürlich könnte es ein Fehler sein, aber eventuell geht die Uhr des Buildservers auch einfach falsch. Buildserver sollten immer die <strong>aktuelle Uhrzeit verwenden</strong>. Dies kann ganz einfach mit einem ntp daemon sichergestellt werden. Falls ein Test eine bestimmte Uhrzeit testen möchte, so sollte nicht die Systemzeit verändert werden, sondern stattdessen der Code so umgebaut werden, daß er einen TimeProvider verwendet welcher im Test die gewünschte Uhrzeit liefert, sich ansonsten wie die normale Systemzeit verhält.</li><li>Falls es doch schmutziger Tricks bedarf um gewisse Teile des Codes zu testen, so ist es in der Regel sicherer die <strong>Testausführung zu forken</strong>, dadurch können dann selbst umgesetzte Systemvariablen keinen Einfluss auf die Tests in anderen JVMs haben. Code Coverage Tools und andere Bytecodemanipulierer zählen mitunter auch als Hack. Geforkte Ausführung ist oft sicherer.</li><li>Falls Ihr mehrere Buildserver habt, stellt sicher, daß diese sich so ähnlich wie nur möglich sind. Nur wenn man es sich wirklich leisten kann und will sollte man mehrere verschiedene Server mit fest <strong>definierten</strong> Unterschieden als Farm aufsetzen. So kann dann auf Systemspezifika getestet werden. Allerdings sollte es keine überraschenden Unterschiede geben.</li><li>Man sollte in Erwägung ziehen das zu testende System für die nächtlichen Integrationstest (automatisch) <strong>komplett neu zu installieren</strong>. Diese Testserver werden mit der Zeit instabil, insbesondere dann wenn viele explorative Tests und ad-hoc Demonstrationen auf dem System gemacht werden. Komplette Neuinstallation klingt abschreckend, ist aber oft einfacher als gedacht. Allerdings dauert die Installation jede Nacht dann etwas mehr Zeit.</li><li>Wenn man Software für automatische Tests deployed sollte man unbedingt zuerst den Server stoppen, die neue Software an die richtige Stelle kopieren und dann den Server starten. Jegliche Art von „<strong>hot deployment</strong>“ ist leider nicht stabil genug um verlässlichen Ergebnisse zu liefern.</li><li>Nach jeglicher Art von <strong>Konfigurationsänderung</strong> oder Veränderungen an der erweiterten Testinfrastruktur sollte ein manueller Testlauf gestartet werden. Tut man dies nicht vermischt sich diese Änderung mit dem nächsten Entwicklercommit und dieser sucht dann vergebens in seinem Code nach der Änderung die den Test brach, obwohl es sich um die Konfiguration handelt.</li><li>Falls sich Tests aufhängen oder blockieren, insbesondere wenn mehrere Tests zur gleichen Zeit (nicht zwingend in dem gleichen Prozess) laufen, so sollte man sich darüber freuen, <strong>einen Heap und Threaddump</strong> machen und erst dann die JVM neustarten. Es kann sein, daß die Tests zufällig eines dieser unheimlich schwer zu findenden <strong>Nebenläufigkeitsproblemen</strong> gefunden haben. Man sollte dafür dankbar sein, da man den Fehler sonst nie gefunden hätte. Leider wird zu oft einfach nur neugestartet.</li></ul><p>Natürlich ist es möglich, daß weiterhin der Build bricht ohne daß die Software Fehler enthält. Aber genau dies verschwendet viel Zeit auf der Suche nach Phantomfehlern. Deshalb muss man die Schwachstellen seines Builds kennen und daran arbeiten diese zu beheben.</p><p>Wir hatten zum Beispiel ein Problem mit einer unserer Integrationtest Suiten. Die Tests verbinden sich mit einem externen Dienst, welcher manchmal nicht antwortet oder nur hängt. Bis vor kurzem brach dies unseren Build. Das Ergebnis war, daß jeder Entwickler sich den roten Build ansah, die Logs studierte und schlussendlich zur Feststellung gelangt, daß mal wieder der Dienst nicht verfügbar war. Nach einer Diskussion über dieses Problem beschlossen wir diese Zeitverschwendung nicht mehr zu machen. Also fügten wir eine kleine Mechanik in die Tests ein, welche die Timeouts erkennt und den Build nicht brechen lässt. Dafür markiert es den Test mit dem nichtkritischem Tag „timeouted“. Natürlich können wir keine Aussage über den Test treffen, aber er ist ebenso wenig Grün wie Rot. Da aber Rot das Anzeichen für die Entwickler ist tätig zu werden konnten wir ihn nicht Rot machen. Leider führt dies zu der Einschränkung, daß wirkliche Grüne Builds keine Tests mit dem Tag „timeouted“ haben dürfen. Im RobotFramework kann man <a href="http://robotframework.org/robotframework/2.9b2/RobotFrameworkUserGuide.html">einen dritten Zustand für „nichtkritische Fehlschläge“</a>  definieren. Vielleicht ist dies ja auch eine Option für Euch?</p><p>Die wichtigste Botschaft ist: <strong>Wenn ein gebrochener Build nicht durch Test- oder Produktionscode verursacht wurde, so muss man unbedingt die Ursache finden und beheben</strong>. Man kann nicht einfach auf kosmische Strahlen verweisen, da sonst irgendwann jeder einfach nur „kosmische Strahlen“ sagt und der Build keine Aussagekraft mehr hat. <strong>Ein roter Build sollte immer bedeuten: Leute macht was!</strong></p>

Die Besten Ausreden warum der Build bricht

<p>Dieser Beitrag ist etwas „off-topic“. Kürzlich ist unser Blog von qTransate auf WPML für das zweisprachige Bloggen migriert worden. Hauptgrund waren die erheblich besseren Updates und eine sauberere Trennung von den verschiedenen Sprachen.<br /> Ein Feature hat uns dabei aber gefehlt: Unter beiden Postings in Englisch und Deutsch wollen wir alle Kommentare anzeigen, nicht nur die Kommentare in der jeweiligen Sprache. WPML erlaubt dies von sich aus leider nicht, jedoch konnten wir dies erstaunlich einfach selbst programmieren.<br /> <span></span></p><p>Da wir an Open Source glauben hier der Quelltext unseres Kommentar-Merge Plugins. Wenn man wollte könnte man die Sprachen noch parametrisieren, aber für unsere Zwecke war dies absolut ausreichend.</p><p><a href="http://wordpress.org/extend/plugins/wpml-comment-merging/">WPML comment merging Plugin auf wordpress.org</a> </p><div>

```php
<?php
/*
Plugin Name: WPML comment merging
Plugin URI: http://wordpress.org/extend/plugins/wpml-comment-merging/
Description: This plugin merges comments from all translations of the posts and pages, so that they all are displayed on each other. Comments are internally still attached to the post or page they were made on.
Version: 1.3
Author: Fabian Lange
Author URI: http://blog.codecentric.de/en/2010/06/wordpress-wpml-comments-filter-plugin/
License: MIT
*/
 
function sort_merged_comments($a, $b) { 
	return $a->comment_ID - $b->comment_ID;
}
 
function merge_comments($comments, $post_ID) {
	// get all the languages for which this post exists
	$languages = icl_get_languages('skip_missing=1');
	$type = is_page($post_ID) ? 'page' : 'post';
	foreach($languages as $l) {
		// in $comments are already the comments from the current language
		if(!$l['active']) {
			$otherID = icl_object_id($post_ID, $type, false, $l['language_code']);
			$othercomments = get_comments( array('post_id' => $otherID, 'status' => 'approve', 'order' => 'ASC') );
			$comments = array_merge($comments, $othercomments);
		}
	}
	if ($languages) {
		// if we merged some comments in we need to reestablish an order
		usort($comments, 'sort_merged_comments');
	}
	return $comments;
}
 
function merge_comment_count($count, $post_ID) {
	// get all the languages for which this post exists
	$languages = icl_get_languages('skip_missing=1');
	$type = is_page($post_ID) ? 'page' : 'post';
 
	foreach($languages as $l) {
		// in $count is already the count from the current language
		if(!$l['active']) {
			$otherID = icl_object_id($post_ID, $type, false, $l['language_code']);
			if($otherID) {
				// cannot use call_user_func due to php regressions
				if ($type == 'page') {
					$otherpost = get_page($otherID);
				} else {
					$otherpost = get_post($otherID);
				}
				if ($otherpost) {
					// increment comment count using translation post comment count.
					$count = $count + $otherpost->comment_count;
				}
			}
		}
	}
	return $count;
}
 
add_filter('comments_array', 'merge_comments', 100, 2);
add_filter('get_comments_number', 'merge_comment_count', 100, 2);
```

</div>

WordPress WPML Kommentar Filter Plugin

<p>Wenn man Services in Mule konfiguriert wird man einige benutzen, welche externe Services aufrufen. Allerdings hängt es von der Umgebung ab, ob und für welche Hosts ein Proxy Server verwendet werden muss. Um die Rekonfiguration von Mule je Umgebung zu vermeiden benutzen wir einen automatischen Proxy Connector. Da ich den ganz nett finde möchte ich Ihn Euch gerne näher bringen. Vielleicht ist er auch für Euch nutzbar<br /> <span></span></p><div>

```xml
<https:connector name="autoProxy">
  <spring:property name="proxyHostname">
    <spring:bean class="org.springframework.jndi.JndiObjectFactoryBean">
      <spring:property name="jndiName" value="/jndi/config/proxyHost" />
      <spring:property name="defaultObject" value="" />
    </spring:bean>
  </spring:property>
  <spring:property name="proxyPort">
    <spring:bean class="org.springframework.jndi.JndiObjectFactoryBean">
      <spring:property name="jndiName" value="/jndi/config/proxyPort" />
      <spring:property name="defaultObject" value="0" />
    </spring:bean>
  </spring:property>
  <service-overrides dispatcherFactory="de.codecentric.mule.HttpAutoProxyMessageDispatcherFactory" />
  <https:tls-key-store path="/mule.keystore" keyPassword="changeit" storePassword="changeit"/>
  <https:tls-server path="/mule.keystore" storePassword="changeit"/>
</https:connector>
```

</div><p>Wie man leicht sieht verwenden wir eine eigene MessageDispatcherFactory, welche die Parameter ProxyHost und ProxyPort aus JNDI ausliest und einen SSL Keystore mit dem berühmten changeit Passwort übergibt.<br /> Diesen Connector verwendet man dann einfach über connector-ref</p><div>

```xml
  <outbound-endpoint address="https://external.service/endpoint" synchronous="true" connector-ref="autoProxy">
```

</div><p>Die Factory selbst ist supereinfach:</p><div>

```java5
public class HttpAutoProxyMessageDispatcherFactory
  extends AbstractMessageDispatcherFactory {
  public MessageDispatcher create(OutboundEndpoint endpoint) throws MuleException {
    return new HttpAutoProxyMessageDispatcher(endpoint);
  }
}
```

</div><p>Die Implementierung des HttpAutoProxyMessageDispatcher ist auch einfach, enthält hier aber zwei hardcodierte Hosts welche nicht geproxied werden sollen. Hier kann man gerne noch Verbesserungen einfließen lassen.</p><div>

```java5
public class HttpAutoProxyMessageDispatcher
  extends HttpClientMessageDispatcher {
 
  private final boolean hasProxy;
  private final String proxyHost;
  private final int proxyPort;
 
  public HttpAutoProxyMessageDispatcher(OutboundEndpoint endpoint) {
    super(endpoint);
    this.proxyHost = ((HttpConnector) endpoint.getConnector()).getProxyHostname();
    this.proxyPort = ((HttpConnector) endpoint.getConnector()).getProxyPort();
    this.hasProxy = StringUtils.isNotBlank(proxyHost);
  }
 
  @Override
  protected HostConfiguration getHostConfig(URI uri) throws URISyntaxException {
    String host = uri.getHost();
    HostConfiguration config = new HostConfiguration();
    config.setHost(host, uri.getPort(), Protocol.getProtocol(uri.getScheme().toLowerCase()));
    if (hasProxy && !isLocalhost(host)) {
      config.setProxy(proxyHost, proxyPort);
    }
    return config;
  }
 
  private boolean isLocalhost(String host) {
    return "localhost".equals(host) || "127.0.0.1".equals(host);
  }
 
}
```

</div><p>Setzt man die Konfiguration so um, muss lediglich im JNDI jeder Umgebung der Proxy eingestellt sein. Mule wird dann automatisch den Proxy verwenden falls gesetzt und die Konfiguration selbst kann unangetastet bleiben.</p><h3>Update: Mule 3.2</h3><p>Kürzlich erschienene Versionen von Mule erleichtern das Implementieren des HttpAutoProxyMessageDispatchers:</p><div>

```java5
public class HttpAutoProxyMessageDispatcher extends
    HttpClientMessageDispatcher implements MessageDispatcher {
 
  public HttpAutoProxyMessageDispatcher(OutboundEndpoint endpoint) {
    super(endpoint);
  }
 
  @Override
  protected HostConfiguration getHostConfig(URI uri) throws Exception {
    Protocol protocol = Protocol.getProtocol(uri.getScheme().toLowerCase());
    String host = uri.getHost();
    int port = uri.getPort();
    HostConfiguration config = new HostConfiguration();
    config.setHost(host, port, protocol);
    if (!isLocalhost(host) && StringUtils.isNotBlank(connector.getProxyHostname())) {
      config.setProxy(connector.getProxyHostname(), connector.getProxyPort());
    }
    return config;
  }
 
  private boolean isLocalhost(String host) {
    return "localhost".equals(host) || "127.0.0.1".equals(host); 
  }
}
```

</div>

Automatische Proxywahl für Mule ESB Webservices

<p>Ich möchte Euch in diesem Beitrag zeigen, wie wir bei codecentric in unseren Projekten den Mule ESB und Apache CXF einsetzen. Ich möchte zeigen wie einfach das Erstellen von Webservices ist und was man tun kann um das doch recht langsame Standardverhalten zu verbessern.</p><p>Sollte man überhaupt einen Webservice einsetzen? Nun eine gute Frage, und wahrscheinlich sogar am relevantesten für die Performance. Webservices eignen sich hervorragend um Interfaces und Services nach außen anzubieten, oder wenn man intern auf Grund von Firewallbeschränkungen oder anderen Programmiersprachen andere Protokolle wie RMI nicht verwenden kann. Da Ihr euch mit Webservices herumschlagt, gehe ich einfach mal davon aus daß dieser Punkt nicht zur Debatte steht.<br /> <span><br /> Wir benutzen den Mule Enterprise Service Bus in einigen Projekten, aber damit möchte ich nicht sagen, daß er für alle geeignet ist. Dokumentation gibt es nur nach Anmeldung und die Releasepolitik ist durchaus fragwürdig. Ich bin nicht sonderlich glücklich damit, aber er funktioniert doch ganz gut sobald mal ihn einigermaßen begriffen hat und <a href="http://www.mulesoft.org/jira/browse/MULE-4095">an einigen</a>  <a href="http://www.mulesoft.org/jira/browse/MULE-4634">Stellen</a>  nachgebessert hat. Um Webservices zu erzeugen kann man diese entweder von Hand schreiben, oder <a href="http://ws.apache.org/axis/">Apache Axis</a>  oder <a href="http://cxf.apache.org/">Apache CXF</a>  verwenden. Ich bevorzuge CXF, da ich dessen API eleganter empfinde, und der generierte Code sauberer ist. Außerdem ist das Projekt noch lebendig und wird sogar von Mule Entwicklern betreut. CXF ist Standard bei Mule und wird von uns in Verbindung mit Spring Pojo Components angewendet.</span></p><p>Nun schauen wir uns mal unser Beispiel Webservice Interface an. Um die Sache etwas interessanter zu gestalten nutzen wir einen nicht trivialen Service der Domänenobjekte als Parameter erwartet und zurückliefert. Ein Wort der Warnung vorweg: Große Objektbäume erzeugen viel XML 🙂</p><div>

```java5
@WebService
public interface RecommendationService {
	@WebMethod
	public Products recommendProducts(
		@WebParam(name="user")
		User user,
		@WebParam(name="genre")
		Genre genre
	);
}
```

</div><p>Natürlich gibt es auch eine Implementierung für diesen Service, welcher im nächsten Schritt in Mule eingebunden wird.<br /> Zu aller erst müssen wir Mule dazu bewegen überhaupt Webservices zu akzeptieren. Da wir Mule in der Regel im WAR deployen benutzen wir den Servlet Connector, allerdings kann auch der Jetty Connector beim eigenständigen Einsatz genutzt werden:</p><div>

```xml
<servlet:connector name="servletConnector" 
                   servletUrl="http://localhost:8080/mule/services/recommendation?wsdl" />
```

</div><p>Als Nächstes folgt die Webservicekonfiguration des Services:</p><div>

```xml
<model name="recommendationServiceModel">
	<service name="recommendation">
		<inbound>
			<cxf:inbound-endpoint address="servlet://recommendation" synchronous="true" />
		</inbound>
		<component>
			<spring-object bean="RecommendationService" />
		</component>
	</service>
</model>
```

</div><p>Und natürlich auch der Service selbst:</p><div>

```xml
<spring:bean id="RecommendationService"
             class="de.codecentric.RecommendationServiceImpl" />
```

</div><p>Man kann die Konfigurationen in eine Datei quetschen, allerdings empfehle ich diese aufzuteilen. Entweder nach Typ (service, component, mule) oder eine Konfiguration pro Service.<br /> Das war es auch schon mit der gesamten Mule Konfiguration.<br /> Nun könnten wir den Service schon testen, wenn wir einen einfachen Weg hätten die Parameter zu übergeben. Bis dahin begnügen wir uns mit dem Aufruf der WSDL.</p><div>

```bash
http://localhost:8080/mule/services/recommendation?wsdl
```

</div><p>Beachtet auch eventuelle s welche auf einen ausgelagerten Teil der WSDL verweisen.</p><p>Einen Java Client für den Zugriff auf den Service zu erstellen ist ganz einfach mit Hilfe des wsdl2java Kommandos von CXF:</p><div>

```bash
wsdl2java -client -d src/main/java -p de.codecentric.client 
  http://localhost:8080/mule/services/recommendation?wsdl
```

</div><p>Wären wir nun ein externer Benutzer, so könnten und müssten wir mit den generierten Klassen arbeiten. Allerdings möchten wir insbesondere bei inkrementeller Entwicklung und den damit verbundenen häufigeren Änderungen an den Domänenobjekten diese nicht immer neu generieren. Außerdem bieten Domänenobjekte sinnvolle Businessmethoden welche nicht generiert werden, da sie nicht Teil des Webservices sind. Da CXF echt clever ist, können wir einfach folgende generierten Klassen löschen:</p><ul><li>Genre</li><li>ObjectFactory</li><li>package-info</li><li>Products</li><li>User</li></ul><p>Nun lassen sich die fehlenden Imports einfach durch die Domänenobjekte ersetzen. Außerdem muss die Referenz auf <strong>@XmlSeeAlso({ObjectFactory.class})</strong> entfernt werden.</p><p>Danach sollten nur noch Interface und Implementierung des Services, sowie zwei Wrapper Objekte für Request und Response übrig bleiben. Führt man nun den Dummy Client mit CXF auf dem Classpath aus, so sollte der Webservice aufgerufen werden.</p><p>Intern löst der Aufruf von</p><div>

```java5
RecommendationServiceImplService ss = new RecommendationServiceImplService(wsdlURL, SERVICE_NAME);
RecommendationService port = ss.getRecommendationServiceImplPort();
```

</div><p>die Erstellung eines dynamischen Proxys mittels Reflection von der WSDL des Servers aus.</p><p>Man könnte jetzt aufhören. Wir haben erfolgreich einen Client erstellt der Domänenobjekte verwendet. Aber die Performance ist echt nicht gut.</p><p>Die WSDL wird vom Server bezogen und in eine Proxy Klasse übersetzt. Natürlich könnte man die WSDL importieren, doch dies müsste jedes mal gemacht werden wenn sich die Objekte verändern. Externe Benutzer müssen das tun, sind aber seltener Änderungen unterworfen. Trotzdem werden bei jedem Aufruf weiterhin Proxy Klassen generiert. Und das ist noch langsam genug. Ich habe die Laufzeit des gesamten Stacks gemessen und die Proxy Erzeugung übertrifft den Rest um Längen.</p><p>Was also tun? Um die Situation zu verbessern benutzen wir einen pool, mit Hilfe von commons pool GenericObjectPool.</p><div>

```java5
private final GenericObjectPool recommendationServicePool;
 
RecommendationServiceFactory recommendationServiceFactory = new RecommendationServiceFactory();
recommendationServicePool = new GenericObjectPool(recommendationServiceFactory, new Config());
```

</div><p>Der Pool benötigt also eine Factory um Instanzen zu erzeugen und eine Konfiguration. Die Konfiguration kann noch angepasst werden, aber die Defaults sind ausreichend gut. Die Implementierung der Factory sieht so aus:</p><div>

```java5
public class RecommendationServiceFactory implements PoolableObjectFactory  {
public Object makeObject() throws Exception {
  RecommendationServiceImplService service = new RecommendationServiceImplService();
  RecommendationService port = service.getRecommendationServiceImplPort();
  return port;
}
public boolean validateObject(Object arg0) {
  // consider all controllers valid objects
  return true;
}
public void destroyObject(Object arg0) throws Exception {}
public void activateObject(Object arg0) throws Exception {}
public void passivateObject(Object arg0) throws Exception {}
}
```

</div><p>Nun können wir unseren Service wie folgt aufrufen:</p><div>

```java5
RecommendationService port = (RecommendationService) recommendationServicePool.borrowObject();
try {
  Products products = port.recommendProducts(user, genre);
} finally {
  recommendationServicePool.returnObject(port);
}
```

</div><p>Auf keinen Fall sollte man vergessen geliehene Objekte wieder in den Pool zurückzugeben. Anders als in einer Bücherei bekommt man keine Mahnung 🙂</p><p><strong>Zusammenfassung</strong><br /> Wir benutzen Mule ESB um Spring Komponenten basierte Webservices, welche Domänenobjekte verwenden, zu konfigurieren und zu deployen. Die Webservices werden mit Hilfe von Apace CXF bereitgestellt und in einem damit generiertem Client angesprochen. Durch die Benutzung eines Pools verhindern wir die unnötige Erzeugung von Proxyklassen.</p><p>Ich erwähnte bereits, daß der Pool eine erhebliche Verbesserung brachte. Dennoch sollte man nie einem Blogbeitrag trauen und immer selber messen. Dies ist sogar ganz einfach möglich indem man die Zeit des Aufrufs ohne Pool und des mehrfachen Aufrufs mit pool misst. Der erste Aufruf im Pool ist auch langsam, da das Objekt erzeugt wird. Auf meiner Maschine hat der ganze Stack 360ms benötigt. Alle folgenden Aufrufe benötigten 4-6ms. Das ist fast eine Verbesserung um den Faktor 100. Für die komplexen Aufgaben die der ESB ausführt sind 4ms sogar recht schnell. Muss doch ein HTTP request gemacht und innerhalb eines WARs im JBoss empfangen werden, die Daten ein und wieder ausgepackt werden, herausgefunden werden welcher Service mit welcher Methode aufgerufen werden soll etc.</p><p>Auf jeden Fall sollte man nicht zu vorschnell Webservices verurteilen. Mit den richtigen Hilfsmittel kann man sie relativ gut benutzen, und sie können auch recht schnell sein.</p>

Einfache und Schnelle Webservices mit Mule ESB und Apache CXF

<p>Letzte Woche durfte ich zur Weiterentwicklung meiner Java Fertigkeiten den <a href="http://www.javaspecialists.eu/courses/master.jsp">Java Specialists Master course</a>  von Heinz Kabutz besuchen. Java Champion Heinz, ist ein hervorragender Trainer, der es geschafft hat Anekdoten, harte Fakten und tiefe Javakenntnisse zusammen mit herausfordernden Übungen zu einem großartigem Kurs zusammenzustellen. Der Umfang betraf das gesamte Spektrum von Java, jedoch lag der Fokus auf den kleinen Gemeinheiten die man entweder nicht kennt oder nicht nutzt. Auszüge des Kursmaterials veröffentlichte er bereits in <a href="http://www.javaspecialists.eu/archive/archive.jsp">seinem Newsletter</a> , welcher eine große Leserschaft weltweit besitzt.</p><p>Im folgenden möchte ich meine Eindrücke der 4 Tage schildern…<br /> <span><br /> <strong>Tag 1</strong></span></p><p>Direkt mit einem komplexen Thema ging es Dienstag früh los: Thread, wie funktionieren sie und was gibt es zu beachten. Wir haben eine ThreadGroup erstellt und zu einem eigenem Thread pool ausgebaut. ThreadGroup ist nun leider nicht die allerschönste Klasse. Heinz verglich sie mit einer Art Kinderzeichnung aus den frühen Java Jahren. besonders einfach zu benutzen fand ich die <a href="http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/package-summary.html">java.util.concurrent Locks</a> , welchen ich bisher weniger Beachtung schenkte. Endlich sind die Zeiten von <em>synchronized()</em> vorbei. Noch vor dem Mittagessen erläuterte Heinz uns seine Gesetze über Nebenläufigkeit, welche er bereits in verkürzter Form auf unserem meet the experts – performance event präsentierte. Dabei stolperten wir über folgenden code:</p><div>

```java5
private boolean running = true;
public void dojob() {
  while(running) {
    // do something useful
 }
}
public void shutdown() {
  running = false;
}
```

</div><p>Führt man diesen auf einer Server VM aus (java -server), so kann es passieren daß der Code sich nicht mehr beendet, da die HotSpot engine den Code optimiert, da running scheinbar immer true ist. Um dies zu vermeiden muss es <em>volatile</em> gemacht werden. Da ich nach Debugging fragte versuchten wir in der Schleife anzuhalten und sieh da, der Debugger zeigte und: <em>running = false</em>. Dies hielt aber den laufenden Code nicht davon ab weiterzulaufen, da der Debugger zwar den korrekten Wert sieht, der laufende Code aber nicht. Doch es wird noch interessanter:</p><div>

```java5
public void doJob() {
  boolean myRunning = running;
  while(running){
    // do something useful
    myRunning = running;
  }
}
```

</div><p>Nun zeigt uns der Debugger dies:</p><div>

```java5
running = false; myrunning = true;
```

</div><p>trotzdem läuft der code weiter. Jedoch nur so lange bis wir mittels F7 die Zeile ausführen ließen. Diese Art von Problemen kann ein Alptraum werden, deshalb ist es wichtig zu wissen was man korrekterweise tun muss.</p><p>Auch wissenswert war es zu erfahren, daß</p><div>

```java5
if (Thread.interrupted()) {
  throw new InterruptedException()
}
```

</div><p>der erste Code in jeder Methode sein sollte welche eine InterruptedException deklariert.</p><p>Wir haben außerdem den <a href="http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/CompletionService.html">CompletionService</a>  kennengelernt, welches nach einem interessanten Interface für die Bearbeitung von asynchronen Aufgaben aussieht. Wer braucht da noch closures? 🙂</p><p><strong>Tag 2</strong></p><p>Wir begannen Tag 2 mit Java new (yet another new?) IO, welches recht viele Features mitbringt, aber irgendwie doch selten verwendet wird. Möglicherweise liegt das an der teilweise sperrigen Benutzung der Interfaces. Man sollte doch vielleicht einfache Beispiele probieren bevor man sich an einem asynchronen nichtblockierendem Server versucht (was man aber durchaus nach Besuch des Kurses kann 🙂 ).</p><div>

```java5
FileChannel fc = new RandomAccessFile("test.txt", "r").getChannel();
MappedByteBuffer buffer = fc.map(FileChannel.MapMode.READ_ONLY, 0, fc.size());
```

</div><p>Die zweite Tageshälfte verbrachten wir in den Untiefen der Java Speicherverwaltung. Natürlich ist die Praxistauglichkeit des Themas reduziert, doch das Verständnis ist essentiell um Probleme zu verstehen und zu lösen. Wir sahen uns caching und pooling an und betrachteten warum dies Objekte leaken oder herumlungern lassen kann. Das Thema erinnerte mich an einen alten <a href="/wissens-hub/blog/jsp-tag-pooling-memory-leaks">post über tag pooling</a>  in Servlet Containern. Ich habe nie wirklich verstanden warum Tags gepoolt werden müssen, und wieso Tags keine erkennbaren Lifecyclemethoden besitzen anhand derer man das Pooling erahnen könnte. Als Tools setzten wir jVisualVm und <a href="http://www.javaperformancetuning.com/tools/hpjmeter/index.shtml">HPjMeter</a>  ein, um den Garbage Collector bei seiner Arbeit zu beobachten.</p><p><strong>Tag 3</strong></p><p>Ich lernte einige interessante Verhaltensweisen von bislang von mir nicht benutzten Collection Klassen, wie zum Beispiel <a href="http://java.sun.com/j2se/1.5.0/docs/api/java/util/PriorityQueue.html">PriorityQueue</a>  kennen, sowie einige Besonderheiten von Classloading. Heinz schaffte es java.lang.reflect.Proxies hervorragend zu erklären, so daß die Anwendung in der Übung leicht viel. Genaugenomen ist die beste Erklärung Teil der JavaDoc, doch man muss erst verstehen wie man diese zu lesen hat:</p><div>

```java5
Foo f = (Foo) Proxy.newProxyInstance(
		Foo.class.getClassLoader(), new Class[] { Foo.class },
		new InvocationHandler() {
		  public Object invoke(Object foo, Method method, Object[] arguments) throws Throwable {
		    return method.invoke(foo, arguments);
		  }
		});
```

</div><p>Nachmittags diskutierten wir über <em>Exceptions</em>, und ich hatte Gelegenheit mir eine begründete Meinung über die Verwendung von checked vs. unchecked Exceptions zu bilden. Ich werde in Zukunft unchecked Exceptions für Entwickler- bzw. Programmierfehler verwenden. Diese zu fangen ist nicht nötig, die Anwendung mag sogar Abstürzen, aber der Fehler muss behoben werden. Jedoch alle umgebungs-, oder installationsrelevanten Besonderheiten werde ich mit checked Exceptions behandeln. Idealerweise bieten diese brauchbare Informationen damit der fangende Code eine brauchbare Fehlerbehandlung durchführen kann. Eine weitere wichtige Erkenntnis: Einfach Exceptions weiter werfen! Ich weiß gar nicht genau warum ich das bisher kaum tat. Wahrscheinlich wollte ich meine Methodensignaturen einfach sauber halten. Dabei ist weiter werfen oft die beste Alternative. Insbesondere die InterruptedException, welche sowieso nur sinnvoll im Threadcode behandelt werden kann (mit Aufruf von interrupted() und dem Verlassen der Schleife).</p><p><strong>Tag 4</strong></p><p>Der letzte Kurstag begann mit einer echt harten Nuss. Es galt die Performance einer Methode drastisch zu verbessern. Doch Heinz ließ uns nicht an die Optimierung, bevor wir nicht alle Zahlen in verschiedenen Szenarien hatten. Zuvor galt es sogar noch zu beweisen, daß unser Testcode keinerlei Auswirkungen auf die Performance des zu testenden Codes hatte. Ich fand dies besonders lehrreich, da ich durchaus manchmal vergessen habe das Problem zu beweisen, bevor ich mit der Lösung begann. Als Randnotiz betrachteten wir die verschiedenen Modi der JVM und fanden heraus wie langsam java -Xint ist. Nachdem ich endlich den Code auf 10% seiner Laufzeit kürzen durfte gingen wir über zu den letzten Themen des Kurses. So behandelten wir kurz Datum und Zeit, wobei ich doch lieber <a href="http://joda-time.sourceforge.net/">jodatime</a>  oder <a href="http://site.icu-project.org/">icu4j</a>  nutze und versuche java.util.Date zu vermeiden. Zuletzt sahen wir uns noch Logging und einige Kniffe zur Optimierung von Loggingausgaben an. Die wichtigste Botschaft bei Logging ist Code Wächter zu verwenden. Zwar war mir die Technik bekannt, der Name dafür jedoch neu:</p><div>

```java5
if (log.isDebugEnabled()){
  log.debug(complexObject.toString() + expensive.toString());
}
```

</div><p><strong>Wrap-Up</strong></p><p>Ich kann den Kurs bedenkenlos weiterempfehlen. 4 randvoll mit Informationen und Übungen gefüllte Tage sind derartig gestaltet, daß sie auch für erfahrene Entwickler herausfordernd sind. Als Teilnehmer sollte man unbedingt einige Zeit mit Java gearbeitet haben um die Nuancen und Besonderheiten zu erkennen. Anfänger könnten zwar folgen, verpassen aber interessante Aspekte, da das Tempo recht hoch ist. Ferner empfehle ich den Kurs in Deutsch zu besuchen, da Heinz unterhaltsamen Akzent hat 🙂</p>

Erfahrungsbericht Java Specialist Master Course

<p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/pks3D8VdTjq13giXYGsL"><img title="Dr_codecentric_und_seine_kranken_Pfleger" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/pks3D8VdTjq13giXYGsL" alt width="297" height="183" /></a> „Dr. codecentric und seine kranken Pfleger“, das Brettspielteam von codecentric, Andreas Ebbert-Karroum, Torsten Rodemann, Marc Clemens und Fabian Lange (von links nach rechts), trat am heutigen Samstag hoch motiviert zur regionalen Vorausscheidung der deutschen Brettspielmeisterschaft in Dinslaken an. Nach gutem Erfolg im letzten Jahr waren die Hoffnungen, trotz etwas geringerem Training, groß.</p><p>Gespielt wurde von jedem Spieler jeweils eine Runde der Spiele <a href="http://www.amazon.de/gp/product/B0010B5472?ie=UTF8&tag=exfuror&linkCode=as2&camp=1638&creative=19454&creativeASIN=B0010B5472">Agricola</a> , ein anspruchsvolles, komplexes Strategiespiel, <a href="http://www.amazon.de/gp/product/B0014LETVU?ie=UTF8&tag=exfuror&linkCode=as2&camp=1638&creative=19454&creativeASIN=B0014LETVU">Stoneage</a> , ein rundenbasiertes Rohstoffsammelspiel, <a href="http://www.amazon.de/gp/product/B001EWE4EG?ie=UTF8&tag=exfuror&linkCode=as2&camp=1638&creative=19454&creativeASIN=B001EWE4EG">Dominion</a> , ein spannendes Kartenspiel, bei dem die Spieler selbst anhand der verfügbaren Karten ihre Strategien zusammenstellen, sowie <a href="http://www.amazon.de/gp/product/B0007M18XY?ie=UTF8&tag=exfuror&linkCode=as2&camp=1638&creative=19454&creativeASIN=B0007M18XY">Heckmeck am Bratwurmeck</a> , ein einfaches Würfelspiel, bei dem man hervorragend Wahrscheinlichkeitsrechnung üben kann.<br /> <span></span></p><ul><li> Der Start in das Turnier lief bei Dominion gut. 2 erste Plätze und ein Zweiter boten eine gute Basis. Lediglich ein Spiel ging, bedingt durch eine Hexe und viele Flüche, verloren.</li><li>Agricola bot über 2 Stunden Spannung und war ein geistig sehr forderndes Spiel. Leider konnten wir uns gegen die sehr guten Gegner nicht durchsetzen. Sowohl Rancher- als auch Farmer-Strategie wurde von uns probiert. Es reichte zu einem 2. Platz, 2 Dritten und einem 4. Platz.</li><li>Nach einer Snackpause gab es dann noch mehr geistige Erholung beim Heckmeck am Bratwurmeck. Glücksspiele sind nicht unser Metier. 3 Vierte Plätze bezeugen das deutlich. Auch der weitere 2. Platz konnte das Ergebnis nicht retten.</li><li>Zuletzt wurde Stoneage gespielt. 1 Erster Platz wurde mit Bauern eingefahren. Die anderen 3 spielten „Verhungern“ und wurden mit 2 dritten und einem vierten Platz nicht entlohnt. Den Gesprächen entnahmen wir daß viele unserer Mitspieler schon auf deutlich raffinierten Taktiken setzten.</li></ul><p>Trotz des nicht guten Abschneidens war dies ein sehr unterhaltsamer Tag; und Motivation für nächstes Jahr, dann vielleicht doch mit etwas mehr Vorbereitung? 🙂</p>

codecentric bei der Deutschen Brettspielemeisterschaft

<p>Nächste Woche findet vom 2. – 5. März <a href="/wissens-hub/webinare">der Kurs von Dr. Heinz Kabutz</a>  in Düsseldorf statt.</p><p>Meine Erwartungen an den Kurs sind hoch. Den Newsletter von Heinz lese ich schon lange und auch als ich ihn bei unserem Meet The Experts kennen lernen durfte gewann ich gleich einen positiven Eindruck von ihm. Er kennt wirklich die fiesesten Details über Java, und ich hoffe er kann mir einige zeigen. <a href="http://www.javaspecialists.eu/courses/master.jsp">Der Kurs verspricht „Extreme Java“</a> . Ich freue mich also auf sehr esoterische Feinheiten ohne echten Praxiswert. Und auf ebenso viele Fallstricke mit echter Praxisrelevanz.</p><p>Und ich hoffe auf dem Training andere Java Profis zu treffen die ebenso wie ich Spaß an kniffligen Aufgaben haben. Bist Du auch dabei?</p>

Vorschau auf den Java Specialist Master Kurs

<p>Automatisierte Builds und Tests setzen wir bei codecentric schon seit langem ein, jedoch fanden die Buildmonitore bis heute noch keinen Einzug ins Gebäude. Zwar ist der Status bisher auch einfach einsehbar gewesen, doch ihn zum Beispiel beim Kaffee zu sehen ist wichtig. Denn gerade wenn man mal nicht daran denkt nachzuschauen ist der eigene Build oft rot.<a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/nJ4Ym0qBTgSnj6nflhjr"><img title="coofeeandbuilds" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/nJ4Ym0qBTgSnj6nflhjr" alt width="468" height="276" /></a> </p>

Frischer Kaffee und Grüne Builds

<p><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/8naxZy4tTieIirH3JBS9" alt="scrumday düsseldorf" title="scrumday düsseldorf" width="200" height="150" /><a href="http://www.scrum-day.de/">scrumdays</a>  sind eine kleinere Veranstaltungsreihe auf denen sich die SCRUM Gemeinschaft zum Erfahrungsaustausch treffen kann. Da codecentric auch sehr aktiv in der agilen Bewegung ist hatten wir natürlich auch auf den scrumdays in Düsseldorf heute einen Stand. Aus den Vorträgen habe ich zwei Themenschwerpunkte entnommen. Interessanterweise behandeln diese andere Aspekte als die üblichen „warum SCRUM toll ist“.<br /> <span><br /> In den Vorträgen ging es zum einen um firmenspezifische Anpassungen für große und kleine Firmen. Ich selbst sehe diese aber sehr skeptisch. Die agilen Methoden predigen „plan do check act“ oder „apply, inspect, adapt“. Dies bedingt also SCRUM zumindest 3 Iterationen (die von <a href="http://borisgloger.com/">Boris Gloger</a>  empfohlene Standardlänge 🙂 ) getreu den Originalprinzipien zu leben. Ich weiß daß es schwer ist, aber man sollte es ehrlich einmal versucht haben. Heute wurde zumindest der Eindruck geweckt man könne auch gleich mit einem modifizierten Prozess beginnen; Etwas von dem ich persönlich stark abgeraten hätte.</span></p><p>Noch interessanter war aber der zweite Themenblock: Ok, nun da wir SCRUM haben, wie müssen wir unsere Organisation ändern? Brauchen wir neue oder andere Führungsebenen? Brauchen wir gar neue Bezahlmodelle? Wie motiviere ich meine Mitarbeiter wenn es nur noch Teamziele gibt?</p><p>Mein Kollege Andreas sprach in seinem Vortrag über die wissenschaftlichen Hintergründe von Motivation, und warum SCRUM durchaus geeignet ist Basis für eine gute Motivation zu sein. Die Folien seines Vortrags finden sich unten angehängt. Auch <a href="http://chcrudy.wordpress.com/">Christiane Philipps</a>  hatte sehr interessante Ansätze. Ich denke dieser Themenkomplex ist äußerst wichtig und muss weiter erforscht werden, denn SCRUM zeigt uns nun die „weichen“ Faktoren und ihre Probleme, welche die traditionellen Prozesse vor uns verborgen hielten.</p><p>Trotz allem war ich leider von der Veranstaltung enttäuscht. Es kam mir fast so vor als bestünde das gesamte Publikum aus den Speakern und Ausstellern. Kaum „normale Besucher“ ließen sich von mir ausmachen. Die Sessions empfand ich mit 45 Minuten zu kurz, die Pausen hingegen ausreichend Dimensioniert.<br /> Da mochte ich das Setup unseres Meet the Experts mehr, obwohl (oder gar weil?) es dort nur 4 Vorträge von aber hochkarätigen Vortragenden und eine viel freundlichere Atmosphäre gab. Die Hotellobby empfand ich jedenfalls als eher unangenehm für tiefere Gespräche.</p><p>So und hier wie versprochen die Slides von Andreas. Lob und Tadel bitte an ihn, nicht an mich 🙂</p><div><a href="http://www.slideshare.net/AndreasEK/macht-scrum-zufriedener">Macht Scrum zufriedener?</a> <div>View more <a href="http://www.slideshare.net/">presentations</a>  from <a href="http://www.slideshare.net/AndreasEK">Andreas Ebbert-Karroum</a> .</div></div>

#scrumday in düsseldorf

<p><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/lOrJSdeeQkSVnqqTAoi4" alt="mte-architektur-jar-openspace" title="mte-architektur-jar-openspace" width="200" height="150" />In diesem Blogbeitrag fasse ich die Ergebnisse der sehr fruchtbaren Diskussion von Freitagabend zusammen. Auslöser für das Thema war Stefan Zörner der in seinem Vortrag über Modularität davor warnte die Kontrolle über Modularität, insbesondere die über externe Bibliotheken zu verlieren. Dieser Betrag soll nicht die Diskussion wiedergeben sondern nur die Ergebnisse dokumentieren:<br /> <span></span></p><ul><li>OSGi ist ein sehr gutes Modulkonzept welches leider noch nicht im Javastandard enthalten ist. Leider wird es auch noch sehr lange dauern bis sich OSGi im Enterprise Umfeld durchsetzt. Die Hauptursache dafür dürfte in der schlechten Interoperabilität von altem Code und der veränderten Laufzeitumgebung, welche primär für den Betrieb Herausforderungen darstellt, zu liegen.</li><li>Man soll viele kleine Module für die eigene Software verwenden. Es gibt einige kleinere Vorteile, welche insgesamt die etwas erhöhten Entwicklungskosten aufwiegen.</li><li>Es ist absolut notwendig jemanden zu haben der den Überblick über alle verwendeten externen Bibliotheken behält.</li><li>Viele externe Bibliotheken zu haben, kann einige Probleme auslösen: Classloading, rechtliche, Dateigröße, Deployment Dauer, Arbeitspeicherverbrauch.</li><li>Maven oder Ivy lösen das Problem nicht aber helfen bei der Bewältigung ungemein.</li><li>Es ist empfehlenswert regelmäßig den Nutzen eingesetzter Bibliotheken auszuwerten. Kaum genutzter Code kann eventuell umgeschrieben werden um Bibliotheken zu reduzieren</li></ul><p>Vielen Dank an alle Teilnehmer. Über 20 Teilnehmer zeigen klar, daß es wichtig ist Abhängigkeiten besser zu bewerten.</p>

Meet The Experts Architektur – Open Space: Verwaltung des JAR Chaos

<p>Nach einem Upgrade der Java Version auf 1.6.0.17 liefen unsere CXF basierten Webservice im Mule ESB nicht mehr.<br /> <span></span></p><div>

```java5
Caused by: javax.xml.stream.XMLStreamException: java.io.UnsupportedEncodingException: "utf-8"
	at com.ctc.wstx.stax.WstxOutputFactory.createSW(WstxOutputFactory.java:257)
	at com.ctc.wstx.stax.WstxOutputFactory.createXMLStreamWriter(WstxOutputFactory.java:124)
	at org.apache.cxf.interceptor.StaxOutInterceptor.handleMessage(StaxOutInterceptor.java:67)
	... 25 more
Caused by: java.io.UnsupportedEncodingException: "utf-8"
	at sun.nio.cs.StreamEncoder.forOutputStreamWriter(StreamEncoder.java:42)
	at java.io.OutputStreamWriter.<init>(OutputStreamWriter.java:83)
	at com.ctc.wstx.stax.WstxOutputFactory.createSW(WstxOutputFactory.java:253)
	... 27 more
```

</div><p>Auf den ersten Blick ist das merkwürdig, da utf-8 ein unterstütztes Encoding ist. Schaut man aber genauer hin stellt man fest daß die Anführungszeichen Teil des Encodings sein sollen. Dies funktioniert nicht. Laut Spezifikation ist dies zulässig, wenn aber meiner Meinung nach ungewöhnlich.<br /> Diese Änderung ist Teil von JAX-WS 2.1.2.</p><p>Patchen lässt es sich aber leicht, wobei der Patch keinen Anspruch auf Vollständigkeit besitzt:</p><div>

```java5
if (encoding != null && encoding.startsWith("\"") && encoding.endsWith("\"")) {
  encoding = encoding.substring(1, encoding.length() - 1);
}
```

</div><p>Einzufügen ist dieser Code an zwei Stellen:</p><div>

```java5
org.apache.cxf.interceptor.StaxInInterceptor#handleMessage()
nach
String encoding = (String)message.get(Message.ENCODING);
 
und
org.apache.cxf.interceptor.StaxInInterceptor#getEncoding()
vor
return encoding;
```

</div><p>Die gepatchte Klasse sollte auf dem Classpath vor dem original liegen. Danach funktionieren die Webservices wieder.<br /> Mittels eines kleinen UnitTests stell ich zudem sicher daß man nach einem CXF Fix/Upgrade testen kann ob dieses Verhalten nun sauber funktioniert.</p>

Mule+CXF haben Probleme mit Encodings in Anführungszeichen

<p>Eines der meistdiskutierten Themen auf der diesjährigen Devoxx sind die demnächst erscheinenden Javaversionen und die darin enthaltenen Änderungen. Natürlich ist es nett, daß es mit Java 7 möglich sein wird einen switch() mit Strings durchzuführen, oder daß die Platform modularisiert wird. Aber der Hype um <a href="http://en.wikipedia.org/wiki/Closure">Closures</a>  ist mir unverständlich. Java 7 wird sogar extra dafür verzögert. Was soll also der Hype?<br /> <span></span></p><blockquote><p>Closures sind nicht trivial zu erklären. Ich versuche das deshalb auch garnicht und vereinfache sie mal zu Codeblöcken welche Leben eingehaucht bekommen. Dadurch können Closures einen ausserhalb nicht mehr existierenden Zustand referenzieren.</p></blockquote><p>Closures sind ohne Zweifel nett. Ich programmiere gerne in Closures wenn ich JavaScript code schreibe. Auch <a href="http://clojure.org">Clojure</a>  hat mir sehr zugesagt als ich es in Howard Lewis Ships Vortrag näher kennenlernte. Wenn man über Clojure spricht ist auch eines klar: Es ist eine neue Sprache welche ihre eigenen Konzepte und Mechanismen mitbringt. Java zu verstehen und zu können hilft nicht für Clojure, obwohl Clojure interoperabel mit Java ist. Java mit Closures ist hingegen komisch. Der durchschnittliche Java Entwickler wird seine Schwierigkeiten haben Closures zu verstehen, und erst recht keinen Anwendungsfall haben sie einzusetzen. Der Grund ist daß dise Art der Programmierung ein anderes Verständnis vorrausetzt.</p><p>Und das ist <a href="http://en.wikipedia.org/wiki/MapReduce">map&reduce</a> . Ok, es ist jetzt nichts fundamental anderes, und auch kein Grundkonzept, dennoch ist map&reduce ein guter Anwendungsfall. Es wurde in fast jeder Session angesprochen und verspricht die Antwort auf die Frage nach der Skalierbarkeit zu sein. Es vereinfacht viel, da es nur funktioniert wenn man vereinfacht. Um Gregor Hohpe zu zitieren: „if we would have rebuilt a relational database, just to make it faster, we would have failed“. Das ist sicherlich wahr. Die inherente Komplexität einer relationalen Datenbank ist nunmal so daß sich das Problem nicht optimieren lässt. Wäre dies möglich hätte Oracle das sicher bereits getan.</p><p>Also muss man vereinfach, aber wie? Behandelt Daten als Schlüssel Wert Tupel, so wie in den Cobol Copystrecken. Man benötigt doch garkeine Relationen. Sie machen alles nur kompliziert und fügen kaum Wert hinzu.</p><p>Wenn man diesen Schritt gemacht hat kann man sowohl mit als auch ohne Closures skalierbar entwickeln. Natürlich favourisieren die „neuen“ dieses Pattern indem sie Code anbieten der jeweils auf einem Datensatz arbeiten kann.</p><p>Gregor zeigte einige bei Google eingesetzte Muster und Frameworks. Besonders gefiel mir Sawzall, welches scheinbar noch nicht open sourced wurde. Es ist sehr beschreibend und äußerst präzise in der Formulierung was mit einem Datensatz zu geschehen hat. Es ist eigentlich eine einfache Closure:</p>

```
errorcount table sum of int
--------
if contains input 'error'
  emit errorcount <- 1
```

<p>Man kann die aktuellen Trends nur als Aufruf verstehen sich über die aktuellen Problemlösungen Gedanken zu machen. Wahrscheinlich benötigen wir neue Muster und Konzepte, da sich Bestehende nicht weiter optimieren lassen. Wir brauchen etwas Neues. Ob dafür Closures in Java ausreichend sind bleibt zu sehen.</p>

#devoxx 09: map&reduce und closures

<p>Auch dieses Jahr sind codecentric Entwickler auf der Devoxx.  Die Devoxx in Antwerpen gehört mit ihren ausgewählten Speakern und interessanten Themen zu den beliebtesten Java Konferenzen in Europa. Kein Wunder daß die abgebildeten 7 Herren im codecentric Hemd sich dieses Event nicht entgehen lasssen konnten.</p><p><img title="codecentric_at_devoxx" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/KDHfQTy8Q6OvKuiBkgJh" alt="codecentric_at_devoxx" width="548" height="411" /><br /> <span><br /> Schon während der ersten Keynote wurde <a href="http://twitter.com/#search?q=%23devoxx">#devoxx</a>  zum trending topic auf Twitter. Auch Dank des trotz des enormen Ansturmes immernoch funktionierenden Wifis.</span></p><p>Antwerpen und die Devoxx Organisatoren bieten wie immer ein umfassendes Rahmenprogramm. Vom traditionellen Steak Essen, über belgisches Bier, bis hin zum gesponsorten <a href="http://www.imdb.com/title/tt1190080/">2012</a>  Film im Metropolis Kino, in dem auch die Sessions stattfinden ist für alles gesorgt.</p><p>Den einen oder anderen separaten Report zu interessanten Sessions wird es sicherlich noch geben.</p>

codecentric Crew auf der #Devoxx 2009

<p>Bei meinem Vortrag heute bei der Java User Group waren zahlreiche Zuhörer anwesend. Vielleicht wollten sie aber nur an das kostenlose Buffet oder warteten auf den folgenden Vortrag 🙂 Spaß beiseite, es war ein guter Abend. Neben meinem Vortrag über Eclipse RAP (zu dem sich unten die Slides finden) zeigte Andreas Schreiber vom DLR wie die Forscher mit verschiedenen Programmiersprachen ihre echten Probleme lösen; ganz im Gegensatz dazu, wie wir manchmal Probleme lösen die wir ohne Programmiersprachen garnicht hätten. Er zeigte wie man zum Beispiel Phyton an Java anbinden kann und warum das Sinn macht. Dr. Simon Wiest brachte nicht nur leuchtende Bären mit um den Zustand seines Hudson Builds zu visualisieren, sondern auch einige Ideen und Ansätze wie man Builds beschleunigen kann. Der Abend endete mit ein paar Kölsch und Diskussionen wie man denn mit Nabaztags einen sinnvollen Buildmonitor bauen kann ohne nur deren Ohren zu rotieren 🙂</p><div><div><a href="http://www.slideshare.net/fabianlange/eclipse-rich-ajax-platform">Eclipse Rich Ajax Platform</a> <div>View more <a href="http://www.slideshare.net/">documents</a>  from <a href="http://www.slideshare.net/fabianlange">Fabian Lange</a> .</div></div></div>

JUG Köln – 5. Oktober – Vortragsfolien von Eclipse RAP

<p>Andreas gab mir kürzlich den Tipp eine nette Bibliothek anzusehen: <a href="http://projectlombok.org/">lombok</a> . Lombok erweitert den Java Kompilierungsvorgang, so daß bestimmte Klassen mit weniger unnötigem Code auskommen da dieser bei der Kompilierung erzeugt wird.</p><p><a href="http://projectlombok.org/"><img title="Project Lombok" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/h1kIeAkXSCqyU8GRXcLq" alt="Project Lombok" width="267" height="233" /></a> Ich bin total begeistert, so reicht es aus <strong>@Data</strong> an eine Klasse zu schreiben und schon werden die getters und setters, toString() und die hashCode() und equals() Methoden generiert. Im Prinzip funktioniert das so wie die magischen Methoden in Groovy. Ich mag das, da ich mich mehr auf die wichtigen Methoden kümmern kann ohne mich durch hunderte von unnötigen Zeilen scrollen zu müssen. Ich mag auch, daß so niemand Getter oder Setter für Seiteneffekte missbrauchen kann. Es passt auch in den agilen Prozess: Es beseitigt <a href="http://en.wikipedia.org/wiki/Muda_%28Japanese_term%29">muda</a> .</p><p><strong>@SneakyThrows</strong> ist genial! Ich hasse die <em>UnsupportedEncodingException </em>auch wenn ich klar  „UTF-8“ spezifiziere, welches garantiert immer vorhanden ist.</p><p><span></span></p><p>Vor allem mag ich den Implementationsansatz: Lombok hängt sich in den Kompilationsvorgang und generiert den entsprechenden Code für die Annotations. Das Eclipse Plugin sorgt dafür daß Eclipse diese (nicht im code vorhandenen) Methoden anzeigen kann.</p><p>Lombok ist cool und ich hoffe es wächst weiter.</p><p>Aber leider ist die Lombokmagie schwer zu verstehen. Im Code findet sich keine Erklärung dafür wie die Klasse zur Laufzeit sich verhalten wird. Dafür, daß der Code letztendlich nur etwas aufgeräumt wird, muss der durchschnittliche Entwickler viel lernen.</p><p>Man denke auch an die Wartung: Wenn man jetzt Lombok verwendet und in 2 Jahren niemand mehr von Lombok spricht, weil das Projekt tot oder nicht mehr cool ist, wer soll dann ein weiteres Jahr später den Code warten können? Man wird sich wundern wie der Code funktionieren konnte, kompiliert er doch ohne Getter und Setter nicht mehr.</p><blockquote><p>Anmerkung zu Gettern und Settern: I glaube man benötigt sie eigentlich gar nicht, sondern generiert sie nur weil Framework X sie braucht. Getter und Setter sollten keine unerwarteten Seiteneffekte haben. Also genau so wie sie Lombok generiert. Doch dann stellt sich die Frage warum man diese Methoden überhaupt braucht und die Felder nicht einfach public macht. Ich denke der Grund ist der, daß man in Wirklichkeit keine Getter und Setter auf Felder braucht, sondern eigentlich Domänenmethoden haben möchte. Ganz einfach ohne unnötige Getter und Setter und ohne Lombok 🙂</p></blockquote><p>Lombok ist definitiv ein netters Spielzeug für erfahrene Entwickler. Und es ist auch sehr mächtig mit einer erkennbar guten Tendenz für zukünfigie Entwicklungen. Für private Projekte werde ich es sicher nutzen.</p><p>Was denkt Ihr über das Verhältnis von Nutzen zu Verwirrung. Ist es vielleicht sogar konstant, so daß jeder Nutzen immer Verwirrung bringt?</p>

Projekt Lombok – Cool, aber mit zu viel Magie?

<p>Gerade frisch zurück von der <a href="http://www.rheinjug.de/">RheinJUG</a>  und einem großartigem Vortrag von Neal Ford. Passend zu unserem kommenden <a href="/wissens-hub/blog/meet-the-experts-architektur-27-november-2009">Meet the Experts – Architecture</a>  war Neals Thema „Emergent Design & Evolutionary Architecture“. Die Folien finden sich auf <a href="http://github.com/nealford/presentations/tree/master/Emergent%20Design%20and%20Evolutionary%20Architecture%20(Neal%20Ford).pdf">Neals github</a> , also fasse ich mich auch kurz und möchte nur meine persönlichen Eindrücke kurz schildern.<br /> <span></span></p><ol><li>Neal bestätigt unser Credo bei codecentric: Der Code ist das wichtigste. Code ist design, Code ist Architektur. Alles was kein Code ist (auch Kommentare) ist nicht so wichtig, weil es nicht Teil des vom Compiler zu unserem Produkt Übersetztem ist. Die gleiche Idee findet sich in ausführbaren Spezifikationen über die <a href="/wissens-hub/blog/agiles-testen-das-herzstuck-agiler-softwareentwicklung">Thomas vor ein paar Tagen schrieb</a> . Neal betonte auch die Wichtigkeit einen sauberen Code zu haben und Baustellen umgehend zu beseitigen. Code solle mit der Zeit besser werden, nicht schlechter.</li><li>Neal verglich <em>Architektur</em> mit <em>Design</em>. So seien sie sich sehr ähnlich, aber Architektur sei beständiger während Design sich an den Geschäftsproblemen orientiert, welche sich häufig ändern.</li><li>Er klassifiziert Komplexität in zwei Gruppen. Es gibt <em>inherente Komplexität</em> eines Problems, welches die Komplexität ist um die wir uns eigentlich kümmern müssten um ein Problem zu lösen. Oft führen wir aber selbst <em>versehentliche Komplexität</em> ein, indem wir zu generische Lösungen skizzieren. Man kann sie zwar bekämpfen indem man versucht Entscheidungen zu verzögern bis sie notwendig werden und man ausreichend Informationen erlangt hat. Außerdem sollte man die einfachen Lösungen bevorzugen, da man komplexer eigentlich immer werden kann, einfacher hingegen eher nicht.</li></ol><p>Es gab noch viele weitere gute Ideen in seinem Vortrag. Da Neal einen hervorragenden Präsentationsstil hat hätte ich ihm noch den ganzen Abend zuhören können 🙂</p><p>Falls Ihr auch heute Abend auf der JUG wart: Was habt ihr mitgenommen?</p><p>PS: Pac Man wird nie wieder so sein wie vorher 😉</p>

Neal Ford auf der RheinJUG: Emergent Design & Evolutionary Architecture

<p>Eines der größeren Proleme in agilen Softwareentwicklungsteams ist der Aufwand. Natürlich, denn Aufwand ist Geld, und da wir alle gerne Geld haben, wollen wir auch möglichst wenig Aufwand. In Planungsmeetings wird aber oft vereinfachend mit Aufwand umgegangen „oh das ist eine Woche Aufwand“. Wie kann denn aber diese eine Woche umgesetzt werden, wenn man es nicht schafft die Aufgaben für die 5 Tage zu definieren?</p><p>Zur Lösung des Problems schlage ich eine radikale Strategie vor: <strong>Werft am Ende eines Tages alles unfertige weg!</strong></p><p><span>Wie kann das nun hilfreich sein? Nun, ich glaube daran daß jede Aufgabe innerhalb eines Tages erledigt werden kann. Agile Prozesse sorgen zwar dafür, daß Aufgaben klein sind, aber keiner beschränkt eine Aufgabe auf maximal einen Tag. Da das Wegwerfen von geleisteter Arbeit an einem Tag schmerzlich ist, führt dieser Ansatz dazu am Ende des Tages <em>etwas </em>fertig zu haben. Die Gründe dafür warum eine Aufgabe länger als einen Tag dauern kann sind im wesentlichen:</span></p><p><strong>Die Aufgabe ist viel zu groß</strong></p><p>Wie offensichtlich, und dennoch widersprüchlich zu meiner Aussage. Aber wenn man mal genauer hinsieht geht es doch im Wesentlichen nur darum die Granularität von Aufgaben richtig zu gestalten. Wenn eine Aufgabe zu groß ist, sollte man das bisher Erledigte wegwerfen und die Aufgabe zerlegen. Die Arbeit ist nicht verschwendet, gewann man doch viel Wissen über die Aufgabe und die Gründe warum sie länger als einen Tag dauert. Es gibt immer eine Teilaufgabe die sich an einem Tag erledigen lässt!</p><p><strong>Der Fortschritt an der Aufgabe wird durch Andere verhindert</strong></p><p>Nehmt eine andere Aufgabe und wartet nicht einfach ab. Das Hindernis wird frühestens am nächsten Tag diskutiert und ist auch frühestens am folgenden Tag erledigt. Bis dahin könnten mindestens 2 weitere Aufgaben erledigt sein. Außerdem lässt sich selbst bei blockierten Aufgaben immer noch eine Teilaufgabe finden die man noch bis zum Ende des Tages erledigt haben kann.</p><p><strong>Eine total einfache Aufgabe dauert viel zu lang<br /> </strong></p><p>Kann eigentlich nicht sein, ist aber häufig so. Dies ist auch das häufigste Anzeichen dafür, daß man sich verrennt. Es ist besser einfach das Angefangene wegzuwerfen und am nächsten Tag mit einer besseren Lösung zu beginnen. Ich weiß daß jetzt viele denken mögen: „oh jeh, die Kosten“, aber ich weiß auch daß mir viele Entwickler zustimmen, denn nach dem Wegwerfen von Code entstehen fast immer bessere und aber auch in Summe günstigere Lösungen.</p><p>Ist das nun alles einfach nur Zeitverschwendung? NEIN. Es geht darum zu lernen! Es ist wichtig handhabbare Aufgaben zu erstellen. Realistische Aufwandsschätzungen sind nur möglich wenn die Aufgabe kleiner als ein Tag ist. Natürlich sind das dann mehr Aufgaben, aber sie sind genauer und somit das Endresultat der Schätzung, aber auch der Arbeit selbst, bessser. Eine anfänglich höhere Rate von „Verschwendung“ reduziert sich schnell, da niemand Arbeit wegwerfen will. Das Bewusstsein für die Aufgaben und ihren Wert steigt. Am Ende lässt sich diese „oh eine Woche“ Aufgabe in 3 Tagesaufgaben zerlegen.</p><p>Es gibt sogar noch weitere Aspekte an dieser Philosophie. Durch das häufigere commiten von Code oder dem Wegwerfen von unfertigem Code am Ende des Tages findet echte „continous integration“ statt. Jeden Morgen können Entwickler auf einem konsitenten vollständigen und funktionierendem Stand arbeiten. Codemerges werden einfacher und Konflikte selten. Auch wird Duplikation reduziert, da ein Entwickler nicht mehr das machen muss was ein anderer tags zuvor tat. Neben den technischen Vorteilen kann man am Ende des Tages den Kopf einfach frei machen und sich entspannen, ohne Sorge zu haben daß etwas noch nicht fertig ist und man sich am nächsten Tag noch an alles erinnern muss.</p><p><strong>Warum nicht?</strong></p><p>Das häufigst genannate Gegenargument ist daß es bei vielen komplexen schwierigen Aufgaben einfach nicht möglich ist sie in Tagesaufgaben zu zerlegen. Dies kann aber nicht wahr sein, denn es muss einen Anfangspunkt geben, und nach 4 Stunden arbeit muss man weiter sein. Schon nach 10 Minuten hat man etwas gemacht. Etwas, was man als Einzelaufgabe hätte aufschreiben können. Eine nicht zerlegbare 2Wochenaufgabe muss sich immer in 10 Tagesaufgaben zerlegen lassen. Es geht darum, daß nicht der Entwickler vor der 2 Wochenaufgabe sitzt und sich fragt „Wo fang ich nur an?  Wie soll ich das machen?“, sondern daß alle involvierten Personen sich daran beteiligen können. Und es gibt die ersten Ergebnisse schon am nächsten Tag. Und da Tagesaufgaben tendenziell einfacher sind können auch unerfahrenen Teammitglieder besser einbezogen werden.</p><p>Dieser Artikel wurde an 4 Tagen geschrieben. Am ersten verfasst, am zweiten rezensiert, am dritten übersetzt und am vierten veröffentlicht. So war am Ende jeden Tages etwas <em>fertig</em>.</p>

Commite jeden tag, oder wirf es weg – Lebe Agilität jeden Tag

<p>JSP Custom Tags waren früher verbreitet im Einsatz. Obwohl man sie heute nurnoch vereinzelnd schreibt, findet sich ein spezielles Problem in fast jedem Projekt in dem JSP Custom Tags eingesetzt werden.<br /> Da in Produktion der eingesetzte Web Container die benutzten Tags poolen wird, muss man beim Schreiben von JSP Custom Tags den Lebenszyklus (lifecycle) berücksichtige. Das Tagpooling ist von der Spezifikation erlaubt und sogar empfohlen, verursacht aber Probleme wenn man daran nicht denkt. Speichert man große Objekte in Tags, verursacht man ein Memory Leak welches den Server abstürzen lässt (oder es passiert nichts schlimmes, für den Fall daß der Pool oder das Objekt klein genug ist). In der Entwicklungsumgebung fällt dies auch oft nicht auf.<br /> <span><br /> Der Verursacher sieht meist so aus wie dieser Codeschnipsel:</span></p><div>

```java5
public class MyTag extends TagSupport {
  public Object leak;
  public int doStartTag(){
    leak = new BigObject();
  }
}
```

</div><p>Erzeugt wird das Problem dann durch diesen Lebenszyklus:</p><ol><li>Klasse laden</li><li>Instanz erzeugen</li><li>setPageContext() aufrufen</li><li>Setter aufrufen</li><li>doStartTag aufrufen</li><li>In Abhängigkeit von Typ und Rückgabewerten andere Methoden aufrufen</li><li>doEndTag() aufrufen</li><li>Die Instanz in den Pool legen</li></ol><p>Wenn nun der gleiche Tag wieder benutzt wird darf der Container bei Schritt 3 beginnen. Wenn nun der Tagpool auf 10 Objekte eingestellt ist und der gleiche Tag durch 10 simultane Anfragen erzeugt wird, landen 10 Instanzen im Pool. Folgen dann aber nur sporadisch Anfragen, dümpeln 10 Instanzen mit einer Referenz auf das große Objekt im Pool. Und schon haben wir unser Memory Leak.</p><p>Man kann dies aber ganz einfach vermeiden indem man „transiente“ Variablen am Ende auf null setze und sie in setPageContext() oder doStartTag() neu befüllt. Am Rande sei hier angemerkt, daß der Konstruktor eines Tags nur einmal gerufen werden könnte, obwohl der gleiche Tag auf hunderten von Seiten verwendet wird. Wie viele Instanzen erzeugt, und damit wie viele Konstruktoren aufgerufen, werden hängt von den Einstellungen des Containers, des Pools und der Serverlast ab.</p><div>

```java5
public class MyTag extends TagSupport {
  public Object noLeak;
 
  public void setPageContext(PageContext pc){
    noLeak = new BigObject();
  }
 
  public int doStartTag(){
  }
 
  public void doEndTag(){
    noLeak = null;
  }
}
```

</div><p>Weitere und bessere Alternativen wären diese Objekte so lokal wie möglich zu machen. Der Tag selbst sollte nur seine gesetzten Attribute kennen.<br /> Ausser dem bisher beschriebenen Memoryleak entsteht noch ein weiteres Problem. Nehmen wir mal an ein Objekt wird nur gesetzt wenn ein bestimmtes Attribut einen bestimmten Wert hat. Ist dies der Fall, wird das Objekt aber nicht wieder entfernt, so findet man das Objekt bei der nächsten Benutzung des Tags wieder, obwohl die Bedingung auf das Attribut nicht mehr zutrifft.</p>

JSP Tag Pooling Memory Leaks

<p>Leider bringt die Google Suche nach „Convert InputStream to String“ immernoch Ratschläge wie StringBuffer, byte[] oder sonstwas. Wenn man sich den Wildwuchs dort ansieht bekommt man graue Haare. Daher in der Hoffnung, daß es in Zukunft nur noch diese Lösung gibt dieses Posting 🙂</p><div>

```java5
 InputStream stream = getClass().getResourceAsStream("/classpath/resource.xml");
 String xml = org.apache.commons.io.IOUtils.toString(stream);
```

</div>

InputStream nach String konvertieren

<p>Hier einige interessante Statistiken zur <a href="/wissens-hub/blog/codecentric-coding-night">coding night</a> . Da die coding night ein „Projekt im Zeitraffer“ war, sind die von Hudson bei den automatischen Builds erstellten Statistiken ganz interessant.</p><h4>JUnit Test Ausführung</h4><p><img title="Junit Test Trend" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/jwqu90QIKWgYFxFp4vvA" alt="coding-night09-junit-trend" width="500" height="200" /><br /> Das erste was auffällt ist, daß es erst ab Build #68 Testergebnisse gab. Der Build fand um 22:28:56 statt, was etwas mehr als 6 Stunden nach dem ersten commit (16:01:27) entspricht. Der Grund ist zum einen, daß erst Verzeichnisstrukturen in den ersten commits aufgesetzt wurden. Zum anderen ist TDD bei nicht vorhandener codebasis auch recht schwer, zumal die ersten Stunde wirklich eher unkoordiniert waren (das erste Scrum of Scrums zur Synchronisation fand um 20 Uhr statt). Allgemein positiv ist der konstante Aufwärtstrend. Die fehlgeschlagenen Tests sind hauptsächlich einem größeren Refactoring geschuldet. Zudem verhinderte zeitgleiches Grillen, daß diese Fehler schnell bemerkt und korrigiert wurden.</p><h4>Testabdeckung</h4><p><img loading="lazy" title="Test coverage" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/SDx9JO3Tmgg5TOLZ8kfQ" alt="Test coverage" width="500" height="200" /><br /> Der Graph ist auch sehr aufschlussreich, so erkennt man daß die Testabdeckung sehr breit ist, da etwa 90% aller Klassen und Packages abgedeckt wurden. Daß die „Conditionals“ rapide fielen hatte den Grund, daß die Software in der Tat bis Build 83 keine If Verzweigung enthielt. Dies spricht für eine sehr geringe Komplexität, welches der Verwendung von Spring anzurechnen ist, da man selber keine Verzweigungen programmieren muss wenn man immer die richtigen Objekte vom Container übergeben bekommt. Zwar versuchte man dann auch später implementierte  Verzweigungen abzudecken, war aber nicht wirklich erfolgreich. Dies liegt meiner Meinung nach daran daß die Verzweigungen durch Fehler/Exception Handling entstehen und nicht so schön testbar sind. Die steigende Methoden und Zeilenabdeckung ist gut, aber insgesamt viel zu niedrig. Die Ursachen dafür sind allerdings nachvollziehbar. So schlagen sich vorbereitete aber nicht genutzte Services (toter code) durch.  Auch die Modellklassen und unzählige Getter und Setter sind teilweise nicht extra getestet.<br /> Zusammen zeigen die ersten beiden Statistiken ein positives Bild. Kontinuierliches Testen erfolgt auch in stressigen Projekten und bringt eine gewisse Sicherheit über die Qualität.</p><h4>Code Wachstum</h4><p><img loading="lazy" title="coding-night09-code-trend" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/6e8Hql6RXO5MKG2Z6jKH" alt="coding-night09-code-trend" width="488" height="359" /><br /> Abgebildet sind die Zeilen selbstgeschriebenen Codes über Zeit. Man sieht den schnellen Wachstum der Zeilenzahl. Es sieht also nach einem sehr produktivem Projekt auch. Die Verteilung des Codes auf die Entwickler ist interessant, man ist fast geneigt zu sagen: 20% der Entwickler haben 80% des Codes geschrieben. Allerdings relativiert sich dies etwas dadurch, daß die Anwesenheit an dem Wochenende stark schwankte. Die 4-6 stärksten Balken verteilen sich somit auch auf die Entwickler welche fast permanent anwesend waren. Eine Anmerkung am Rande: Letzendlich ist es doch erschreckend, wie viel Code für relativ wenig Funktionalität benötigt wurde. Diesen Kritikpunkt muss Java leider einstecken.</p><h4>Code Typ</h4><p><img loading="lazy" title="coding-night09-code-type" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/H92739qpR3WvnJnSJath" alt="coding-night09-code-type" width="595" height="316" /><br /> Das Tortendiagramm zeigt es deutlich. Wir haben hauptsächlich Java code geschrieben. JSPs wurden als Views genutzt. XML ist kaum vorhanden, da wir größtenteils Annotations verwendet haben anstelle von langen Spring Konfigurationen. Ausgeblendet aus dieser Ansicht sind Javascriptbibliotheken welche eingebunden wurden aber im src Verzeichnis liegen und damit von FishEye als unser Code gezählt wird. Auch zeigt die Verteilung, daß relativ wenig untestbarers entstanden ist. Ausser den Views, welche in egal welcher Form immer problematisch sind, ist fast der komplette Code mit Java Mitteln testbar.</p>

codecentric coding night – facts & figures

<p>Heute mal was ganz kurzes von mir 🙂<br /> Etwas holprig war doch noch die SVN Integration in Eclipse Ganymede. Für Galileo gilt dies nicht mehr. Der Kürzeste Weg zu SVN:</p><ol><li>Help > Install New Software… > Galileo – http://download.eclipse.org/technology/subversive/0.7/update-site/ > Collaboration > Subversive SVN Team Provider (Incubation)</li><li>Help > Install New Software… > Add > Polarion – http://community.polarion.com/projects/subversive/download/eclipse/2.0/galileo-site/</li><li>> Subversive SVN Connectors > Subversive SVN Connectors</li><li>> Subversive SVN Connectors > JavaHL 1.6.0 Win32 Binaries (Optional)</li></ol><p>Nicht durch das „Optional“ verwirren lassen. Im Schritt 1 bekommen wir die SVN Integration für Eclipse. Im Schritt 2 legen wir Polarion als Update site an. Im Schritt 3 Installieren wir das Interface von Polarion zu Eclipse SVN und im Schritt 4 wählen wir noch eine der möglichen Implementierungen.</p>

Eclipse Galileo und SVN

<p>Der erste Eindruck ist wichtig, denn er ist entscheidend für unsere Erwartungen. Wenn man sich nach einer neuen Technologie, oder einem Framework umsieht, so sind Erfolgsgeschichten anderer Nutzer ein wichtiger Faktor um Vertrauen aufzubauen. Natürlich ist es fraglich immer anderen Firmen nachzulaufen, aber das Risiko der allererste Nutzer zu sein ist doch sehr hoch. Aber nicht nur solche Case Studies, sondern auch eine echte Community (also kein totes Forum) mit Feeds, Blogs und vielem mehr, sollten heute auf jeder Framework Webseite zu finden sein, zeigt eine wohl ausgestattete Webseite doch transparent die aktive Entwicklung und Pflege. Natürlich sollte die Seite auch nett und ansprechend gemacht sein, idealerweise mit dem Framework selbst.<br /> <span><br /> Wie aber kümmern sich die Großen unter den Java Frameworks um den ersten Eindruck?</span></p><ul><li><a href="http://tapestry.apache.org" target="_blank">Tapestry</a> , ein schönes Framework mit vielen Generatoren, hat auf seiner Seite keinen Marketing Bereich, man findet nur recht schnell ein herunterladbares Logo, mit welchem man auf seiner Seite zeigen kann, daß sie mit Tapestry läuft. Die Dokumentationsseiten sehen sehr statisch aus, das Wiki etwas unübersichtlich, jedoch enthüllt es nach etwas Recherche eine <a href="http://wiki.apache.org/tapestry/PoweredByTapestry" target="_blank">Liste von Referenzen</a> . Zumindest ist die Seite sauber strukturiert und offensichtlich aktuell.</li><li><a href="http://struts.apache.org/2.x/" target="_blank">Struts, in Version 2</a> , ist der Nachfolger des wahrscheinlich am häufigsten benutzten Java Web Framework. Alte und teilweise falsche Informationen, präsentiert auf einer ganz und gar nicht ansprechenden Seite. Selbst wenn man weiß wonach man sucht findet man es im Wust doppelter (wohl geschuldet an die Zusammenführung von WebWork und Struts2) und veralteter Seiten nicht immer.</li><li><a href="http://myfaces.apache.org/" target="_blank">Java Server Faces</a> , vertreten durch den größten „Community Player“: MyFaces, hat leider auch wenig Marketing. MyFaces hat dabei sogar erst kürzlich die Seiten komplett neu gestaltet. Dennoch finden sich keine Informationen über Kunden, oder gar Demonstrationen. Sehr viele technische Informationen (mit der JSF Spec gleich auf der Startseite), jedoch kein Versuch von dem Nutzen von MyFaces zu überzeugen.</li><li><a href="http://www.springsource.org/about" target="_blank">Spring MVC</a>  oder <a href="http://www.springsource.org/webflow" target="_blank">Web Flow</a>  haben keine echten eigenen Seiten, sie sind als Unterpunkte auf der SpringSource Seite gelistet. Exzellente Dokumentation und Foren helfen Entwickler, überzeugen aber wohl keine Entscheider.</li><li><a href="http://wicket.apache.org" target="_blank">Wicket</a> , ein Java Web Framework welches anders sein will, ist da schon besser aufgestellt. Blogs, verschiedene Themenfeeds, Live Demos und eine aktive Community zeichnen ein sehr gutes Bild von dem Framework. Viel Information verschiedenster Art wird übersichtlich präsentiert.</li></ul><p>Ein kleiner Blick auf die Kontrahenten: Die dynamischen / Scripting Sprachen. Ich wähle einen Vertreter jeder Gattung:</p><ul><li>Das PHP „<a href="http://www.symfony-project.org/" target="_blank">symfony framework</a> “ berichtet häufig über große Installationen, z.B bei <a href="http://www.symfony-project.org/blog/2009/02/18/dailymotion-powered-by-symfony" target="_blank">dailymotion</a> , Yahoo! <a href="http://www.symfony-project.org/blog/2008/05/08/yahoo-answers-powered-by-symfony" target="_blank">Answers</a> , <a href="http://www.symfony-project.org/blog/2006/10/28/yahoo-bookmarks-uses-symfony" target="_blank">Bookmarks</a>  und <a href="http://www.symfony-project.org/blog/2007/10/02/delicious-preview-built-with-symfony" target="_blank">Delicious</a> . Ein Blog, Forum, Wiki (welches aber mal aufgeräumt werden könnte), Screencasts, und Unmengen von Dokumentation, welche in einer Vielzahl von Sprachen erhältlich ist, sind verfügbar. Und die Seite ist selbst mit symfony erstellt. Vom Design her gehe die kürzlich veröffentlichten standalone components einen weiteren Schritt in Richtung ansprechender Präsentation.</li><li><a href="http://rubyonrails.org/" target="_blank">Ruby on Rails</a>  hat sogar eine <a href="http://rubyonrails.org" target="_blank">application gallery</a> , in der große Referenzen wie Twitter, Basecamp oder die yellow pages vorgestellt werden. Hervorragende <a href="http://rubyonrails.org" target="_blank">screencasts</a> , anwendergeschriebene How-tos und ein Blog halten die Community informiert und bindet sie ein. „Get Excited“ ist der Titel des ersten Unterbereiches – eine sehr verführerische Aufforderung…</li><li><a href="http://www.djangoproject.com/" target="_blank">Django</a> , ein Python basiertes Web Framework, hat sogar eine <a href="http://www.djangosites.org/" target="_blank">eigene Seite</a> , welche Anwenundgen „powered by django“ präsentiert, auch wenn sie nicht nach Wichtigkeit oder Größe sortiert sind. Es gibt ebenfalls ein Blog und ein großes Community Wiki. Obwohl das Layout etwas gewöhnungsbedürftig ist und die Seite selst sehr textlastig, fällt die Suche leicht.</li></ul><p>Mit der Ausnahme von Wicket musste ich bei allen Java Web Frameworks feststelle, daß die Seiten sich an Entwickler wenden welche das Framework bereits kennen. Marketing betreiben sie in keiner Form. Ich weiß nicht warum dem so ist, jedenfalls sind das meine Beobachtungen. Vielleicht liegt es daran, daß:</p><ul><li>… Java eine Sprache für Geschäftsanwendungen ist. Es gibt kein Interesse an dem Web Massenmarkt.</li><li>… Java  von Technikern entwickelt ist: Gute Dokumentation aber keine Werbemaßnahmen.</li><li>… Java  ganz anders als das Web skaliert. Ist eine „shared nothing“ Architektur besser als die von Java favorisierten Cluster?</li><li>… es zu viele große Mitspieler in der Java Welt gibt. In anderen Sprachen sind die Top frameworks leichter zu finden.</li><li>… Java Entwickler lieber Code als Dokumentation und Werbung schreiben.</li><li>… Java Frameworks Webseiten entweder mit java.net, apache.org oder maven-site Stil gebaut werden. Dieser Stil ist zwar stukturiert und kann generiert werden, ist aber überhaupt nicht ansprechend.</li></ul><p>Da ich ein großer Fan von Java Frameworks bin macht mich dies natürlich traurig, daher hier meine Ideen um Abhilfe zu schaffen:</p><ul><li>Tue Gutes und sprich darüber. Es gibt keinen Grund zu übertreiben, aber zeigt was ihr könnt.</li><li> Euer Framework ist toll! Nutzt es und macht Eure Webseiten damit. Eine Bessere demonstration kann es nicht geben.</li><li>Benutzt aktuelle Tools, wie ein Blog, RSS feeds und ein Wiki (schonmal vom web 2.0 gehört?)</li><li>Seid transparent – nutzt einen schnellen und einfach zu bedienenden Bugtracker (tschüß bugzilla).</li><li>Macht ein einfaches Design. Es gibt sehr viele freie schöne ansprechende Designs. Denkt daran: Ihr präsentiert Euch und Eure Arbeit.</li></ul>

Java Framework Marketing

<p>„<em>Kann ich diesen Code ändern?</em>“ klingt nach einer ganz üblichen Frage im Projektalltag, aber meiner Meinung nach bringt diese Frage ein großes Problem im agilen Entwicklungsprozess ans Tageslicht.</p><p>Vorab: Die Frage ist sehr gut, zeigt sie doch die heeren Absichten ihres Stellenden: <em>Verbessere gefundenen Code</em>. Ständige Verbesserung ist eine der wichtigsten Grundsätze bei der Erstellung von sauberem Code. Aber die Frage an sich zeigt, daß etwas dem Fragesteller besorgt. Etwas steht in seinem Weg, ansonsten hätte er den Code einfach geändert. In Scrum nennt man dies ein „<em>impediment</em>“ welches gelöst werden muss, aber auch nicht Scrum Projekte sollten dieses Problem lösen. Nebenbei sei erwähnt, daß das Lösen konkreter Fallbeispiele nicht reicht. Das Problem sollte grundsätzlich angegangen werden damit die Frage nicht mehr gestellt werden muss.<br /> <span><br /> Im Folgenden einige von mir als Problemursachen identifizierte Sachverhalte und Lösungsideen:</span></p><ul><li><strong>Der betroffene Code ist nicht zugänglich oder aus politischen gründen tabu</strong> ⇒ Überzeugt Eure Teams, daß gemeinsame Verantwortlichkeit für Code vorteilhaft für alle ist. Es geht insbesondere nicht darum bestimmte Verantwortlichkeiten anderer Teams zu übernehmen. Außerdem sind die meisten Entwickler sowieso vorsichtig bei solchen Änderungen. Insofern braucht man sich nicht vor der „<em>common code ownership</em>“ zu fürchten.</li><li><strong>Das Refactoring bricht existierende API</strong> ⇒ Für die meisten Projekte ist das garkein so großes Problem wie oft dargestellt. Normalerweise wird die API nur intern verwendet und eine neue API könnt auch viel besser benutzbar sein. Selbst wenn die API extern verwendet wird ist eine kontrollierte Änderung durchaus möglich.</li><li><strong>Der Entwickler traut seinen Fähigkeiten nicht</strong> ⇒ Die IT Welt verlangt nach kontinuierlichem Lernen und Veränderung und eigentlich mögen es sogar viele Entwickler an neuem Unbekannten zu arbeiten. Es ist völlig okay zögerlich zu sein, aber frische Ideen können alten Code besser oder robuster machen. <em>Pair Programming</em> mit dem ursprünglichen Ersteller des Codes, oder einem anderen erfahrenen Entwickler im Team hilft hierbei oft die Angst vor Änderungen zu nehmen. Und für den Fall, daß doch etwas passiert gibt es ja Tests…</li><li><strong>Nichtvorhandene Tests machen Änderungen riskant</strong> ⇒ Es ist wichtig Zeit in das Schreiben von Tests zu investieren um das aktuelle Verhalten des Codes zu verifizieren und sicherzustellen, daß es mit dem Verhalten nach der Änderung identisch ist. Schwieriger ist es, wenn in der Änderung auch Verhalten geändert werden soll. Dann hilft es meist nur mit einem Architekten mögliche Implikationen zu diskutieren oder herauszufinden wer den Code aktuell überhaupt verwendet.</li><li><strong>Die genaue Verwendung des Codes ist unbekannt</strong> ⇒ Ein möglichst umfassendes Architekturbild und so viel Code abhängiger Projekte wie möglich helfen die Auswirkungen von Änderungen abzusehen. Für Entwickler wäre ein Refactoringsetup der Entwicklungsumgebung mit sämtlichem Code hilfreich. IDEs bieten viele Refactoringtools und können die meisten Verwendungen von Code aufspüren. Größere Refactorings können auch auf eigenem Branch und unter Beobachtung durch ein Continous Integration system durchgeführt werden.</li><li><strong>Aber es gibt kein Backup…</strong> ⇒ Oh, immer noch kein Versionskontrollsystem? Dies sollte schleunigst geändert werden.</li></ul><p><strong>Code verändern ist gut</strong>, da wir alle Code besser oder schöner machen wollen. Es hilft Lösungen verständlich und einfach zu halten. Wenn man die Ursachen wie Fehler oder Designschwächen nicht  verbessert werden andere Entwickler anfangen diese mit Workarounds in ihrem Code zu umschiffen. Dies führt zu einer unschönen und nicht wartbaren Verschwendung von Bytes.</p><p>Mein Appell an alle Entwickler:<br /> „<strong>Scheut Euch nicht mit guten Absichten fremden Code zu verbessern.</strong>“</p><p>Mein Appell an Projektleiter und Scrum Master:<br /> „<strong>Macht das Ändern fremden Codes schmerzfrei</strong>“</p><p>Um mit einer aktuell allgegenwärtigen Phrase die Frage im Titel dieses Betrages zu beantworten:<br /> „<strong>Yes, you can!</strong>„</p>

Kann ich diesen Code ändern?

<p>Neal Ford hielt am Dienstag auf der JAX einen Talk über <a href="http://en.wikipedia.org/wiki/Domain-specific_language">DSLs</a>  und was sie uns für Vorteile bringen. Er zeigt, daß Java bei der Unterstützung für DSL Notationen recht schnell an seine Grenzen stößt und wechselte daher für seine Beispiele dann zu Ruby. Aber da wir bei codecentric hauptsächlich uns mit Java beschäftigen, habe ich mir mal angesehen was möglich ist und was man damit eigentlich tun kann. Einige Entwickler haben bereits das neue <em>Builder pattern</em> von Josh Bloch mittels eines <em>fluid Interfaces</em> umgesetzt. Aber dieses Pattern hat ein Problem: das sogenannte „finishing problem“. Weil das <a href="http://www.javaspecialists.eu/archive/Issue163.html">Builder pattern</a>  mittels verketteter Methoden arbeitet und Werte via Rückgabeparameter übergibt sind zu verschiedenen Zeitpunkten bestimmte Werte noch nicht initialisiert. Neal zeigte ein von <a href="http://www.jmock.org/" target="_blank">jMock</a>  inspiriertes Beispiel wie man dieses Problem in Java lösen kann. Dies inspirierte mein folgendes Beispiel, welches so oder so ähnlich auch schon von GWT oder Swing Entwicklern verwendet wird.<br /> <span><br /> <strong>Mein Java DSL Beispiel</strong></span></p><div>

```java5
Session ormPitfalls = new Session() {{
	speaker("Mirko");
	attending("Fabian");
	attending("a lot of other people");
	at("Rheingoldhalle");
	at(new JaxDate() {{
		day2();
		session2();
	}});
}};
```

</div><p>Auf den ersten Blick sieht dies nicht besonders ungewöhnlich aus. Aber… Oh.. <strong>doppelte geschweifte Klammern</strong>?? Der hier verwendete Trick ist eine  <strong>anonyme Klasse</strong>, welche <strong>Session </strong>erweitert (genauso bei <strong>JaxDate </strong>etwas weiter). Nachdem der <strong>Standard Konstruktor</strong> ausgeführt wurde laufen die sogenannten <strong>Initializer Blocks</strong>. Dieser Initializier, welcher in geschweiften Klammern geschrieben wird, enthält nun Methodenaufrufe in einer DSL im Kontext <strong>Session</strong>.</p><p><strong>Braucht man das?</strong></p><p>Genauer gesagt hat dieses Vorgehen sogar probleme. Jede Instanz hat seine eigene Klassendefinition, welche zur Laufzeit erstellt werden muss, was eine etwas längere Erstellungszeit nach sich zieht. Ausserdem ist der Speicherverbrauch etwas größer und <strong>getClass().getName() </strong>liefert natürlich einen anderen Namen.</p><p><img title="Performance of Anonymous Classes" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Q3cRyjzlRba01onweCCQ" alt="Performance of Anonymous Classes" width="445" height="139" /></p><p>Und zuletzt bleibt natürlich die große Frage: Wollen wir wirklich, daß Fachabteilungen in Produktion laufenden Code mittels einer DSL schreiben?</p><p><strong>Aber…</strong></p><p>… es gibt eine gute Verwendung: <em>Testen</em>! Sehr gerne sähen wir mehr Fachabteilungen am Testen beteiligt, aber selbst mit guten Tools gibt es immernoch einen großen Aufwand an Mocks und Dummies welche erstellt werden müssen. Der oben gezeigte Code um Objektinstanzen zu erstellen ist aber sehr verständlich. Tester können die Domänenmethoden verwenden anstelle sich mit der Erzeugung von Datumsobjekten durch die <a href="http://java.sun.com/j2se/1.5.0/docs/api/java/util/Calendar.html" target="_blank">Java Calendar API</a>  rumschlagen zu müssen. Ausserdem ist der Code viel lesbarer und besser. Bis jetzt würde die zu testende und die testende Methode jeweils über eigenen Code ein Datum berechnen. Da es aber keinen Test für den Test gibt wird nicht verifiziert, daß die Datumsberechnung ok ist. Im obigen Beispiel ist die Datumsberechnung jedoch nur einmal implementiert.</p><p><strong>Kleiner Calendar Exkurs<br /> </strong></p><p>Da ich gerade beim Calendar bin. Wie berechnent man „morgen mittag“? So?</p><div>

```java5
Calendar today = Calendar.getInstance();
today.setTime(calendar.getTime());
today.add(Calendar.DAY_OF_YEAR, 1);
today.set(Calendar.HOUR_OF_DAY, 12);
today.set(Calendar.MINUTE, 0);
today.set(Calendar.SECOND, 0);
today.set(Calendar.MILLISECOND, 0);
```

</div><p>Das sieht nicht nur hässlich aus, sondern hat auch teilweise falsche Semantik. Besser wäre:</p><div>

```java5
Calendar calendar = GregorianCalendar.getInstance();
Calendar today = calendar.clone();
today.setTime(calendar.getTime());
Calendar tomorrow = today.clone();
tomorrow.add(Calendar.DAY_OF_YEAR, 1);
Calendar tomorrowNoon = tomorrow.clone();
tomorrowNoon.set(Calendar.HOUR_OF_DAY, 12);
tomorrowNoon.set(Calendar.MINUTE, 0);
tomorrowNoon.set(Calendar.SECOND, 0);
tomorrowNoon.set(Calendar.MILLISECOND, 0);
```

</div><p>uhh.. zumindest versucht dieser Code den Zwischenzuständen korrekte Namen zu geben. Wenn dieser Code aber in einer Methode namens <strong>tomorrowNoon()</strong> in unserem <strong>CustomCalendar/Date Objekt</strong> wäre, würde die Semantik viel besser sein (die Methode arbeitet dann nur auf „<strong>this.</strong>„), insbesondere ist der Code vor dem Anwender versteckt.</p><p><strong>Fazit</strong></p><p>Domain Specific Languages sind sehr interessant; insbesondere in Programmiersprachen welche eine noch freundlichere Notation erlauben. Jedoch ist die Zeit in vielen Projekten noch nicht reif. Für Tests hingegen stellen sie schon jetzt ein probates Mittel dar um Fachabteilungen mit einzubeziehen und Testcode les- und wartbarer zu machen. Generell ist es immer hilfreich Methodennamen sprechend zu wählen und die Funktionalität an der Fachdomäne auszurichten.</p>

Pragmatic Domain Specific Languages in Java

<p>InnoDB war bislang die populärste Storage Engine von <a href="http://mysql.com/">MySQL</a> , da die MyISAM Engine auf Grund vieler Limitationen nicht überzeugen konnte und nur in Randgebieten Einsatz fand. MySQL AB entwickelte einige Zeit an <a href="http://www.mysql.com/why-mysql/white-papers/">Falcon</a> , der Nachfolgerengine für InnoDB und MyISAM.<br /> Nachdem MySQL <a href="http://web.archive.org/web/20150218172446/http://www.mysql.com/news-and-events/sun-to-acquire-mysql.html">von Sun übernommen</a>  wurde und der Chefarchitekt von Falcon das Team verließ, stand es schon schlecht um MySQL. Nach der Ankündigung von <a href="http://www.sun.com/aboutsun/pr/2009-04/sunflash.20090420.1.xml">Oracle Sun kaufen zu wollen</a>  wurden die Karten wieder erneut gemischt.<br /> Doch um MySQL steht es meiner Meinung nach schlecht, insbesondere seit nun InnoDB als <a href="http://www.innodb.com/wp/products/embedded-innodb/">eigenständige Datenbank</a>  veröffentlich wurde. Das Produktportfolio von Oracle im Datenbankbereich ist damit nun noch undurchsichtiger und umfangreicher. Wurde noch kürzlich darüber spekuliert ob MySQL als „kleines Oracle“ überleben kann, so ist dies meiner Meinung nach wirklich fragwürdig. Für MySQL spricht wenig. Für InnoDB, welches de facto den Großteil der „MySQL“ Installationen ausmacht spricht deutlich mehr. InnoDB lässt sich gut neben den alten Oracle Produkten positionieren. Für Clusterfähigkeit muss es dann wohl schon bald ein echtes „Oracle“ sein.</p><p>Aber die genaue Zukunft ist noch ungewiss. Dennoch ist jetzt der richtige Zeitpunkt die eingesetzte Datenbanklandschaft mal auf Einsatzweck und verwendete Features zu prüfen. Oracle wird nach der Übernahme das Produktportfolio anpassen, und wir sind dann bereit.</p>

Das Ende von MySQL?

<p>Heute musste ich feststellen, daß in den Apache Commons zwar viel drin ist aber keine Funktion zum CamelCasen von Strings.</p><p>Da ich aus XML Namen im Format <strong>MY_TINY_PROPERTY</strong> gerne den Java Propertynamen <strong>myTinyProperty</strong> haben wollte, musste ich mir selbst behelfen.</p><div>

```java5
private String toCamelCase(String value, boolean startWithLowerCase) {
	String[] strings = StringUtils.split(value.toLowerCase(), "_");
	for (int i = startWithLowerCase ? 1 : 0; i < strings.length; i++){
		strings[i] = StringUtils.capitalize(strings[i]);
	}
	return StringUtils.join(strings);
}
```

</div><p>Dieser Helper deckt den Großteil der vorstellbaren Anforderungen ab. Zumindest meine komplett. Alternativ könnte man auch WordUtils#capitalizeFully() verwenden und das Ergebnis noch transformieren.</p><p>Der Weg zurück ist noch etwas unschöner, da die Trennzeichen für split() nicht so einfach zu bestimmen sind. In vielen anderen Programmiersprachen findet sich so eine Funktion sogar in den Kernbibliotheken, warum hat Java oder Apache Commons das noch nicht? Patch?</p>

StringUtils.camelize(String);

<p>Insbesondere bei der agilen Entwicklung unter Beibehaltung existierender Daten kann man leicht auf ein Problem stoßen welches ich diskutieren möchte:</p><blockquote><p>Eine Kundenverwaltungsoftware für einen PC Verkäufer wird entwickelt. Die Software läuft gut, aber es häufen sich Betrugsfälle im Rahmen von Garantiefällen. Deshalb wird beschlossen bei dem Hersteller der Hardware die Seriennummer im Garantiefall gegenzuprüfen. Bei der Verwendung des Webservices des Herstellers fällt auf, daß ein Großteil der bereits erfassten Seriennummern falsch sind. Der Hersteller gibt die Validierungsroutine heraus und diese wird in die Software eingebaut. Nun wird beim Verkauf und allen weiteren Geschäftsvorfällen die Nummer geprüft. Ab diesem Zeitpunkt häufen sich die Beschwerden der Mitarbeiter, daß die Anwendung alte Kundendaten nicht mehr speichern kann. Auch das Finanzmodul verweigert jetzt seinen Dienst und kann Zahlungen für Rechnungen nicht mehr speichern.</p></blockquote><p>Das Szenario zeigt, daß Bestandsdaten immer Probleme machen wenn zusätzliche Bedingungen eingeführt werden. Man könnte die Validierung auf das Userinterface beschränken und so das Finanzmodul funktionsfähig halten, jedoch hilft dies für die andere Hälfte der Probleme nicht.</p><p>Auch automatische Datenkorrekturen sind nicht immer erfolgreich, da oft Information einfach fehlt.</p><p>Ein Patentrezept gibt es leider nicht, jedoch hat sich folgende Prozedur bewährt:</p><ol><li>Vor dem Hinzufügen der Regel alle Bestandsdaten welche Fehlerhaft sind korrigieren soweit möglich</li><li>Regeln für einen gewissen Zeitraum nur als Warnung, nicht als Fehler prüfen.</li><li>Regeln anhand von weiteren Parametern, welche alte Datensätze ausschließen, anwenden</li><li>Beim Design von Datenfeldern zeitnah Validierung hinzufügen</li></ol><p>Was für Erfahrungen habt Ihr gemacht. Gibt es ein Vorgehen welches das Auftreten von solchen Dateninkonsistenzen vermeidet?</p>

Datenvalidierung und Agile Entwicklung

<p>Wir bei codecentric haben nicht nur den Anspruch führend im Bereich Java Performance zu sein, sondern auch auf anderen Gebieten unseren Kunden mit Rat und Tat zur Seite zu stehen.</p><p>In einem früheren Eintrag habe ich schon einmal über einen <a href="/wissens-hub/blog/vergleich-von-java-und-php-fur-webanwendungen" target="_blank">Vergleich von PHP und Java</a>  geschrieben. Dabei habe ich unter anderem Tooling Probleme bei PHP bemängelt. In diesem Eintrag möchte ich deshalb darauf eingehen wie man PHP Anwendungen Profilen kann.</p><p>Für Java Entwickler sollte <a href="http://www.ej-technologies.com/products/jprofiler/overview.html" target="_blank">JProfiler</a>  ein Begriff sein. Das Äquivalent auf PHP Seite nennt sich Xdebug + CacheGrind. <a href="http://xdebug.org/docs/profiler" target="_blank">Xdebug</a>  ist dabei das Mittel um Skriptaufrufe zu profilen, <a href="http://sourceforge.net/projects/wincachegrind/">WinCacheGrind</a>  nutzen wir dann anschließend um die gesammelten Daten auszuwerten. In diesem Beispiel profilen wir einen Kommandozeilen Aufruf des <a href="http://www.symfony-project.org/about">symfony Framworks</a> . Da ich dort auch commiter bin nutze ich Xdebug dort häufiger um eine gute nichtfunktionale Qualität sicherzustellen.</p><p>Zuerst lädt man die ‚.dll‘ (oder ‚.so‘ für Linux) Extension von Xdebug herunter und legt sie zu den weiteren Extensions in das ‚php/ext‘ Verzeichnis. Um die Extension zu aktivieren muss man in der ‚php.ini‘ Xdebug einbinden und mitteilen wo es hin profilen soll:</p><div>

```none
zend_extension_ts="d:\dev\php\ext\php_xdebug-2.0.3-5.2.5.dll"
xdebug.profiler_output_dir="c:\xdebug-profiling"
xdebug.profiler_enable=1
```

</div><p>Es ist dabei darauf zu achten, daß diese Einstellungen in den richtigen ‚php.ini‘ Dateien gemacht werden. im PHP Verzeichnis findet sich die für die Kommandozeile, im Apache Verzeichnis üblicherweise die für den von Apache gestarteten PHP Prozess. Auch muss das angegebene Zielverzeichnis existieren, ansonsten werden keine Dateien abgelegt.</p><p>Als kurzer Test sollte ein Aufruf von ‚php -m‘ folgendes liefern:</p><div>

```none
[Zend Modules]
Xdebug
```

</div><p>Als nächstes profilen wir einen Aufruf. Z.B. einen der symfony sandbox, zum generieren einer Anwendung:</p><div>

```none
php symfony generate:app codecentric
```

</div><p>In diesem Fall entsteht eine etwa 8MB große ‚cachegrind.out.4896‘. Dieses kann nun mit WinCacheGrind geladen werden. Dies sieht dann in etwa so aus:</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/HQZHGQ6xR5a0JQX07kJC"><img title="WinCacheGrind loaded PHP profiling data" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/HQZHGQ6xR5a0JQX07kJC" alt width="300" height="239" /></a> </p><p>Leider bietet WinCacheGrind nur begrenzte Funktionalität. <a href="http://sourceforge.net/projects/kcachegrind/" target="_blank">KCacheGrind</a>  ist da schon etwas weiter, jedoch bei weitem noch nicht so ausgereift wie die häufig von uns eingesetzten Java Tools. Außerdem findet sich keine Memory Ansicht. Dies ist wohl auch darauf zurückzuführen, daß das Memory Management in PHP sehr dürftig ist. Brauchbar ist dagegen die Anzeige der benötigten Zeit.</p><p>Auf dem Tab ‚Overall‘ findet sich der Code der in Summe die meiste Zeit verbraucht hat. Dies ist für gewöhnlich auch die Stelle an der man schnell die größten Gewinne machen kann. Für den Symfony Task findet sich beispielsweise hier:</p><div>

```none
Function  : sfFinder->search_in
Avg. Self : 0,2ms
Avg. Cum. : 5,1ms
Total Self: 127ms
Total Cum.: 3214ms
Calls     : 629
```

</div><p>die <em>search_in</em> Funktion benötigt selbst im Schnitt 0,2ms, aufgerufene Funktionen benötigen in Summe im Schnitt 5,1ms. Da die Funktion 629 mal aufgerufen wurde ergibt dies dann die entsprechenden Gesamtsummen. Nun kann man entweder schauen ob die Funktion wirklich so oft aufgerufen werden muss, und wenn ja, ob man nicht einen einzigen Durchlauf noch optmieren kann.</p><p>Auch ohne die <a href="/leistungen" target="_blank">richtige Spürnase</a>  für Performanceprobleme kann man mit dem beschriebenen Tooling auch PHP Anwendungen in der Performance optimieren. Es bleibt abzuwarten ob sich PHP und die entsprechenden Tools soweit entwickeln werden wie es heute schon status quo in Java ist.</p>

Profiling von PHP Anwendungen

<p>Vom 20.-22. Oktober fand in San Jose die 6. Ajax World Conference statt. Als Abgesandter von codecentric war ich 3 Tage dort vor Ort um die neuesten Trends und Entwicklungen im Bereich Ajax und RIA zu verfolgen.</p><p>In dem unten angehängten Slideset habe ich versucht die vielen Eindrücke zu sammeln und strukturiert wiederzugeben. Ich hoffe es ist mir zumindest ansatzweise gelungen. Generell war der breite Blick auf das Thema RIA, AJAX oder web 2.0 sehr interessant. Sowohl sehr technische als auch sehr businesslastige Präsentationen gaben ein sehr vollständiges Bild des status quo.</p><p>Ich für mich habe dort viele interessante und nette Menschen kennengelernt, einiges an JavaScript Wissen vertieft und gute Argumentationshilfen für den geschäftlichen Einsatz von RIA gesammelt.</p><p>Für Rückfragen bezüglich der Konferenz, den Slides oder RIA im allgemeinen stehe ich gerne zur Verfügung</p><div><a href="http://www.slideshare.net/fabianlange/codecentric-at-ajax-world-conference-san-jose-presentation?type=powerpoint">Codecentric At Ajax World Conference San Jose</a> <div>View SlideShare <a href="http://www.slideshare.net/fabianlange/codecentric-at-ajax-world-conference-san-jose-presentation?type=powerpoint">presentation</a>  or <a href="http://www.slideshare.net/upload?type=powerpoint">Upload</a>  your own. (tags: <a href="http://slideshare.net/tag/ajaxworld">ajaxworld</a>  <a href="http://slideshare.net/tag/trends">trends</a> )</div></div>

Ajax World Conference in San Jose, CA

<p>Heute schreibe ich über ein Problem welches mir kürzlich mit Struts2 begegnet ist. Es ist allerdings auch gültig für viele andere Szenarien. Hier ein Beispiel:</p><p>Die Wahlen in den Staaten nähern sich, deshalb wollen wir heute eine kleine Vorabstimmung machen.</p><p>Wir bauen dafür einen Service, welcher 3 Methoden enthält:</p><div>

```java5
public interface ElectionFavorite {
  public List getFavs(int userId);
  public List getChoices();
  public void setFavs(int userId, List);
}
```

</div><p>Sieht doch ganz einfach aus. Unsere Auswahl sind mehrere Top Kandidaten, unter anderem Homer Simpson, Dilbert und Captain Kirk. Ich denke diese wären wohl alle eine gute Wahl.</p><p>Als Oberfläche für die Abstimmung schreiben wir eine kleine Struts2 Anwendung und benutzen die CheckboxList um die Wahlmöglichkeiten darzustellen. Die beiden Getter des Interfaces, welches wir als EJB realisieren, verwenden wir um die Möglichkeiten zu laden und falls vorhanden auch eine bereits getätigte Auswahl eines Users anzuzeigen.</p><p>Die Anwendung funktioniert prima, bis wir speichern:</p><div>

```java5
NoClassDefFoundException: com.opensymphony.xwork.util.XWorkList not found
```

</div><p>Wie kann das passieren? Nun Struts2 muss einiges an Konvertierungsmagie für uns durchführen. Der HTML Request liefert leider nur ein HTML Array der Auswahl ab, wir wollten aber eine Liste haben. Also baut Struts2 uns eine Liste. Reichen wir diese Liste nun weiter an unsere Implementierung des ElectionFavorite findet sich diese Liste wahrscheinlich nicht auf dem Classpath. Je nach Classpathkonfiguration kann das Beispiel noch funktionieren, aber spätestens bei einem getrennten Service EAR und der Webapplikation in einem WAR ist dann auch Schluss.</p><p>Um das ganze ans Laufen zu bekommen, muss man auf Clientseite in der Struts2 Action z.B. einen Proxy verwenden welcher die Liste umwandeln kann:</p><div>

```java5
setFavs(List favs){
  this.favs = new ArrayList();
  this.favs.addAll(favs);
}
```

</div><p>Die Moral dieser Geschichte ist, dass Interfaces eine tolle Sache für APIs sind, weil es die Benutzung verschiedener Implementierungen erlaubt, aber wenn genau diese Implementierung nicht überall vorhanden ist können Probleme entstehen. Es gibt grob gesagt 3 Möglichkeiten dieses Problem zu lösen:</p><ol><li>Stellt sicher dass alle Klassen von Clients auch auf Serviceseite verfügbar sind</li><li>Eine Konvention für das jeweilige Projekt nach der nur JDK Implementierungen für Interfaces übergeben werden dürfen</li><li>Benutzt keine Interfaces in Euren Service APIs</li></ol><p>Keine dieser Optionen ist eine einfache Wahl. Leider. Vielleicht hat ja jemand eine viel bessere Idee?</p><p>(Möglichkeit 3 funktioniert durch die Magie innerhalb von Struts2 leider auch nicht)</p>

Struts2 Interfaces und EJB Probleme

<p>Donnerstag hat Peter Roßbach, Entwickler im Tomcat Projekt, auf der <a href="https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjerb-A79TPAhXGKsAKHYkXBlcQFggeMAA&url=http%3A%2F%2Fwww.rheinjug.de%2F&usg=AFQjCNEiK46P8FcgAdlpTiw7AqniYB3Ncg&sig2=F2ut-BAkZDQcyqsUkjBBgQ">RheinJUG in Düsseldorf</a>  einen Vortrag gehalten. Dabei handelte es sich nicht um einen langweiligen trockenen technischen Talk, sondern um ein lockeres Potpourri aus Tomcat Architektur, Best Practices, Open Source Community sowie aktueller und zukünftiger Entwicklung.</p><p><strong>Performanceoptimierung im Tomcat</strong></p><p>Zum Thema Performance nannte er als wesentlichen negativen Faktor die Benutzung des Entwicklungsmodus für Produktion. Im folgenden einige weitere Parameter die er mit ihrer Auswirkung auf die Performance beschrieb.</p><p>So gibt es im Tomcat 6 eine Verbesserte Protokollimplementierung:</p><div>

```apache
<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
 connectionTimeout="20000" />
```

</div><p>außerdem ermöglicht Java NIO eine bessere Dateidownload Option. Servlets sollten dafür nur die Sendfile Request Parameter setzen und keine weiteren Daten ausgeben:</p><div>

```text
 org.apache.tomcat.sendfile.filename: Canonical filename of the file which will be sent as a String
 org.apache.tomcat.sendfile.start: Start offset as a Long
 org.apache.tomcat.sendfile.end: End offset as a Long
```

</div><p>Produktionsserver sollten vor allem nicht automatisch deployen:</p><div>

```xml
<Host name="localhost" autoDeploy="false" deployOnStartup="false" deployXML="false">
```

</div><p>Der Jasper JSP Compiler sollte ebenfalls getuned werden:</p><div>

```xml
<servlet>
  <servlet-name>jsp</servlet-name>
  <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
  <init-param>
<param-name>development</param-name>
<param-value>false</param-value>
  </init-param>
  <init-param>
<param-name>genStringAsCharArray</param-name>
<param-value>true</param-value>
  </init-param>
  <init-param>
<param-name>trimSpaces</param-name>
<param-value>true</param-value>
  </init-param>
</servlet>
```

</div><p><strong>mod_jk zum Loadbalancing</strong></p><p>Als zweiten Schwerpunkt stellte er das Modul „mod_jk“ vor, welches in Verbindung mit einem Apache Httpd und dem Tomcat AJP Protokoll dafür sorgt, daß Java Webapplikationen sich sinnvoll auf Tomcat Server verteilen lassen.</p><p>Er erläuterte die verschiedenen Loadbalancing Konfigurationen und daß es durchaus sinnvoll sein kann einen Tomcat Server pro Applikation zu verwenden. Dies begründet er insbesondere mit Memory Management und Ausfallsicherheit.</p><p>Tomcat Konfiguration:</p><div>

```xml
<Connector port="8009" protocol="AJP/1.3"/>
<Engine name="Catalina" defaultHost="localhost" jvmRoute="node01">
```

</div><p>mod_jk Konfiguration im Httpd:</p><div>

```apache
<IfModule !mod_jk.c>
  LoadModule jk_module "modules/mod_jk.so"
</IfModule>
JkShmFile "logs/mod_jk.shm"
 
JKWorkerProperty worker.list=loadbalancer
JKWorkerProperty worker.node01.port=8009
JKWorkerProperty worker.node01.host=localhost
JKWorkerProperty worker.node01.type=ajp13
JKWorkerProperty worker.loadbalancer.type=lb
JKWorkerProperty worker.loadbalancer.connection_pool_minsize=0
JKWorkerProperty worker.loadbalancer.connect_timeout=30000
JKWorkerProperty worker.loadbalancer.prepost_timeout=10000
JKWorkerProperty worker.loadbalancer.balance_workers=node01
JKWorkerProperty worker.loadbalancer.method=Request
JKWorkerProperty worker.loadbalancer.retries=2
JKWorkerProperty worker.loadbalancer.recovery_options=7
JKMount /myapps* loadbalancer
```

</div><p>Weitere Dokumentation zum mod_jk worker findet sich hier:</p><p><a href="http://tomcat.apache.org/connectors-doc/reference/workers.html">http://tomcat.apache.org/connectors-doc/reference/workers.html</a> </p><p>Insgesamt ein recht unterhaltsamer Vortrag, aus dem man einiges lernen konnte über das Tomcat Projekt und die Tomcat Architektur, wie Open Source „lebt“ und was man als Entwickler/Architekt einer Java Webanwendung so alles beachten sollte.</p>

Tomcat 6 Vortrag von Peter Roßbach bei der RheinJUG

<p>Heute hatten <a href="https://www.codecentric.de/standorte">Christian</a>  und ich es mit einem sehr mysteriösen Connection Problem zu tun. Als Teil einer Prozesskette schlug ein Rest WebService Aufruf fehl. Jedoch tat er dies nur unter Last. Auf Grund dessen wollten wir das Laufzeitverhalten auch nicht durch Debugging Breakpoints zu sehr beeinflussen und beschränkten uns auf Debug-Logausgaben. Dabei war dem nicht ganz einfach beizukommen: Der WebService Client ist eine Erweiterung des Apache Commons <a href="http://hc.apache.org/httpclient-3.x/index.html" target="_blank">HTTPclient</a> . Der Webservice in Struts2 mittels des <a href="https://struts.apache.org/maven/struts2-core/apidocs/org/apache/struts2/dispatcher/mapper/Restful2ActionMapper.html" target="_blank">Restful2ActionMappers</a>  implementiert. Beide bekamen über Spring diverse Dienste injected. Zuerst hatten wir die ungewöhnlich große Größe der Post Requests und der Responses in Verdacht, jedoch schienen diese in Ordnung zu sein. Trotzdem häuften sich Variationen von:</p><div>

```java5
java.io.IOException: CRLF expected at end of chunk: 72/84
java.io.IOException: Bad chunk size: somexml
```

</div><p>Als uns klar wurde, daß das Problem auf dem Transportweg auftritt sahen wir uns um und entdeckten diese Spring Konfiguration:</p><div>

```xml
<bean name="restClient" class="de.codecentric.framework.RestClient">
  <property name="httpClient">
    <bean class="org.apache.commons.httpclient.HttpClient" />
  </property>
</bean>
```

</div><p>Standardmäßig hat der HttpClient einen ConnectionManager der immer die gleiche Connection herausgibt. Sogar an unterschiedliche Threads. Wenn man das einmal weiß, findet man schnell den</p><div>

```java
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager
```

</div><p>doch leider half dieser auch nicht weiter. Es gesellte sich eine</p><div>

```java
java.io.IOException: connection closed
```

</div><p>hinzu. Was vielleicht überraschend klingt: der <a href="http://hc.apache.org/httpclient-3.x/threading.html#MultiThreadedHttpConnectionManager" target="_blank">MultiThreadedHttpConnectionManager</a>  erlaubt per default nur 2 Verbindungen zum gleichen Host. Nachdem wir diese erhöhten lief die Anwendung auch wieder unter Last.</p><p>So ungefähr sieht dann die Spring Konfiguration aus:</p><div>

```xml
<bean name="restClient" class="de.codecentric.framework.RestClient">
  <property name="httpClient">
    <bean class="org.apache.commons.httpclient.HttpClient">
      <property name="httpConnectionManager">
        <bean class="org.apache.commons.httpclient.MultiThreadedHttpConnectionManager" destroy-method="shutdown">
          <property name="params">
            <bean class="org.apache.commons.httpclient.params.HttpConnectionManagerParams">
              <property name="defaultMaxConnectionsPerHost" value="20" />
            </bean>
          </property>
        </bean>
      </property>
    </bean>
  </property>
</bean>
```

</div><p>Fazit: Wenn sich verschiedene Threads die gleiche UrlConnection teilen geschehen die wundersamsten Dinge (Exceptions) 🙂</p>

Seiteneffekte beim Connection-Sharing

<p>Keine andere Sprache sorgt seit langer Zeit für so kontroverse Diskussionen wie PHP. Als auf Java spezialisierte Firma erreichen die codecentric GmbH auch Anfragen zur Migration von PHP Anwendungen.</p><p>Dabei geht die Frage, ob Java besser als PHP sei, an dem Hauptproblem vorbei. Sowohl in Java als auch in PHP gibt es Frameworks, welche speziell das Erstellen von Web Anwendungen unterstützen. Frameworks können natürlich Nachteile von Sprachen ausgleichen, aber auch Vorteile von Sprachen negieren.</p><p>Um den Vergleich von Java und PHP zu verstehen muss man in der Zeit bis etwa in das Jahr 2000 zurückgehen. Java bot damals mit Servlets und Struts erste Konzepte für Web Anwendungen, aber diese zu erstellen, zu konfigurieren und zu deployen war sehr kompliziert. Durch den Boom des Internets entstand eine neue Entwicklergemeinschaft welche schnell HTML lernte. Doch reines HTML begrenzt die Möglichkeit an Interaktion und CGI-Perl Skripte waren umständlich und schwierig. PHP bot hingegen eine elegante und einfache Möglichkeit, wollte man ein Datum in einer Webseite ausgeben, so nannte man die Webseite nicht „.html“ sondern „.php“ und baute an der gewünschten Stelle ein <?php echo date() ?> ein. Auf dem <a href="http://httpd.apache.org/" target="_blank">Webserver Apache</a> , welcher bereits für PHP vorbereitet war, lief die neue Datei sofort.</p><p>Zwar gab es auch in JavaServer Pages die Möglichkeit Scriptlets zu verwenden, doch dies war als unsauber verpönt. Stattdessen propagierte die Java Community die Verwendung von Komponenten. Meiner Meinung nach, ein entscheidender Faktor für die Kategorisierung von Java als „Enterprise“.</p><p>Für Internetanwendungen ist ein schönes Design wichtiger als ein Funktionales, da es mehr Kunden anzieht. Während ein in Dreamweaver oder Frontpage vom Designer gebautes HTML von PHP Entwicklern einfach mit dynamischer Funktionalität erweiterbar war, konnten komponentenbasierte Java Frameworks nicht viel damit anfangen. PHP konnte Designs mit Funktionalität ausstatten. In Java musste man jedoch die Funktionalität verschönern.</p><p>Doch in den vergangenen Jahren entstand Einsicht auf beiden Seiten. Java reduzierte die Komplexität, Frameworks wie <a href="http://tapestry.apache.org/" target="_blank">Tapestry</a>  oder <a href="http://code.google.com/webtoolkit/" target="_blank">GWT</a> , erlaubten von Designern erstellte Templates. PHP erlernte mit Version 5 brauchbare Objektorientierung und Frameworks wie <a href="http://framework.zend.com/" target="_blank">Zend</a>  oder <a href="http://www.symfony-project.org/" target="_blank">symfony</a>  brachten den PHP Entwicklern Designkonzepte bei. Auch die ergänzenden Bibliotheken von Java fanden Entsprechungen auf PHP Seite. So gibt es zum Beispiel in PHP die ORMs Propel und Doctrine.</p><p>Vom heutigen Standpunkt aus betrachtet bieten also Java und PHP ähnliche Funktionalität. Dennoch bleiben weitere Aspekte zu betrachten:</p><ul><li><strong>Stabilität</strong><br /> PHP hat hier meiner Meinung nach deutliche Schwächen. Die prozedurale Abwärtskompatibilität, kein echter Deprecationmechanismus, ein undurchschaubarer Wirrwarr an halboffiziellen Bibliotheken und plattformabhängiger Funktionalität sind nur einige der Problempunkte die PHP hat. PHP mangelt es an einem sauberen Schnitt, den das PHP Team mit Version 6 geplant hat.<br /> Java hingegen hat eine saubere Platformunabhängigkeit und eine recht klar definierte Anzahl an Kernbibliotheken mit entsprechenden Qualitätsstandards.</li><li><strong>Performance</strong><br /> Wurde früher Java oft als langsam bezeichnet, so sind heute die JVMs hochoptimiert, wohingegen die Skriptsprachen, auch PHP noch damit kämpfen. So gibt es erst in PHP 5.3 einen brauchbaren Garbage Collector. Auch andere Optimierungen fanden nur sehr zögerlich Einzug in die PHP Runtimes. Dies mag wohl daran liegen, daß PHP im Gegensatz zu Java nach jedem Request die VM neu startet, was weitere Performanceprobleme bedingt. So muss bei jedem Request die Session von Platte gelesen werden. Zwar gibt es dort auch Lösungen im PHP Bereich (MemCache, APC), jedoch sind diese zum Einen selten eingesetzt, zum Anderen auch noch stark in der Entwicklung.<br /> Interessanterweise macht dieser Nachteil die Skalierung von PHP Anwendungen recht einfach. Da Requests völlig separat verarbeitet werden können, wirkt sich zusätzliche Hardware relativ linear auf die Kapazitäten des Servers aus. Im Web liegt der Fokus auch eher auf der Anzahl der Requests, nicht direkt auf der genauen Dauer eines einzelnen Requests.</li><li><strong>Auswahl</strong><br /> Idealerweise erfindet man das Rad nicht neu. Selbst wenn man es noch runder machen könnte steht der Aufwand auf einer holperigen Straße nicht in Relation zum Nutzen. Von daher ist es sinnvoll bereits existierenden Lösungen zu verwenden. Sowohl in PHP, als auch in Java existiert viel modularer Software, teils mit freien, teils mit unfreien Lizenzen. Allerdings haben PHP Module wesentlich mehr Probleme als in Java geschriebene. So haben einige PHP Modulentwickler sich eigene Konzepte einfallen lassen (z.B. Zend nutzt Zend Loader als Ersatz für Packages) oder die Module sind nur auf ein Framework optimiert (symfony Plug-In).<br /> Java ist als Sprache, gerade durch die „komplizierten Konzepte“ wie z.b. Classloading und Packages, besser auf Modularisierung vorbereitet. Auch durch die bessere Toolunterstützung (Ant/Maven, Javadoc, JUnit) besitzen Java Frameworks leichter zu installierende, besser dokumentierte und getestete Artefakte. Allerdings verbreiten sich PHP Tools für diese Aufgaben (pake/phing, PHPDocumentor, PHPUnit/lime).</li><li><strong>Integration<br /> </strong>Integration ist sicherlich die Stärke von Java. Zum einen ist Java selbst fast „Industry Standard“, zum anderen gibt es für viele Standards Implementierungen in Java. Soll eine PHP Webanwendung auf einem bestimmten Protokoll kommunizieren ist die Auswahl in PHP relativ dünn. Selbst größere Implementierungen sind z.B. von Zend sind teilweise nur sehr rudimentär implementiert (z.B. OpenID). Dies mag aber auch daran liegen, daß Integrationen von PHP Anwendungen oft über Datenbanken laufen.</li><li><strong>Entwickler Know-How</strong><br /> Schon vor 20 Jahren hat Frederic Brooks nach der „Silver Bullet“ gesucht und sie nicht gefunden. In seinem Artikel kommt er zu dem Schluss, daß Softwaredesign, Problemformulierung und die Fähigkeiten der Entwickler wesentlich wichtiger sind als die verwandten Tools oder Sprachen. Von daher ist es sicherlich sinnvoller bei der Umsetzung einer Webpräsenz durch einen Designer mit PHP Kenntnissen ein aktuelles PHP Framework einzusetzen. Soll nur das Web-Frontend für ein Java EE Backend entwickelt werden ist sicherlich Java die näherliegende Wahl.<br /> Allerdings sollte das Entwicklerknowledge nicht primär im Fokus stehen. Gewisse Technologische Hürden lassen sich nur mit bestimmten anderen Technologien und Sprachen sinnvoll lösen, und es ist mitunter sinnvoller einen Experten mit spezifischen Fähigkeiten einzukaufen als es mit ungeeigneten Tools selbst zu versuchen.</li></ul><p>Als Fazit bleibt mir der Schluss, daß Java weiterhin die bessere Wahl für viele Projekte ist. Für kleinere isolierte Projekte können aber Scriptsprachen schneller zum Ziel führen. Als Kompromiss vielleicht Groovy mit Grails?</p>

Vergleich von Java und PHP für Webanwendungen

<p>Am Montag den 11. August habe ich einen Vortrag auf der <a href="http://www.jugdo.de/2014/08/08/sommer-event-programm/">Java User Group Dortmund</a>  gehalten.<br /> Thema des kurzen Vortrages war Garbage Collection Tuning und Möglichkeiten die Erzeugung von Garbage zu vermeiden.<br /> </p>

Am Montag den 11. August habe ich einen Vortrag auf der Java User Group Dortmund gehalten. Thema des kurzen Vortrages war Garbage Collection Tuning und Möglichkeiten die Erzeugung von Garbage zu vermeiden.

Garbage Collection Probleme Einfach Lösen

<p>Am Montag den 11. August habe ich einen Vortrag auf der <a rel="external" target="_blank" href="http://www.jugdo.de/2014/08/08/sommer-event-programm/">Java User Group Dortmund</a>  gehalten.<br> Thema des kurzen Vortrages war Garbage Collection Tuning und Möglichkeiten die Erzeugung von Garbage zu vermeiden.<br> </p>

Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Data Effectiveness

Digitale Produkte & Lösungen

Digitale Souveränität

IT-Security

Künstliche Intelligenz

Software-Modernisierung

Leistungen von A bis Z ...

Leistungen

Arbeitsweise

Referenzen

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Events

Fachmedien

Softwerker

Webinare

Wissens-Hub

Jobs

Unsere Kultur

Karriere

Über uns

Aktuelles

Kontakt

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Garbage Collection Probleme Einfach Lösen

War dieser Beitrag hilfreich?

Blog-Autor*in

Garbage Collection Probleme Einfach Lösen

War dieser Beitrag hilfreich?

Blog-Autor*in

Jetzt für unseren Newsletter anmelden