Für Java Entwickler hat das SPDY Protokoll den großen Vorteil, dass an der Applikation selbst keine Änderung vorgenommen werden muss. Das Protokoll muss rein serverseitig implementiert werden. Der aktuelle Jetty in der Version 9 stellt mit seinem SPDY-Connector die Referenz-Implementierung für das SPDY Protokoll. Clientseitig wird SPDY derzeit von aktuellen Chrome und Firefox Browsern unterstützt. Browser die kein SPDY unterstützen (z.B. der Internet Explorer), werden weiterhin über HTTP 1.1 bedient. Das SPDY Protokoll ist 100% kompatibel zu HTTP 1.1, so dass moderne Browser von SPDY profitieren, alle anderen Browser die Web-Anwendungen aber ebenfalls nutzen können. Neben dem Jetty und dem Apache Web Server gibt es derzeit noch keine „stable“ Implementierungen des Protokolls. Für den Tomcat Servlet-Container wird ein SPDY-Connector frühestens mit Version 8 bereitstehen.
Der reine Performance-Gewinn durch den Einsatz von SPDY bzw. SPDY-Push kann je nach Web-Anwendung bis zu 25 Prozent bringen. So demonstrierte Thomas uns eindrucksvoll am Ende seiner Session den Aufruf einer präparierten Webseite mit HTTP 1.1, SPDY und SPDY mit aktiviertem Push-Cache. Die Seite hatte mehrere Bild-Ressourcen, die beim Aufruf über HTTP 1.1 aufgrund des Aufbaus von entsprechend vielen Socket-Connections die Bilder sichtbar nacheinander geladen hat. Beim Aufruf mittels SPDY war bereits ein Unterschied in der Lade-Geschwindigkeit sichtbar, da nur noch eine einzige Socket-Connection aufgebaut wurde, über welche die Bilder übertragen wurden. Beim letzten Testfall (SPDY mit aktiviertem Push-Cache) konnte man einen deutlichen Unterschied erkennen: Die Bilder waren sofort da. Ich hatte den Eindruck, als kämen die Bilder direkt aus dem Browser-Cache (der Browser-Cache war natürlich in allen Szenarien deaktiviert).
Linux Knowhow ist auch bei Java Entwicklern erwünscht
So die Aussage der Session „Java auf Linux-Servern unter Hochlast“ von Oliver Jucknath und Felix Becker. Die beiden haben uns praxisnahe Beispiele für die Analysemöglichkeiten von Performance Problemen auf Linux-Servern unter Last gezeigt. Mithilfe von JMeter Szenarien demonstrierten sie, dass selbst kleine Änderungen an Anwendung und/oder Systemkonfiguration große Auswirkungen auf die Gesamt-Performance haben können. So kann ein Log-Eintrag, der durch die Anwendung erzeugt wird, im Zusammenspiel mit dem Auslagern der Log-Files auf ein NFS-Laufwerk zu wesentlich geringerem Durchsatz der Anwendung führen. Das häufige Schreiben via NFS ist im Verhältnis zur lokalen Festplatte extrem langsam und wird zusätzlich durch sonstigen Netzwerk-Traffic beeinflusst.
Der klare Aufruf der beiden ist, dass für den optimalen Betrieb einer Java Anwendung immer Entwickler und Sys-Admins eng zusammen arbeiten sollten. Vor allem sollten Java Entwickler sich nicht scheuen, ein gewisses Knowhow von Linux Systemen aufzubauen, um das Verhalten der eigenen Anwendung besser analysieren und einschätzen zu können.
Als kleinen Praxistipp lege ich allen, die „kill -3 <java-proc-id>“ noch nicht kennen, diesen Befehl wärmstens ans Herz. Das Ergebnis ist ein Stacktrace und Infos zum aktuellen JVM Zustand des Java Prozesses. Probiert es einfach mal aus!
Parallele Programmierung mit Akka
Sehr spannend fand ich auch die Vorstellung des Concurrency Frameworks „Akka“ durch Heiko Seeberger von Typesafe. Akka implementiert das Aktoren-Modell, welches dem Entwickler die parallele Programmierung mit Threads erleichtert.
