Buch: Ilya Grigorik High Performance Browser Networking

Jeder der professionell sich mit Webperformance auseinandersetzt sollte dieses Buch besitzen. Es beschäftigt sich sehr gut beschrieben mit dem Browser Networking. Es geht auf alle relevanten Aspekte wie Latenz, Übertragungsgeschwindigkeit, TCP, TLS (aka HTTPS), drahtlose Netzwerke, WLAN ein. Das Networking wir gut und umfangreich beschrieben und sollte Jedem vertraut sein, der über Performance nachdenkt. Der Teil zu HTTP ist gut und endet mit einer kurzen Einführung von HTTP 2.0, das hier nur relativ kurz angerissen wird. Abgerundet wird dieses empfehlenswerte Buch mit XMLHttpRequests, SSE, WebSockekts und WebRTC. Das Buch ist gelungen ist aus meiner Sicht ein Standardwerk für den Bereich Performance und Web, ach wenn der zweite Teil ein wenig schwächer ist.
Wer Themen sucht zur Optimierung der Browserperformance, der wird in diesem Buch leider nicht fündig. Dieser Zweite wichtige Themenkomplex bleibt aussen vor. Hier wünscht man sich ein zweites Buch zu diesem Thema vom Autor. Ilya Grigorik hat diese Dinge leider nicht zu einem Buch zusammengefasst, sondern man findet sie auf der Seite von Google, bei Google Developers unter Webfundamentals, Performance (Link). Auch diese Seiten sind wirklich lesenswert.

Neue Ideen zur Performance Optimierung von Webapps

Nach Brodli und Zopli als Alternativen zur Gzip Kompression im Webbrowser, dachte man das wäre es jetzt. Aber nein es gibt, wieder von Google, nach eine andere weniger bekannte Idee um Bytes in der Übertragung vom Webserver zum Wenbbrowser des Kunden zu sparen, sie heisst SDHC. SDHC oder lang Shared Dictionary Kompression over HTTP, benutz ein gemeinsames Dictionary für die Kompression. Das Dictionary ist bei einigen Kompressionsverfahren ein grundlegendes Element und wird z.B. bei Gzip immer neu aufgebaut in Abhängigkeit zum zu komprimierenden Inhalt. Googles Idee ist, irgendwie ähnelt sich alle Responses also kann man vielleicht mit einem zentralen Dictionary, wenn man es nur einmal überträgt, weitere Bytes sparen. Ich bin gespannt auf die ersten Messergebnisse.

Links:

1. https://engineering.linkedin.com/shared-dictionary-compression-http-linkedin
2. http://blog.endpoint.com/2009/07/sdch-shared-dictionary-compression-over.html

Und es gibt mal wieder ein neues Bildformat, das sich anschickt das alte Ross JPEG in den Ruhestand schicken. Es heisst, jetzt kommt's,  Better Portable Graphics oder BPG. Es greift auf die Still Image Kodierung von HEVC zurück. Mal sehen wie es im Vergleich aussieht, vor allem mit den anderen JPEG Nachfolgern wie WebP oder JPEG2000 und mal sehen wie es mit Browsersupport vorangeht. Auf den ersten Blick ergeben sich bei hohen Kompression Weichzeichnungseffekte, die kennt man ja schon von JPEG2000. Hier könnt ihr das ganze mal selbst probieren: http://xooyoozoo.github.io/yolo-octo-bugfixes/#cologne-cathedral&jpg=s&bpg=s

Die dritte Performance Idee heisst Tubolink und ist die geschickte Anwendung von Javascript um den HTML Body des aktuellen HTML Dokuments im Browserfenster auszutauschen und das Parsen und Kompilieren von inkludierten JS Dateien zu sparen. Die Idee kling ganz nett, die Frage ist, wie hoch das Einsparpotential ist und ob dies mit jeder Webseite funktioniert.

SPDY vs. HTTP

Google hat mit SPDY (Link zum Projekt), gesprochen Speedy, ein alternatives Übertragungsprotokoll zu HTPP und HTTPS entworfen. Es soll die Probleme von HTTP beheben und erfreut sich zunehmender Beliebtheit bei vielen Big Playern (Link). Dem entsprechend gibt es verschiede Test. Google gibt eine Beschleunigung um bis zu 55% an (Link). Das wäre eine dramatische Verbesserung. Guy Podjarny hat in seinem Blog ein interessanten Test (Link) veröffentlicht. Dabei kommt heraus, das SPDY langsamer als HTTP ist und nur ein wenig schneller als HTTPS. Dieses Ergebnisse ist ernüchternd. Wichtig bei dem Test von handelt es sich um ein einen Real World Test, der den aktuelle Stand reflektiert. Sicher sind mit einigen Optimierungen bessere Ergebnisse für SPDY zu erzielen, aktuelle Seiten sind stark für HTTP optimiert. Die Frage ist ob dies den Unterschied von 5% (Guy Podjarny: SPDY vs. HTTPS) zu 55% (Google) erklärt? Ich bin gespannt.

Datenbank-Ressource in Tomcat einbinden

Das das verwenden von Connection Poos eine tolle, Performance steigernde Sache ist hat sich sicher herumgesprochen. Nun gibt es verschiedene Möglichkeiten einen DB Connection Pool zu benutzen. Man kann natürlich auch selber entsprechende Logik in eine zentralen Datenbankklasse implementieren. Bei Serversoftware ist eher davon abzuraten, weil man dann das Connection Management komplexer wird. So schliesst die Datenbank von ihrer Seite aus eine Connection nach einer festgelegten Zeit der Inaktivität um Ressourcen zu sparen, bei MySQL sind dass 8 Stunden, d.h. wenn 8 Stunden lang keine Daten über die Datenbank Connection geflossen sind schliesst die Datenbank die Verbindung. Dies bemerkt man in der Regel erst am nächsten Tag oder am Montag, wenn man versucht Daten von Datenbank zu holen. Die Lösung lautet, man muss immer prüfen ob die Connection noch funktioniert, das macht man in dem man eine Datenbankabfrage macht, die immer ein definiertes Ergebnis liefert. Das prüfen der DB-Connection reicht nicht.

Zurück zum Pooling, Tomcat bietet ein eigenes Pooling mittel Tag resource. Das sieht in der Datei META-INF/context.xml der Webapp wie folgt aus:

<Resource

name="jdbc/MYSQLDB"

auth="Container"

type="javax.sql.DataSource"

username="smartblu"

password="xxx"

url="jdbc:mysql://localhost:3306/igd"

driverClassName="com.mysql.jdbc.Driver"

maxActive="500"

maxIdle="100"

maxWait="10000"

validationQuery="select count(*) from USER"

removeAbandoned="true"

logAbandoned="true"

/>

Mit validationQuery gibt man die oben erwähnte Wartungsabfrage an, mit der DB-Connection-Pool die Datenbankverbindung testen kann. Was jetzt noch fehlt, ist die Referenzierung der Datenbankressource in der Datei web.xml.

<resource-ref>

<description>DB Connection</description>

<res-ref-name>jdbc/MYSQLDB</res-ref-name>

<res-type>javax.sql.DataSource</res-type>

<res-auth>Container</res-auth>

</resource-ref>

Tomcat JDBC Realm

Mit Hilfe des JDBC Realms kann man in Tomcat sehr einfach und elegant eine Benutzerauthentifizierung und Zugriffsteuerung durchführen, bzw. von Tomcat durchführen lassen. Dafür muss man in der Datei context.xml der Webapp folgenden Abschnitt einfügen:

<Realm className="sb.realm.SmartBLURealm" debug="99"

driverName="com.mysql.jdbc.Driver"

connectionURL="jdbc:mysql://localhost:3306/test"

connectionName="smartblu"

connectionPassword=""

userTable="USER"

userNameCol="LoginName"

userCredCol="Password"

userRoleTable="user_roles"

roleNameCol="role_name"

digest="sha"/>

Tomcat versucht dann die Benutzer zu Authentifizieren gegen eine Datenbank jdbc:mysql://localhost:3306/test mit den entsprechenden Parametern. Der Datenbank-Table heisst hier USER. Die Passwörter der Benutzer sind mit SHA gehasht. SHA bedeutet in der Java-Welt meines Wissens nach SHA2.

In diesem Beispiel wir nicht der normale JDBC Realm verwandt sondern ein eigener Realm, der von JDBC Realm abgeleitet wurde aber gleichzeitig ein Migrationsfunktion (das Altsystem verwendete nicht SHA sondern Crypt) besitzt. Die Jar-Datei die die hier verwandte Klasse enthält muss für Tocat verfügbar sein, sie muss sich also im Verzeichnis tomcat/libs befinden. Alternativ kann in dieses Beispiel auch der JDBC Realm (org.apache.catalina.realm.JDBCRealm) eingetragen werden.

Der Realm ist aber nur ein Baustein bei der Authentifizierung mit Tomcat. Die weiterne Bausteine (Login-Config, Rollen und Security Constraints) sind in der Datei web.xml des Projektes enthalten.