HTTP Client Performance

Für die Load- und Performance-Messungen auf dem Server gibt es eine Reihe von Werkzeugen wie XLT (Link) oder das bekanntere Apache JMeter (Link). Die einfachste Aufgabe ist es eine Reihe von HTTP Request an den zu untersuchenden Server zu senden. Dabei kann man in JMeter die Implementation für den HTTP Request auswählen. Zur Auswahl stehen in JMeter 2.9: HTTPClient3.1, HTTPClient4 und Java. Alternativ brauch man nicht auswählen, dann wir Java als Standard benutzt.

Aber welcher dieser drei HTTP Clients ist die optimale Wahl. Im Atlassian Blog gibt es einen Vergleichstest zwischen verschiedenen HTTP Clients (Link), dabei sind auch die drei JMeter Kandidaten. Eine normale JMeter Anwendung besteht in der Regel aus vielen kleinen HTTP Requests. Bei Atlassian Test für kleine Dateien (80kb) liegt CURL vor  dem HTTPClient3.1 und dem Java (hier Bee). Wie verhalten sich aber die HTTP Clients im JMeter-Test? Dazu habe ich einen kleinen Testaufbau mit einem konstanten Durchsatz von 152 Request/s auf verschiedene kleine HTML- und JSON Fragmente aufgesetzt. Dabei erreichten die Clients folgende Werte für den durchschnittliche Requestdurchsatz und den auf dem Loadwert auf dem JMeter-Client:

1. HTTPClient3.1; 164 Req/s; Load 2.0
2. HTTPClient4; 137 Req/s; Load 2.9
3. Java; 150 Req/s; Load 2.6

Damit bestätigt sich das Bild aus dem Atlassian-Test, die für die meisten Test günstigste Wahl, weil performateste und Ressourcen-schonenste Auswahl ist der alte Apache HTTPClient3.1., der leider nicht mehr weiter entwickelt wird.

Browser Fingerprinting

Mit Hilfe von Cookies lassen sich Browser und damit Benutzer im WWW sehr leicht wieder erkennen. Dabei hinterlässt der Web-Site Betreiber einen Datenkrümel beim Benutzer, also im Webbrowser. Somit ist auch für den Web-Surfer erkennbar, dass der Web-Site-Betreiber ihn trackt. Es bleiben eindeutige Spuren zurück. Daneben gibt es aber eine Form des Treckings, das keine Spuren beim Benutzer hinterlässt, das Browser Fingerprinting. Dabei werden diverse Informationen des Browsers abgefragt wie User Agent, bevorzugte Sprachen, unterstützte Mime Types und Plugins, Bildschirmauflösung und weitere Dinge. Damit ergibt sich ein möglicherweise eindeutiger Wert. Wer dies sich für seinen Browser sich ansehen möchte: Link.

Gegen Cookies helfen Adblocker, die Tracking Pixel und die damit verbundenen Cookies fern halten oder das gelegentliche Löschen der Cookies oder der Surfen im privaten Modus.

Aber was hilft gegen Browser Fingerprinting? Die vollständige Deaktivierung von JavaScript und Flash scheinen im Moment ein guter Weg zu sein oder die Nutzung von JonDo.

Es wäre sich auch ein interessanter Weg die Daten die fürs Browser Fingerprinting genutzt werden zu reduzieren. Aber dies ist bei den meisten Browsern schwierig. Die Option der Manipulation des User Agents wäre für die Browserhersteller ein einfache Option, vielleicht auch die Abschaltung einiger anderer Dinge wie die Font-Erkennung, die durch die Webfonts an Bedeutung verlieren. Eine Verringerung der potentiellen Datenmenge führt zu weniger eindeutigen Erkennbarkeit des Benutzers. Oder wie wäre es mit einer Sicherheitsabfrage: Erlauben sie dieser Website die technischen Daten ihres Browsers zu erfassen? Oder kann man statt Cookies zu vermeiden sie tauschen, vielleicht ein automatische Cookie-Tauschbörse?

Warum gibt es überhaupt diese Techniken wie Cookies oder Browser Fingerprinting, bzw. warum sind sie populär? Neben eineigen sinnvollen Anwendungen, wie die Sissionsmanagement z.B. beim Einkaufen im Internet geht es primär um das gezielt ausspielen von Werbung. Targeting und Retargeting sind hier die Schlüsselworte. Eins muss man klar sehen, das Internet ist nicht umsonst, wir bezahlen mit Werbekonsum oder wir bezahlen für Tools die die Werbung uns vom Hals hält.

Weiter Informationen zu Thema: Link

Installieren von Java auf einem QNAP TS-110

Das QNAP TS-110 hat Marvell 6281 mit 800MHz, die CPU ist kompatibel mit ARMv5. Damit sollte man das neue Java 7 bzw. der Java 8 Preview sich installieren lassen. Der erste Hürde ist der Download via Command Line:
wget --no-check-certificate http://www.java.net/download/jdk7u40/archive/b40/binaries/jdk-7u40-fcs-bin-b40-linux-arm-vfp-sflt-16_aug_2013.tar.gz  -O java7.tar.gz


Nach dem Entpacken der Test:

[/share/Public/jdk1.7.0_40] # bin/java -v
Illegal instruction


Es funktioniert nicht.

Update:

Ein Jahr später. Es geht doch: LINK Java läuft auf dem kleinen QNAP TS-110.

Kann ich SPDY nutzen?

SPDY ist ein HTTP Alternative, die Mängel von HTTP(S) kompensieren soll und besser den Anforderungen moderner, grosser Web-Applikationen entsprechen. Doch wie verbreitet ist SPDY bei den Benutzern? Dazu gibt es ein hilfreiche Übersicht, welcher Browser SPDY unterstützt (Link). Kombiniert man diese Daten mit der Webbrowserverbeitung von StatCounter kommt man auf eine Browserunterstützung von 65% für 09/2013. Damit kann man für 65% der heutigen Benutzer die Webaplikation zu beschleunigen. Die Browserunterstützung wird auch den IE erreichen und damit werden können fast alle Benutzer SPDY nutzen.
Übrigens gibt es nettes Firefox Addon SPDY indicator, das anzeigt ob die Site per SPDY ausgeliefert wird.

Wie surft Deutschland 2012/2013?

Jeder der eine Web-Projekt aufsetzt muss seine Kunden kennen. Dazu gehören auch die technischen Fragen: Welche Browser werden genutzt? Mit welcher Geschwindigkeit surfen die Kunden?

Bei den Webbrowsern ist die Frage relativ einfach zu beantworten, eine gute Quelle ist StatCounter. In Deutschland ist seit Jahren Firefox an der Spitze der Charts.
Aber mit welcher Geschwindigkeit welchem Zugang und welcher Latenz kommt der Kunde? Hier gibt es gute Quelle, die Bundesnetzagentur. Daraus ergibt sich folgende Verteilung: 93% der Haushalte in Deutschland verfügen über einen Breitbandanschluss. Diese splitten sich in 83% DSL, 13% Kabel und 3% LTE auf. Für die Latenz (Ping) bedeutet das: DSL 24msec, Kabel 15mesc und LTE 45msec. Dazu kommt, dass 40% der Haushalte in Deutschland WLAN einsetzen mit einer Latenz von 10msec. Ein typischer Benutzer setzt DSL6000 und Firefox ein. WLAN ist aber eine sehr häufige Option. Für Webtest wären ein sinnvoller Wert für Latenz (DSL + WLAN) 34msec.

Quellen:

Bundesnetzagentur, Jahresbericht 2012
Bundesnetzagentur, Abschlussbericht „Dienstequalität von Breitbandzugängen“, 2013

ANT Properties laden

Die Propertiesverarbeitung in ANT ist komfortabel aber nicht ohne Tücken. Properties können mittel Tag, File oder ANT Parameter (-D) gesetzt werden. Aber wer gewinnt?

• Wird ANT mit Parameter -Dpropertiename=wert gestartet, dann gewinnt dies immer.
• Das setzen eines Propertie per File oder Tag sind gleichberechtigt, der letzte gewinnt.

Wer braucht Closures?

Ich nicht. Ich nicht, solange ich nicht JavaScript programmiere. Man kann mit Closures unter anderem den Mangel an this in JavaScript ausgleichen. Wenn man Closures und ggf. Currying beherscht ist dies cool aber kein Grund diese Techniken immer und immer wieder einzusetzen. Closures haben auch Nachteile: Memory leaks und schlechtes Laufzeitverhalten:

• http://molily.de/weblog/closures-performance

Ach so, wenn man nach dem Begriffen Vorteilen Closures googelt, da findet man viel über deren Nachteile.