Kiu – {Q} – Talk

Drastischer Abfall der Linken bei der Erreichbarkeit. Ladezeiten der FDP haben sich auf den Backbones drastisch verschlechtert.

Auch bei den Usern mit schneller Internetanbindung deutlich zu sehen. Sowohl die Linken als auch die FDP muss dramatische Einbußen bei Geschwindigkeit und Verfügbarkeit hinnehmen. Die Grünen konnten als einzige etwas Boden bei der Ladezeit gut machen.

Bei der Ladezeit konnet sich die CDU/CSU dezent verbessern. Fällt aber weiterhin zusammen mit den Linken bei den Usern mit DSL-Light (< 512 kbit/s) deutlich in der Verfügbarkeit ab. Jeder 10te Aufruf konnte gar nicht oder nicht schneller als 120 Sekunden ausgeführt werden. Einzig die SPD konnte sich leicht verbessern.

Bei den Ladezeiten fast durchweg Verbesserungen. SPD und Grüne verschlechtern sich hier gegen den Trend. Mit 40 Sekunden und mehr wird allerdings die Geduld der User arg strapaziert. Bei der Verfügbarkeit beim Modemnutzer konnten SPD und Grüne weiter zulegen. Die FDP ist ganz klar und mehr als deutlich Sieger, während die CDU den positiven Trend nicht halten konnte. Lediglich 28,4% aller Zugriffe war erfolgreich. Mit diesem Ergebnis dürfte es eng werden für die CDU, die gerade bei der konservativen Bevölkerung auf dem Land punkten will.

Die Messergebnisse zum Download: ergebnisse_messungen_juni

Nachdem ich es trotz verzweifelter Bemühungen nicht geschafft habe, die Studie über Cloudcomputing in Deutschland von der IDC Marktforschung zu erhalten, wollte ich erst gar nicht zu dem Theam bloggen. Schade, dass ich mich dort nicht mit meinen Argumenten platzieren konnte.

Interessant insbesondere, weil dort scheinbar nur durch kurzen Augenschein überprüft wird ob man (das anfragende Unternehmen) nun Cloud-Anwender ist oder nicht. Hätten die Damen und Herren sich dort wirklich mit meinem Arbeitgeber beschäftigt, dann hätten diese sicherlich festgestellt, dass wir sogar ein ganzes Produkt über Cloud computing aufgebaut haben. Aber – es hilft jetzt auch kein mosern und weinen – ist halt so. Ich bin und bleibe studienlos.
Der Spiegel Artikel über das Thema ließ mir jedoch keine Ruhe.

Dort stolpert man nämlich schon im ersten Satz über die Todschreibung von Cloudcomputing: “Cloud Computing war einer der heißesten IT-Modebegriffe der letzten zwei Jahre“. Oha….”war” – Rest in piece.

Wie falsch der Spiegel Redakteur liegt, zeigt sich wenn man (leider nur) die Kurzfassung der Studie liest.
Immerhin 7% der befragten Unternehmen setzen die virtuelle Rechen- und Speicherkapazität ein. 7 weitere Prozent planen deren Nutzung. Das sind immerhin 14% – eine nicht geringe Menge wenn man die Probleme betrachtet, die die Studie dagegenhält:

- Kaum oder keine Referenzen
- Schwierige Implementierung
- Mangelnde Praxistauglichkeit (??)
- Mangelnde Compliance Richtlinien

Von allen 4 Hauptargumenten die genannt wurden, würde ich nur eines gelten lassen – nämlich das Argument “Compliance”. Solange es keine haltbaren SLA’s gibt, solange wird es (nicht nur in Deutschland) niemand oder nur wenige wagen, wirklich geschäftskritische Anwendungen in die Cloud zu verlegen. Gewinner wird der Anbieter sein, der es als erster wagt, verbindliche Qualitätsmerkmale anzubieten – auch schriftlich.

Das Argument “mangelnde Praxistauglichkeit” ist absolut hahnebüchend. Das kann nur jemand gesagt haben, der sich bislang noch nicht mit dem Thema beschäftigt hat (immerhin 75%) oder zu den 4% gehört, die einen Einsatz kategorisch ausschließen. Aber praxistauglich ist es auf jeden Fall – da könnte ich eine Reihe Beispiele nennen, wo es sich so dermaßen empfiehlt auf die Cloud zu setzen wie nur was. Sei es als einfacher Datenspeicher (Videoteaser zu einem neuen – vermutlich erfolgreichem Kinofilm)  oder als zusätzliche Applikationsrechenpower (Online Gewinnspiel bei einer Halbzeitpause eines Championsleague Spiels, Lotto Jackpot jenseits von gut und böse).

Schwierige Implemetierung kann ich auch nicht gelten lassen – Entweder man hat keine Zeit oder keine Lust sich mit der Thematik tatsächlich auseinanderzusetzen oder man hat einfach den Bedarf nicht. Schwierig ist die Implementierung auf keinen Fall – wenn sogar ich es schaffe mit minimalem Aufwand (<1 Tag) mir eine funktionierende Webseite in der Cloud zu basteln.

Kaum oder keine Referenzen lasse ich als Argument für die sehr konservativ ausgerichteten IT-Abteilungen gelten. Diese sind selten “Ahead of the curve” und setzen nur getestete Systeme ein. 7% in Deutschland sind jedoch Vorreiter und vertrauen auf eine Technologie, die noch nicht mit Referenzen um sich schmeißen kann.

Was die Studie offen lässt, ist der Grad der Zufriedenheit, mit dem die 7% Nutzer die Cloudtechnologie nutzen. Ich vermute, dass hier ein “überragend” zu hören ist (Erfahrungswerte).

Wie lassen sich jedoch die berechtigten Compliance-Ängste beheben? Das geht relativ einfach, indem man solche Technologien testet.
Moderne Lasttestverfahren von außerhalb der Firewall erlauben hohe Lastzahlen und können so “erwartete Peaks” simulieren. Also ein probates Mittel um eine erwartete Lastspitze (welche durch Cloud computing abgedeckt werden soll) zu simulieren und das Verhalten der Cloudservices zu testen.

Allerdings kann ich aus meinen bisherigen Tests mit den Services von Amazon und Goolge sagen, dass man nicht erwarten kann, dass die Performance dann auch der Performance von Google oder Amazon entspricht – jedenfalls nicht aus der globalen Perspektive. Zu sehr ist der Standort der virtuellen Umgebung beeinflussend. Wähle ich z. B. die Cloud stationiert in London, dann habe ich die gleichen Latenzprobleme in den USA, als wäre mein Server in Deutschland stationiert. Dort gilt es genau zu evaluieren (!!) welchen Service ich wähle und wo dieser lokalisiert ist.

Eine Frage (gerichtet an die 75% “noch nicht damit beschäftigt”) hätte ich dann doch noch: Wie viele von Ihnen nutzen “Sales Force” oder andere Software-as-a-Service-Lösungen ?
Ich vermute, einige nutzen diese Technologie bereits. Eigentlich nichts anderes als “Cloud computing”!

Es ging durch die News, dass Google’s services teilweise nicht zur Verfügung standen. Der Spiegel schreibt dazu lapidar:

“Weil Google seine Anwendungen und Rechennetze auch anderen Firmen zur Verfügung stellt, waren auch weitere Websites zeitweise nicht erreichbar.”

Der unwissende Leser denkt und glaubt: War ja nicht so schlimm. Da konnten einige ihre Emails nicht lesen – die Suche war langsamer. Was sich aber hinter “weitere Websites” verbirgt bleibt auch im Verborgenen.
Wenn man nun weiß, dass Google Services sehr umfangreich sind und wirklich häufig genutzt werden (auch hier im Blog – dieses eine Banner rechts), dann wird die Sache schon etwas “dramatischer”. Google Services sind z. B. Bannerlieferung durch Doubleclick, Bannerlieferung durch Googlesyndication und noch deutlich häufiger genutzt: Google Analytics.

Gemeinsamkeit bei allen diesen Services: Einbindung durch ein kleines Javascript welches von Google bereitgestellte Inhalte nachlädt.

Welche Einflüsse Javascript auf die Ladezeit hat, habe ich im Eintrag: Percieved Rendertime oder gefühlte Ladezeit beschrieben. Javascript verhindert, dass eine Webseite weiter geladen wird. Glück als für diejenigen, die Google Analytics als letztes Element im Quelltext einbunden haben. Die Webseite wurde fertig geladen nur auf Google wurde erfolglos gewartet. Der User hatte das Gefühl die Webseite sei fertig.

(Klicken zum Vergrößern

Pech dagegen, wer wie Bild.de schon im Header auf Google Services verwiesen hat. Da wurde dann mitunter die Webseite für bis zu 90 Sekunden nicht weitergeladen. Der normale Internetnutzer weiß nicht, dass er gerade Opfer von Google’s Ausfall wurde, sondern denkt vielleicht: “Boah, Bild geht ja heute gar nicht!”

Bei Bild ist Google schon im Header eingbunden.

Deutlich zu sehen ist, wie das Google Problem zum Bild Problem wurde. Zu dem Zeitpunkt war noch nicht ein einziges Bild im Browser geladen. Der User wartete und wartete….bis er vermutlich keine Lust mehr hatte und zu einer anderen Seite wechselte. Für Bild bedeutet das: Weniger Aufrufe, Klickrate sinkt, Umsätze sinken.
Für Webseiten, die richtig umsatzstark sind (Retailer) bedeutet solch ein Ausfall also mitunter richtig Geschäftseinbußen.

Tests haben bewiesen, dass Ausfälle wie dieser dazu führen, dass die Besucherzahl sich nur relativ langsam wieder normalisieren.

Dieser Chart zeigt einen Ausriss aus den Amerikanischen Top 30 Portalen: Namen wie Lycos und Myspace sind nicht gerade selten besuchte Webseiten, welche unter dem Fehler litten.

Bekannte US-Amerikanische Portale litten unter dem Google Ausfall. Glück, wer wie Lycos erst am Ende des Quelltextes Google eingebunden hat.

Über die Optimierung von Ladezeiten existiert schon viel Information in Englischer Sprache. Methoden gibt es viele, z. B. die Minimierung von Objekten (Anzahl, Größe), Verwendung von Kompression bei Skripten, optimierter Nutzung des Browsercaches, Verwendung von HTTP1.1 und vieles mehr. Viele Entwickler, Designer und Developer nutzen heutzutage Tools wie YSlow, Firebug oder HTTPWatch, um die Ladezeiten während der Entwicklung zu kontrollieren oder mal in der Liveumgebung zu testen.
Das ist alles schön und gut, weil es dazu beiträgt, dass die Webseiten schnell geladen werden. Eines jedoch können diese Tools nicht abbilden. Einen – wenn nicht den wichtigsten – Faktor berücksichtigen diese Applikationen nicht.

Die “percieved Rendertime” – die gefühlte Ladezeit. Es handelt sich dabei um die Zeit, die es braucht, um das Browserfenster zu füllen und dem User das Gefühl zu geben, er könne nun mit seinem Vorhaben (dem Grund seines Webseitenbesuches) beginnen.

Was es damit auf sich hat ist nicht so schnell und einfach erklärt. Ich will es aber dennoch anhand von Beispielen erklären. Herhalten als schlechte Beispiele müssen die Denic.de und die Deutsche-Bank.de.

Bevor ich aber mit den schlechten Beispielen anfange, möchte ich ein relativ einfaches Beispiel zeigen, welches die percieved Rendertime verdeutlicht. Spiegel online wird vermutlich jeder der Leser kennen. Die Webseite ist so optimiert, dass der Besucher recht schnell das Gefühl bekommt “fertig geladen” bekommt, obwohl die Webseite mit all ihren “3rd Party” Inhalten bei weitem noch nicht fertig geladen ist.

In dem kleinen Screenshot markiert die grüne Fläche den Teil, der sehr schnell nach dem Aufruf erscheint und einen Standard Laptop screen (800 Pixel Höhe) . Der Rest (incl. Banner) wird erst später geladen.

Recht undeutlich auf dem Bild aber erkennbar der “Börsen” und “Wetter” Bereich.

Im Gegensatz zum Spiegel arbeitet die Deutsche Bank nicht “pro gefühlte Ladezeit”. Ein Screenshot nach 3 Sekunden Ladezeit (und ich habe eine schnelle Anbindung) zeigt deutlich das Defizit:

Wo ist der Haupt-Eye-catcher?

Schön zu sehen – alle anderen Grafiken sind bereits geladen. In diesem Fall handelt es sich bei dem Eye-Catcher um eine relativ große Flash Datei. Verständlich, dass diese noch laden muss. Zwei Optionen gäbe es, um mir das Gefühl zu geben die Seite ist schon fertig geladen:

a) eine Grafik (Standbild) anbieten, welche durch das Flash ersetzt wird
b) eine Fortschrittanzeige einblenden – um mir zu zeigen, dass noch irgendwas passiert.

Zur Erinnerung: 40% aller Deutschen kriechen noch langsam durch das Internet. Und der ein oder andere Deutsche Bank Kunde wohnt sicher auf dem Land (ich kenne einen auf Norderney).

Gehe ich zur Analyse tiefer in die Daten und schaue mir die Ladereihenfolge an, wird schnell klar: Auch dort gibt es Optimierungsmöglichkeiten (anklicken zum Vergrößern):

kugel_blau.swf ist das zuletzt geladene Objekt

Mit 1,5 Mb zudem sehr mächtig dimensioniert – d. h. ohne Alternativgrafik wird ein User mit geringer Bandbreite sehr lange den großen leeren Bereich sehen. (Lange warten würde auch ein Businessmensch im ICE von Köln nach Frankfurth mit UMTS Verbindung).

Als Regel könnte man hier aufstellen: Die wichtigen visuellen Objekte im DOM tree so Platzieren, dass sie frühzeitig geladen werden.

Ein zweites Beispiel für Percieved Rendertime habe ich auf der neuen Denic Seite gefunden. Zufällig. Ich öffnete meine Browser – es wurde meine Standardseite geladen (about:blank) und ich gab in die Adresszeile www.denic.de ein. Dann passierte aber erst mal gar nichts – ich sah nur in der Statusleiste dass sich etwas tut. Das warten ging so 5-6 Sekunden bis dann “schwupp” alles da war. Hätte ich eine andere Seite offen gehabt, hätte ich die alte Seite noch gesehen.

Steve Souders nennt dieses Phänomen “white screen”. Verursacht wird es durch Javascripte, die im <head> Bereich der Webseite eingebunden wurden und nur sequenziell vom Browser geladen werden. Eins nach dem anderen. Sind diese Javascripte nun sehr groß, oder benötigen eine große Renderzeit, dauert es bis die Webseite weiter geladen wird.

Beispiel: Denic.de - gemessen mit einem DSL Durchsatz von 3.400 mbit/s

Die Grafik zeigt schön, wie sehr das jquery Javascript ein Weiterladen der Seite blockiert. Denic macht meines Erachtens gleich mehrere Fehler – und verlangsamt dadurch die Ladezeit der Webseite dramatisch:
1.) Jquery auf der Startseite ! (wird es dort überhaupt benötigt ?? Ich konnte keine Funktion erkennen) – Sollte es nicht besser auf der Seite erst geladen werden wo es benötigt wird ? So lädt jeder (JEDER) Besucher von Denic die kompletten 102 Kb herunter, ohne dass er sie möglicherweise benötig. Außer dass Ressourcen verschwendet werden, wird auch noch der Server unnötig belastet, die Bandbreite belastet und der Besucher belastet.

2.) Unkomprimierte Auslieferung der Scripte (CSS, Javascript) – die Webseite von Denic ist insgesamt ca. 270 kb schwer. Allein ca. 180 kb sind Javascript und CSS Dateien. Der Rest sind eh schon komprimierte  Binärdaten (Bilder). Durch die Verwendung von gzip oder mod_deflate könnten ca. 80% der Datenmenge eingespart werden,  d. h. Ressourcen werden verschwendet, der Server unnötig belastet (Socketbelegung), die Bandbreite belastet und am wichtigesten der Besucher belastet.
3.) Javascripte werden in Header eingebunden. Dadurch entsteht der “white screen” Effekt. Da kein “onload” oder “domready” Event gesetzt ist, können die Javascripte auch als letztes referenziert werden (wenn Sie denn wirklich unbedingt benötigt werden). Dann scheint Webseite fertig geladen und der User kann sein wunderbares Browseerlebnis beginnen.

Es macht also durchaus Sinn, sich Gedanken zu machen, wie etwas wo eingebunden wird. Das kann neben einem glücklichen Webseitenbenutzer auch noch Strom sparen, die Server generell entlasten und …..gute Rankings in den Suchmaschinen geben…..(kleiner Scherz)

Ein weiterer Relaunch ein weiteres Designfehlerchen. Bei Blau ist im Safari 3.2.1 und im aktuellen Google Chrome Browser ein kleines Fehlerchen vorhanden. Es ist zwar ohne weiteres mögliche einen Stick zu ordern, doch für die Benutzer der beiden genannten Browser ist solch ein Fehler sicher keine Vertrauen schaffende Maßnahme. Kann passieren – sollte aber nicht – insbesondere zum in der Presse verbreiteten Relaunch sollten zumindest alle über 1% Browser die Inhalte korrekt darstellen.

Ein kleiner Fehler, kann große Folgen haben.

Safari 3.2.1 Darstellung:

Chrome Darstellung:

Auf die Performance hatte der Relaunch einen leicht negativen Einfluss – die Ladezeit an den Backbones hat sich leicht verschlechtert.

Deutlich: Konstant, aber verändert nach dem Relaunch

Das Hamburger Abendblatt wurde einem Relaunch unterzogen. Der Designbote bewertet das Design als “nicht mehr verstaubt” und besser zu bedienen – womit er zweifelsfrei recht hat.
Aus Sicht eines Qualitätsmanagers allerding fallen kleinere Fehler auf und auch die Performance könnte etwas verbessert werden.

Bei der Qualitätsprüfung fällt auf, dass die wechselnde Newsbox auf der linken Seite nicht immer ausreichend für die Inhalte dimensioniert ist und der “pager-tabs-container” mitunter überfüllt ist.

Zuviel Text für die Box. Eine Textlängenbeschränkung und Kontrolle im Workflow des Content Management Systems sollten sinnvoll überdacht werden.

Für User mit einem schicken neuen Blackberry wird die Navigation zum Platzfresser und sieht eigenartig aus.

Versetztes Submenü - auch eine interessante Variante

Ob Bold oder Storm - bei beiden Browsern siehts komisch aus

Bei der Performance könnten noch einige Bytes rausgeholt werden, indem die CSS und Javascript Dateien cachebar gemacht werden. Obwohl sie mit einem “expires” Header versehen sind landen sie nicht im Browsercache. 70 kb weniger bewirken dann doch eine nicht nur messbare sondern auch spürbare Beschleunigung beim Ladevorgang.

Deutlich zu sehen was im Cache landet und was nicht.

Wie in den Messergebnissen ersichtlich gibt es deutliche Probleme bei der Performance der ePetitionsseite.

Ein Blick in die Messdaten verrät, dass es definitiv kein Bandbreitenproblem ist, sondern sich das Problem in der Middleware bzw. dem Backend befindet. Das bestägtigt auch die Aussage, die schon länger hier zu lesen ist

Zwei exemplarische Detailansichten von meinen Messungen weisen extrem Lange “First Byte” Zeiten für die Auslieferung des Root Objekts auf (das eigentliche HTML) auf. Was für diese Annahme spricht. Der Server weiß, was mein Browser angefragt hab, benötigt aber eine lange Rechenzeit um mir das erste Byte auszuliefern. Der Download an sich geht dann wieder schnell (wäre bei mangelnder Bandbreite deutlich länger)

Aufruf der Startseite der ePetition gegen die Sperrung von Internetseiten. Deutlich zu sehen, die extreme First Byte Zeit. Teilweise auch lange Connectzeiten. Das eine Problem bedingt das andere. Ist ein Socket des Servers lange besetzt, weil auf Daten gewartet wird, ist dieses Für andere mögliche User "besetzt" - ergo es dauert ein wenig bis eine neue Verbindung etabliert werden kann.

Auf der Registrierungsseite kommt neben der Problematik des Root Objekts ein weiteres Problem hinzu: Das Captcha.
Die Erzeugung dieses dynamischen Elements nimmt wieder eine lange Zeit in Anspruch, sodass auch hier die Auslieferung des ersten Bytes auf sich warten lässt.

First byte Wartezeit beim ersten und beim Root-objekt sowie bei der Erzeugung des Captchas.

Dedizierter Chart nur für die Auslieferung des ersten Bytes - 1st Byte Zeiten weisen oft auf ein Problem im Backendbereich hin. Selten liegt das Problem auch mal an anderweitiger Netzwerklatenzen.

Neben der 1st Byte Time gibt es allerdings auch Probleme (wenn auch weniger als von mir erwartet) mit der Connection Zeit. D. h. die Webserver scheinen fast ausreichend groß dimensioniert zu sein viele User in Empfang nehmen zu können.

Einige Ausreißer belegen, dass es nicht immer leicht ist überhaupt mit dem Server eine Verbindung zu etablieren

Ähnlich wie bei der Connection zeichnet sich das Bild für die Etablierung einer SSL verschlüsselten Verbindung.
Ist ein Server überlastet, dann kann es auch bei dem SSL Handshake zu Verzögerungen kommen. Die komplette Registrierungsseite – sowie Teile der Petitionsseite sind SSL Verschlüsselt. Das kostet Zeit.

Deutlich auch hier bei der SSL Zeit die tageszeitabhängige Schwankung.

Alle drei genannten Problem hängen unmittelbar zusammen: Ist ein Socket wegen langer 1st Byte Zeit lange belegt (und muss der Rechner lange rechnen), dann schwitzt der Server schon mit dem connection handling (was wiederum dazu führen kann, dass der Server noch länger rechnen muss). Wird on top auch noch die Rechenleistung für SSL Verschlüsselung benötigt, dann kann es schnell passieren, dass ein User 60 Sekunden darauf wartet dass die Webseite endlich fertig geladen ist.

Ein meiner Meinung nach wunderschönes Beispiel, wie wenig der Webseitenbesucher noch interessiert, habe ich gerade auf der Finanznachrichten.de Webseite gefunden.

Das Wort User wird exakt einmal in dem Bericht erwähnt ! Wow – aber nicht ob er die Webseite besucht, sondern welche Keywords er eingibt.

Wenn ich so etwas lese, dann würde mich in der Tat interessieren, ob es wohl möglich ist eine Webseite so SEO zu optimieren, dass sie unter die ersten 10 Plätze bei Google fällt, obwohl sie noch nie ein Mensch besucht hat?

Ich halte SEO für wichtig – keine Frage. Aber vielleicht sollte man den Businessfokus (der definitiv dahinter steht) etwas in den Vordergrund rücken. Ein Satz wie: Ein gutes Ranking heißt, dass ein User die Webseite schneller in Suchergebnissen vorgeschlagen bekommt und dadurch wahrscheinlicher wird, dass mehr Besucher auf der Webseite zu erwarten sind.

Das weiß zwar jeder, der auch nur ein bisschen Ahnung vom Internet hat auch so, nur empfinde ich es als ganz schrecklich, wenn SEO nur mit einem optimalen Ranking belohnt wird und nicht nach der dadurch gestiegenen Anzahl der Besucher.

Wie schon gesagt: Ich habe das Gefühl, dass der User aus dem Gesichtsfeld rückt. SEO über alles lautet die Parole. Bezahlt wird nach dem Grad der Optimierung – egal ob das auch nur einen einzigen Webuser mehr gebracht hat oder nicht……

[Edit 07.06.2009] Der Wahnsinn schein Methode zu haben…..Hauptsache Robots kommen zurecht und hier….Keinmal User – einmal Besucher (wobei der auch nur Cookies akzeptieren soll)!

Grundgesetz für die Bundesrepublik Deutschland vom 23. Mai 1949 (Bundesgesetzblatt I Seite 1)

Artikel 17

Jedermann hat das Recht, sich einzeln oder in Gemeinschaft mit anderen schriftlich mit Bitten oder Beschwerden an die zuständigen Stellen und an die Volksvertretung zu wenden.

Ich gehe hier der Frage nach – kann “Jedermann” von diesem Grundrecht auch Gebrauch machen.

Die Startseite zur Petition gegen Sperren von Internetseiten ist nach Messungen von mir schlecht bis gar nicht verfügbar.

[EDIT 07.05.2009, 12:30 Uhr]Warum das so ist erklärt ein wenig dieser Chart[/EDIT]

Wer sich nur für die Anzahl der Petitionszeichner interessiert bitte hier klicken: http://sejmwatch.info/petition-internet-zensur.html

Messungen zeigen, dass die Performance im Tagesverlauf deutliche Ladezeiteinbrüche aufweisen. Dieses gilt sowohl für die Startseite der Petition als auch für die Registrierungsseite. Eine Registrierung ist nötig um sich an der Petition zu beteiligen.

Messungen aus den Backbones in Deutschland

Die Frage die ich mir stelle – wird dadurch die Menge der Teilnehmer möglicherweise beeinflusst ?

Zudem ist die Erreichbarkeit deutlich eingeschränkt. Mehr als jeder zehnte Besucher konnte die Webseite nicht innerhalb von 120 Sekunden öffnen.

Performance und Verfügbarkeit aus der Endbenutzersicht

Update: 20:47 Uhr 05. Mai 2009

Schwer zu der Performance zu sagen, ohne dass es politisch klingt. Ohne Partei ergreifen zu wollen: Das ist unterirdisch und habe ich in meiner ganzen beruflichen Zeit (im Bereich Web-Performance) noch nicht gesehen!

Performance entspricht nicht den Erwartungen.

Update: 06.05.2009 14:00

06.05.2009 - Status Quo

Update: 06.05.2009 20:00

Langsam aber weitestgehend verfügbar. Eine Limitierung auf 15 Einträge pro Minute scheint es nicht zu geben.

Update: 07.05.2009 12:00 Uhr

Nachts gut, Tagsüber optimierungsbedürtig - Status Quo

Update: 07.05.2009 20:00 Uhr

Leichte Besserung in der Ladezeit. Die Anzahl der Zeichner pro Minute nimmt ebenfalls ab.

Update: 08.05.2009 21:00 Uhr (keine weiteren Updates dieses Wochenende (Sonntag abend nächste Aktualisierung)

Massive Probleme heute. Problematisch: Verfügbarkeit nicht garantiert

Update: 10.05.2009 17:00 Uhr – weniger Belastung am Wochenende – dennoch deutliche Performance Schwankung.

Nach einem schwarzen Freitag ein relativ ruhiges Wochenende

Update: 11.05.2009 20:00 Uhr – Der run scheint sich fürs erste gelegt zu haben. Die Performance ist besser.

Leichter Performanceeinbruch über den Montag. Keine so heftigen Ausreißer mehr.

Update: 12.05.2009 19:30 Uhr – relativ entspannte Lage auf dem Server im Vergleich zur letzten Woche.

Entweder die Anfragen an den Server haben sich unter die kritische Menge bewegt oder aber es wurde etwas an der Performanceschraube gedreht.

Update: 13.05.2009 23:00 Uhr -  keine großartigen Veränderungen. Ich werde nur noch aktualisieren sollte sich etwas aufregendes ergeben.

Von guter Performance zwar noch immer keine Rede aber keine großen Auffälligkeiten mehr

Update: 20.05.2009 09:00 – Keine großartige Veränderung mehr.

15.06.2009: Über die letzten 21 Tage zeigt sich eine durchgehende inkonsistente Performance. Allerdings ohne dauerhafte Performanceausbrüche. Angenommen es würde sich bei der Petitionsseite um einen Shop handeln könnte davon ausgegangen werden, dass dieser wenig Erfolg hätte. Wartezeiten wie bei der Petitionsseite werden heute nicht mehr von den Internetusern toleriert.

Schwankende Performance - besonders im Tagesverlauf, trotz geringerer Last, geht die Performance zurück

Update: 15.06.2009 22:13
Eigentlich wollte ich diesen Eintrag auf Eis legen, doch dank Tobi und Q wurde ich darauf hingewiesen, dass die Petitionsseite wohl in der Performance wieder deutlich zurück geht. Anders als in den Messungen vorher leidet dieses Mal auch die Erreichbarkeit deutlich. D. h. selbst wenn Internetuser die Petition zeichnen wollen können Sie es nicht. Die Seite ist schlichtweg nicht erreichbar.

Thema schon abgehakt und nun dieses. Zweite Welle ?

Update: 16.06.2009 (Übersicht von gestern 15.06.2009 12:00 bis 15.06.2009 23:59 Uhr

Verfügbarkeit an Backbones nur 86% – Ladenzeiten bis über 1 Minute. Es darf berechtigt hinterfragt werden wieviele Zeichnungsversuche in Frustration geendet sind, oder wieviele gar nicht stattfinden konnten.

Frage: Gibt es eine gesetzliche Pflicht Petitionen zu ermöglichen und auch die Zeichnungsmöglichkeiten sicherzustellen?

Hosteurope überarbeitet den Webauftritt und ist etwas “verrückt”

Stellt sich die “Startseite” noch zentriert im Browser dar, führt der Klick auf “Unternehmen” auf eine Webseite, die sich am linken Bildschirmrand drängt (so wie alle weiteren Seiten auch). Die Frage sei erlaubt ob das absichtlich so ist oder ob es sich dabei um ein versehen handelt. Es ist allemal verwirrend.

Hosteurope verrückt nach dem ersten Klick die Ausrichtung

Die Schatten (welche ich persönlich sehr schick finde) werden im populären Internetexplorer 7 nicht korrekt dargestellt, was jedoch nicht auffällt, wenn man die Webseite nur mit einem Browser öffnet.

Kann man mehr von Profis erwarten ? Ich meine ja.

Update: Auf Anfrage an das Qualitätsmanagement erhielt ich folgende Mail

“das besagte Phänomen existiert bereits seit Anfang 2007. ”

Auch schön – über Geschmack lässt sich ja bekanntlich nicht streiten…..

Update 2: Jetzt alles zentriert….

Download der gesamten Screen Captures (IE6, 7, 8, Chrome, Safari 3, 4, Firefox (Linux, MS XP), Opera 9,62)