Kiu – {Q} – Talk

Ich lese gerade auf Heise folgenden Artikel:

Blitz stört Amazons und Microsofts Cloud in Irland

Neben Erdbeben und Schiffschrauben ein weiteres Kuriosum in der Welt der unvorhersehbaren Zwischenfälle.

(Quelle: Cloudsleuth.net)

Deutlich ist die Ausfalldauer auf dem Chart zu sehen (immerhin ein halber Tag).

Cloudsleuth zeigt die Performance verschiedener Cloudprovider an – leider fehlt die Microsoft Cloud für Irland.

Es ist ja mitunter wirklich eigenartig, was man so zu sehen bekommt.

Gestern habe ich mit einem kurzen Blog schon beschrieben das mythings’s re-targeting engine sich nicht mehr meldet.
Heute hat sich das ganze geändert.
Denn heute führt der Request auf mythings zu einem redirekt welches ein blank.html zurückwirft.

Auf connection 13 sieht man in diesem Fall das Redirect und die Antwort.

D. h. es sieht für das ungeübte Auge also so aus, als würde die Engine arbeiten – tut sie aber nicht.

Was ich mich frage:
Wissen die Kunden von Mythings über das Problem Bescheid ? Dieses existiert nunmehr schon seit 24h.

Das Verlinken von mythings.com an dieser Stelle macht auch keinen Sinn, weil die Webseite derzeit nicht reagiert….oder besser gesagt nur eigenartig reagiert – und mit der Art sich selber dann vermutlich in den Zenit der absoluten Unerreichbarkeit schießt.

Ruft man nun mythings.com auf wird man (mitunter nach einer langen Weile) redirected auf eine ErrorPage.aspx von wo aus man fleißig wieder auf eine ErrorPage.aspx usw. redirected wird.
Man könnte das auch als automatisierten DoS bezeichnen – Hausgemacht.

Wie sich das ganze aus externer Sicht darstellt sieht man hier:

Die gelbe Linie zeigt die Auslieferung des blank.html – Derzeit also keine Funktion. Und damit keine 533% Conversion-Steigerungsmöglichkeit (?!)

[Update 1]

Heute erscheint diese Meldung auf der Mythings.com

Interessant, dass es so lange dauert, obwohl Amazon wesentlich kürzer offline war.

Mythings schreibt in einer Pressemitteilung:

“Die Steigerung der Return Conversionrate um 300-700% stellt den Uplift dar, welcher durch das Anzeigen von personalisierter Werbung gegenüber nicht personalisierter Werbung erreicht wird. Als Beispiel haben 0,57% der Besucher, die keine personalisierten Ads gesehen haben, bei einem Händler den Shop verlassen und danach gekauft, wogegen 3,61% der Besucher, die personalisierter Werbung ausgesetzt waren, danach eine Transaktion abschlossen. Dies stellt eine Steigerung von 533% durch das personalisierte RE-Targeting von myThings dar. “

Was Mythings verschweigt: 100% Conversionverlust, wenn der Server von Mythings steht – wie zur aktuellen Stunde.

Just my 50 Cent.

Lange habe ich nichts mehr geschrieben – es gab einfach andere Prioritäten (Familie / Beruf). Ich hoffe, dass ich jetzt in der Sommerzeit wieder einmal Muße und Zeit finde den ein oder anderer Blogeintrag zu erstellen.

Neues von mir als Gastautor findet sich hier:
http://t3n.de/news/e-commerce-speed-sells-webshop-performance-275306/

Gestern war es mal wieder soweit. Gleich zwei Seiten – in der Presse (Heise / Spiegel) genannt – waren nicht erreichbar.

Betroffen waren: Jako (gleich mit mehreren Domains) und der Bundeswettbewerb Informatik.

In der Heise Community ist dieses Phänomen schon länger bekannt und wurde “Geheist” getauft. Selbst einen Eintrag in Wikipedia gibt es zu dieser Wortschöpfung.

Sicher ist, sobald eine Webseite von den Medien genannt wird (im Guten wie im Schlechten), wird der Anbieter mit deutlich erhöhtem Traffic rechnen müssen.

Zwei Gründe führen in der Regel (es gibt deutlich mehr, aber die genannten sind die häufigsten) dazu, dass die Server in die Knie gehen:

• Anzahl der Connections die der Server/Backend zu bewältigen hat ist schlichtweg zu groß.
• Anbindung (Bandbreite) reicht für die Auslieferung der Daten nicht aus.

Jako war gestern sicher härter getroffen, da zum Zeitpunkt des “Überlaufs” (rien ne va plus) über die Webseite keine Bestellungen getätigt werden konnten (lost revenue) oder schlichtweg keine Angebote anzeigen lassen konnten (risked revenue).

Wie das von außen betrachtet aussieht zeigt der folgende Chart. Eine Stunde nach der Veröffentlichung des Artikels habe ich die Webseite gemessen: Ergebnis: Über Stunden Ausfall des Servers – bis man vermutlich um 0:00Uhr einmal rebootet hat. Selbst heute noch steht das Angebot auf wackeligen Beinen.

Wie kann man sich nun aber als Webseiten-Anbieter vor solchen Problemen schützen?

Eine 100% Sicherheit kann natürlich nichts versprechen – aber ein dediziertes Monitoring könnte verwendet werden, um z. B. bei einer gewissen Anzahl von “gleichzeitigen Sessions” oder bei einer gewissen Bandbreitenauslastung Alarm zu schlagen.

Sicher denken jetzt viele: Ah, das haben wir auch – und trotzdem passiert es.
Vermutlich wurde in einem solchen Fall nicht darüber nachgedacht, was nach einem solchen Alarm passieren soll. In den meisten Fällen die ich kenne, gab es keine definierten Prozesse was denn nun im Alarmfall zu tun sei:
Seitengrößenminimierung, Ersatzseite, Umleitung, dynamische Rechenkapazitätserweiterung etc. etc.?
In vielen Fällen wird häufig gedacht: Ich stelle mir zwei Server hin, die ich im Fall des Falles dazuschalte. Meiner Meinung nach ist das herausgeschmissenes Geld: 2 Server für vielleicht 2 Stunden im Jahr ? (Wartung, Update, Aktualisierung, Test, Hardware)

Hand aufs Herz: Wer hat schon einmal mit einer dynamischen Kapazitätserweiterung (Bandbreite/Rechenleistung) auseinandergesetzt ? Wer hat schon einmal über einen Last-Test seine Kapazitätsgrenzen ermittelt ? Wer hat ein Szenario entwickelt, welches Last-Alarme sinnvoll macht (Prozess) ? Wer hat diesen Prozess schon einmal real durchgespielt ?

Wenn jemand diese 5 Fragen mit “ich” beantworten kann, dann ist er wirklich gut und das Risiko geheist und gespiegelt zu werden ist minimiert!

Wie ich bereits im Teil Zwei der Serie “Der neue Bundestag Internetauftritt” bemerkte, ist die Ladezeit für User mit mäßiger Internetanbindung äußerst lang. Als Grund nannte ich unter Anderem das außergewöhnlich hohe Seitengewicht (in kb).

Ich wurde unterdessen von einem Freund gefragt, was ich denn in solch einem Fall tun würde. Und meine erste Idee war: Überprüfen, ob die Grafiken optimiert werden können.

Das einfachste Mittel für eine solche Schnellüberprüfung lieferte mir das Browserplugin “YSlow”, welches für jeden Webseitenentwickler heutzutage ein “MUSS” sein sollte. Integriert in YSlow befindet sich ein Service der sich “Smush.it” nennt und Grafiken auf Optimierbarkeit OHNE Qualitätsverlust überprüft.

Genau diese Überprüfung habe ich mit der Webseite (www.bundestag.de) einmal durchgeführt.
Siehe da: Über 500 Kb lassen sich so einfachst optimieren.

Den Bildern sieht man keinen Qualtätsverlust an – der User wird es allerdings an der deutlich verbesserten Ladezeit dennoch bemerken.

49% an Daten gespart ! in Downloadzeit für einen Modem-User bedeutet das eine maximale Beschleunigung der Ladezeit von ca. 68 Sekunden.

Komprimiert man nun noch Javascript (derzeit 275 kb) und CSS Dateien (derzeit 147 kb), dann könnte die Webseite rasch nur noch halb so groß sein wie bisher und faktisch doppelt so schnell laden wie derzeit.

Ich wiederhole deshalb die alte Leier gerne:

• Strom sparen
• Server entlasten
• Datenleitungen und Transferleistungen entlasten

Insgesamt also Unsummen an Geldern (Steuerzahler ?)  sparen.

Die Energieleistung, die für das Hosting der Datenmenge, den Transport der Datenmenge und den Abruf der Datenmenge verwendet wird könnte ohne weiteres eine 100Watt Glühlampe (zwinker zwinker) für eine längere Zeit zum Glühen bringen.

Spiegel online in einem neuen Gewand und doch bei der Technik alles beim alten.
Wie schon vor dem Relaunch hat es der Spiegel-Online nicht so mit “Green IT” oder auch ressourcensparendes Agieren – eine Anfrage an die Marketingabteilung des Spiegels blieb leider damals (vor c.a.2 Monaten) unbeantwortet.

Nun wurde der Spiegel neu gelauncht und ich hoffte, dass sich nun etwas ändert.

Fehlanzeige.

Deutschland meistbesuchte Nachrichtenseite (Besucher insgesamt) missachtet durch zwei einfache Konfigurationsmaßnahmen die Regeln des “Grünen” IT-Betriebs – was zudem die Transportwege (Datenautobahnen) verstopft und die User frustriert (lange Ladezeiten).

Man sollte doch annehmen, dass die Jungs und Mädels vom Spiegel das drauf hätten oder ?

Meine  Haupt-Kritikpunkte:

1. Javascript und CSS Dateien werden unkomrimiert ausgeliefert
2. Javascript und CSS Dateien werden nicht im Browser gecached

Das viele andere Dinge (Bilder, Videos) nicht im Cache landen können oder sollen,  könnte und kann ich noch nachvollziehen, aber gerade CSS und Javascript Dateien ändern sich selten und sollten im Cache des Browsers um beim weiteren Browsen durch die Seite NICHT nochmal vom Server angefragt werden zu müssen.

Ein einfacher Blick mit der Firefox Extension Firebug beweist meine Behauptung – Dabei habe ich die Seite genau einmal geladen und danach den refresh Knopf gedrückt:

Cache Einstellung = sofort (mit dem Laden) abgelaufen - Seite wurde um exakt die im Expires Header angegebene Zeit geladen - Wäre die Datei aus dem Cache geladen, wäre der HTTP Response eine 304 (anstelle der 200); Kompression verwendet? Nein

Eine Kalkulation macht das (für mein Verständnis) dramatische Ausmaß verständlich.

Die drei Skripte zusammen ergeben: 188 kb an Daten, die bei JEDEM Aufruf eines Users geladen werden.
Laut IVW (Veröffentlichte Zahlen) waren das im Juli 672.822.499 Seitenaufrufe.

Nun mal gerechnet:
672822499 User*188kb = 126.490.629.812 Kb

126490629812 kb = 123526005,68 MB = 123526 GB = 124 Terabyte

124 Terabyte nur Javascript und CSS ! Wow. Pro Monat !

Content-Kompression durch Gzip oder mod_deflate könnten bis zu 80 % davon einsparen !
Eingesetztes effektives Caching würde bedeuten, dass das Javascript per Visit (Unique User der weitere Seiten anklickt) nur einmal geladen wird.

Caching könnte also schon mal eine Menge Datenfluss minimieren:
Bei den aktuellen Zahlen 672822499 PI / 113005581 Visits kommen wir auf ca. 6 Klicks pro User (= 6 mal laden von Javascript und CSS)
Würden jeweils JS und CSS Dateien nur  einmal geladen (und dann aus dem Cache gezogen) werden wären es gesamt nur:  124 TB / 6 = 20, 7 TB Monatlich (“nur” hahaha…)

Angenommen, nun würde noch für die Dateien vom Typ CSS und JS die Kompression mit Gzip oder mod_deflate aktiviert könnten von der Datenmenge im günstigsten Fall nochmal 80% abgezogen werden = Bleibt eine fast schon lächerlich geringe Datenmenge von irgendwas zwischen 4 und 5 Terabyte pro Monat.

Drei Fliegen ließen sich so mit einer Klappe schlagen:

• Bessere Performance auf dem Endkunden-PC (weniger Daten = schneller)
• Kostenersparnis (Akamai lässt sich das sicherlich gut bezahlen oder ?)
• Ressourcen geschont = Umwelt geschont = Gutes Beispiel = Gutes Marketing = Gestiegene Besucherzahlen….

Vielleicht ließt ja ein Spiegelredakteur diesen Blog und wundert sich, dass zwei der einfachsten Regeln des Performance Managements nicht beachtet wurden !!

Ich vermute, dass eine Argumentation von Seiten des Spiegels schwer fallen wird. Wo sie sich selber doch so sehr für Green IT engagieren: http://www.spiegel.de/netzwelt/tech/0,1518,539506,00.html

Stille ! So könnte man die Performance des neuen Bundestages für all diejenigen bezeichen, die in Deutschland mit einer Internetanbindung von unter 256 kbit/s leben müssen (privilegiert sind z. B. in Bayern in etwa 25% aller Haushalte – sprich 75% aller Haushalte müssen – oder wollen – mit einer Bandbreite von unter 256kbit/s Leben.  Quelle: http://breitband.bayern.de).

Es ist kein Wunder, dass sich die Ladezeit so extrem hinzieht. Einen Grund dafür habe ich bereits im ersten Teil genannt: Die extreme Menge an Daten. Mit derzeit immer noch über ca. 1150 KB ist die Webseite ein wahrer Bandbreitenkiller. Und liegt damit deutlich über dem durchschnittlichen Seitengewicht (kb) aller von Gomez gemessenen Webseiten (ca. 750 kb).

Rein rechnerisch (ohne internettypische Latenzzeiten) benötigt ein Modem Benutzer (11% aller Deutschen Internetanschlüsse) geschlagene 144 Sekunden. Rechnet man hier noch die Latenzzeit für die jeweilige Verbindungserstellung und die möglicherweise dauernde Serverantwort hinzu, dann sind die User ingesamt schnell mit über 3 Minuten Wartezeit dabei.

3 Minuten – das muss man sich mal auf der Zunge zergehen lassen !

Der privilegierte Internetuser, mit mehr als 512 kbit/s, wartet immerhin insgesamt 10 Sekunden (durchschnittlich) bis die Webseite geladen ist. Ca. die Hälfte dieser Zeit starrt er auf einen Bildschirm bei dem sich, außer in der Statusleiste, nichts tut (weil ja erst Unmengen an Javascript geladen werden müssen).

Die ersten 3 Messtage zeigt sich folgendes Performancebild:

Die Messungen von echten Desktop-PCs zeigen: Modem-Nutzer bekommen kaum die Webseite innerhalb von 120 Sekunden angezeigt. Die wenigen erfolgreichen Messungen ergeben sich daher, dass die Messungen mit höherer Bandbreite begonnen wurden und mit niedrigerer Bandbreite beendet wurden (Reklassifizierung der Messagenten zu Dial Up Usern).

Wie sich die Anordnung der Javascripte beim Laden in einem Browser darstellen zeigt die folgende Grafik. Während CSS und Javascripte geladen werden passiert im Browser gar nichts (außer in der Statusleiste)

Es vergehen in diesem Fall immerhin 6,5 Sekunden bis das erste Bildchen zu sehen ist. Davor passiert das, was Steve Souders als white screen Symptom bezeichnet

300.000 € hat das neue Gewand des Bundestages den Steuerzahler gekostet. Und – soviel sei schon mal versprochen – es wird noch viel teurer. Darf ich als Steuerzahler mehr erwarten was die Repräsentation unserer Legislativen angeht ?

Über das Design und die Funktionalität möchte ich mich (jetzt) gar nicht auslassen, aber die Webseite kommt daher als 1,25 Megabyte schwerer Dinosaurier, der so ziemlich jeden User, der keine 1A Internetanbindung hat (und das sind verdammt viele) zum verzweifeln bringen wird.

Wie schon das Internet Politbarometer zeigt, interessiert sich die Politik (dort die einzelnen Parteien) kaum für den User. Der neue Internet-Auftritt beweist zudem, wie mit Ressourcen herumgeschleudert wird.

Umweltschutz ? Fehlanzeige.

0,5 MB Skript/CSS unkomprimiert ! WOW

Durch Kompression, könnte extrem viel Serverpower gespart werden, der User müsste nicht so lange sein Modem laufen lassen etc.. Das Kostet Geld und wird die benötigte Bandbreite der Server nur belasten.

Qualitativ lässt die Umsetzung des Designs deutliche Wünsche offen. Das Design nicht sauber X-Browser-Kompatibel umgesetzt. Da wird wohl nochmal nachgebessert werden müssen.

Beim Opera bricht die Suche aus der Navigation aus, Das Große Plenarsaalbild hat eine unschöne Ecke unten. (Klicken zur Detailansicht)

Windows Mobile User haben extrem viel Spaß:

Wo bin ich ?

Mit einem aktuellen Safari-Browser wurde vermutlich auch nicht geschaut, ansonsten würden solche “Lücken” im Design nicht entstehen.

Geballte Internet-Kompetenz ?

Wenn der Auftritt repräsentativ sein soll, dann muss wohl nochmal nachgebessert werden. Vermutlich war eine X-Browser-Kompatiblität nicht Bestandteil des Projekts und muss nachberechnet werden.

Wer hat das Projekt abgenommen und geprüft ? Oder wurde es “durchgewinkt” wie eines der vielen kontrovers diskutierten Internetthemen ? Fragen über Fragen.

Kopfschüttelnd nehme ich das zur Kenntnis und Frage mich, was Babiel als Agentur sich da für eine Referenz geschaffen hat.

In Teil 2 werde ich mich die Tage mit der Performance beschäftigen….das wird auch nochmal spannend.

In der Presse wird gerade über die Performance von Twitter berichtet.

Ursache dafür ist wohl ein massiver Trafficzuwachs durch Spam-Mails provoziert – und nicht wie gestern noch angenommen eine Hackattacke.

Betrachtet man nun die Ladezeit von Twitter über einen längeren Zeitraum, stellt man deutlich fest, dass Twitters Performance sich deutlich verbessert hat und selbst der Hackangriff die Startseiten Ladezeit nur minimal beeinflusst hat. Der Server war für wenige Stunden nicht erreichbar, aber wenn er da war war er schneller als vergleichsweise 1 1/2 Wochen zuvor.

Twitters Ladezeit über die letzten 14 Tage. Seit einer Woche ist die Ladezeit rasend schnell im Vergleich zu vorher.

Aus der Sicht der Verfügbarkeit wird das Problem dann schon eher deutlich:

Deutlich zu sehen, trotz extrem schlechter Ladezeiten war die Verfügbarkeit von 2 Wochen deutlich besser als die letzten 24 Stunden

Gemessen wurde pro Stunde 1 x aus den folgenden Backbone Netzwerken:

CA: Santa Clara – SAVVIS

IL: Chicago – Level3

NJ: Newark – Qwest

TX: Houston – InterNap

VA: Reston – SAVVIS

WA: Seattle – InterNap

CANADA: Vancouver – Rogers Allstream

CHINA: Beijing – China Netcom

DENMARK: Copenhagen – LambdaNet

GERMANY: Munich – Telefonica

UNITED KINGDOM: London – Global Crossing

(Messplattform: www.gomez.com), gemessen wurde nur die Startseite

Was genau sich verbessert hat in der Performance sieht man hier (für die Techniker):

Das Hauptproblem waren die initalen Verbindungen und die lange First Byte Zeit. Das Problem scheint definitiv beseitigt zu sein.