Main /

Performance

Allgemein

Knowledge Base

Virtualisierung Emulation

Technik und Wissen

Community

Privat

%center%[[http://validator.w3.org/check?uri=referer|http://www.w3.org/Icons/valid-xhtml10.png]]%%

Performance

Was ist Performance

Aus der Sicht eines Web-Software-Entwicklers.

Performance ist eine gefühlte Größe. Ein Computerprogramm ist schnell, wenn es die gestellte Aufgabe in sehr kurzer Zeit abarbeitet.

Ein Computer-Programm reagiert träge wenn:

  1. Der Bildaufbau sehr schleppend abläuft, weil z.B.
    1. Das Dokument sehr groß ist, das angezeigt werden soll
    2. kleinen Bilder erst im Browser skaliert werden, dann werden sehr viele unnötige Daten vom Server geholt.
    3. es sehr viele Anfragen an den Server gibt weil
      1. es sehr viele kleine CSS Dateien gibt
      2. es sehr viele kleine JS Dateien gibt
      3. es sehr viele kleine Bilder gibt
  2. wenn jeder Tastendruck eine Rückfrage an den Server bedeutet und der Server erst in 0.5sec antwortet. Das klingt sehr schnell, aber wenn man erstmal merkt, das 2 Zeichen eintippen 1 Sekunde brauchen, wird die Sache sehr lästig.
  3. wenn ein Wechsel auf die nächste Seite nicht sofort gestartet wird.

Dann spricht man gerne davon, das Programm reagiert träge, oder die Performance ist schlecht.

Verbesserungsmöglichkeiten oder Optimierungen

Das ist alles kein Hexenwerk, es sind nur ein paar simple Ideen, die aber reichen sollten die gefühlte Performance anzuheben.

Das Dokument ist sehr groß
da stellt sich die Frage, ob es nötig ist immer das ganze Dokument zu liefern oder ob es reicht das Dokument in einzelne Seiten zu zerlegen und diese dann auszuliefern. Es wird also nur ein kleiner Teil des gesamten Dokuments gezeigt, von der Komplexität der Verwaltung solcher zeige nur Teile ist hier nicht die Rede.
kleinen Bilder nicht erst im Browser skalieren
es gibt genügend Programme, die Bilder auf exakt die Größe skalieren, die man benötigt, das geht auch per Batch Programm. Zudem kann man bei Fotos die Qualität runterschrauben (70% statt 90%) was gerade bei Jpeg sehr viele Bytes spart, man kann immer noch im letzten Schritt einen extra Link anbieten, der Bilder dann in höchste Qualität liefert.
es gibt sehr viele kleine CSS Dateien
Es gibt Programme wie SASS, die CSS Dateien zusammenfassen können, dann wird statt vielen CSS Dateien nur noch eine CSS Datei geliefert, diese kann zusätzlich von Whitespaces befreit werden. Ok, SASS kann noch mehr, aber das ist hier nicht relevant.
es gibt sehr viele kleine JS Dateien
Auch hier gibt es genügend Programme, die alle JS Dateien zu einer oder wenigen Dateien zusammenfassen.
es gibt sehr viele kleine Bilder
Hier könnte man über Sprites nachdenken, dann gibt es nur noch ein großes Bild, das geladen werden muss und zusätzliche CSS Regeln um an die einzelnen Bilder zu kommen, allerdings sagt die Erfahrung, das der Erstellungsprozess für den Sprite nicht zu kompliziert werden sollte, sonst könnte das Performanceziel durch die Komplexität zunichte gemacht werden.
weitere Tipps für viele Dateien
Verwendet einen Cache für statische Daten, wie CSS, JS, Bilder wie z.B. Varnish, dann muss nicht erst der Apache/Tomcat die Daten liefert
wenn jeder Tastendruck eine Rückfrage an den Server bedeutet
Generell sollte man die Kommunikation mit dem Server stark einschränken. Wenn ein Benutzer das Programm verwendet mag das vertretbar sein, wenn aber viele Benutzer gleichzeitig Anfragen an den Server stellen, wir das eine Herausforderung. Mit Wicket z.B. sollte man erst nach Verlassen eines Inputfeldes (onBlur) mit dem Server kommunizieren. Bei AngularJS? reicht es erst mit dem Server zu kommunizieren, wenn das Formular an den Server geschickt wird. Wenn die Prüfung der Eingabedaten kompliziert und langwierig ist, zerlegen sie die Eingabe in mehrere Felder und prüfen weniger. Lassen sie IMMER den Server die Prüfung der Eingabedaten nochmal machen, egal wie kompliziert es ist. Das ist sonst ein Sicherheitsproblem.
wenn ein Wechsel auf die nächste Seite nicht sofort gestartet wird
Sollte evtl. ein sog. Throbber oder ein animiertes Gif gezeigt werden. Beim Druck auf einen Button sollte immer sofort etwas passieren und sei es die Seite ist leer und zeigt kurz 'einen Moment bitte, die Daten werden verarbeitet.' Zeigen sie solche Seiten aber nicht zu kurz (<2 sek. sind solche Seiten nicht nötig) und zeigen sie solche Seiten nicht zu lang (>6 sek. wird es nervig)

Die obigen Verbesserungen reichen meist schon aus, um die gefühlte Performance zu steigern.

Liefere Daten sparsam
Es sollten so wenig Daten(Bytes) wie möglich geliefert werden, also prüfe, wie viele Daten (in Kilobytes) pro Anfrage eigentlich geliefert werden. Sind es nur ein paar wenige Kilobytes sind obige Tipps hilflos. Sind es aber mehrere 100 Kilobytes, können die obigen Ideen helfen.

Rechenbeispiele: Wir liefern 300 Kilobytes große Seiten und haben einen Upload von

1Mbit/s
sind ~100 Kilobytes/s, heißt wenn man alleine die Seite lädt, braucht diese min. 3 sek. bis die Daten beim Benutzer-Client sind, bei mehreren Benutzern teilt sich das dann noch auf, bei 5 Nutzern gleichzeitig dauert es min. 5x so lange also min. 15 sek bis die Daten beim Benutzer sind.
10Mbit/s
sind ~1000 Kilobytes/s, heißt wenn man alleine die Seite lädt, braucht diese min. 0.3 sek. bis die Daten beim Benutzer-Rechner sind.
40Mbit/s
sind ~4000 Kilobytes/s, heißt wenn man alleine die Seite lädt, braucht diese min. 0.075 sek. bis die Daten beim Benutzer-Rechner sind. Das klingt sehr schnell, hängt aber immer davon ab, wie viele Nutzer gleichzeitig die Leitung belasten.

Wenn die obigen Ideen schon ausgeschöpft sind, geht es ans Eingemachte, dann muss der Hotspot gefunden werden, der für die Trägheit sorgt, denn es bringt wenig, eine Funktion zu optimieren, wenn diese nur einmal aufgerufen wird und danach nie wieder.

Links

Frische Änderungen (All) | Edit SideBar Zuletzt geändert am 05.01.2016 09:21 Uhr Seite Bearbeiten | Seitenhistorie
Powered by PmWiki