ArticlePDF Available

Latenz und Wartezeiten bei WWW-Anwendungen

Authors:
  • AIS San Marino

Abstract

Latency and waiting times in web applications. Keywords: Distributed applications, latency, web, optimization. Abstract: Designers of web applications are given a catalogue of techniques to optimize their applications for latency. Significant improvement of responsiveness, especially over large distances between the computers involved, is possible. Part of these techniques is applicable to existing applications.
____________________
grkg / Humankybernetik
Band 52 · Heft 1 (2011)
Akademia Libroservo / IfK
____________________
Latenz und Wartezeiten bei WWW-Anwendungen
______________________________________________________________________
Latenz und Wartezeiten bei WWW-Anwendungen
von Reinhard FÖSSMEIER, Akademio Internacia de la Sciencoj (AIS) San-Marino
1 Einleitung
Bei interaktiven Anwendungen ist die Latenz zu einem wichtigen Begriff an der
Schnittstelle von Technik und Ergonomie geworden. Als Latenz oder Verzögerung einer
Anwendung bezeichnet man die Zeit, die von einer Aktion des Benutzers bis zur An-
kunft der Reaktion der Anwendung vergeht, also die Wartezeit des Benutzers. Bei ver-
teilten Anwendungen, beispielsweise in Client-Server-Technik, setzt sich diese Warte-
zeit aus drei Teilen zusammen:
Der Applikations-Server braucht zur Bearbeitung der Anfrage eine bestimmte
Verarbeitungszeit tp, die sich aus seiner Leistungsfähigkeit und der Komplexität
der Anfrage bestimmt. Dieser Zeitbedarf lässt sich durch den Einsatz von leis-
tungsfähigeren oder parallel arbeitenden Maschinen (Cluster-Bildung) verringern.
Auch neue technische Entwicklungen spielen hier eine Rolle. So kann etwa die
gefürchtete Verzögerung, die bei Java-Servern durch eine Speicherbereinigungs-
Phase entstehen kann, durch neue Techniken in Grenzen gehalten werden (Gousi-
os/Karakoidas/Spinelis 2006).
Für die Übertragung zunächst der Anfrage und dann der Ergebnisse über die Ver-
bindungsleitung ist eine bestimmte Zeit erforderlich. Entsprechend dem Datenum-
fang M und der Kapazität C der Verbindung, also der pro Zeiteinheit übertragba-
ren Datenmenge, ergibt sich ein Zeitbedarf von tu = M/C. Auch dieser Zeitbedarf
lässt sich durch technische Mittel, wie den Einsatz breitbandiger Verbindungen,
Bündelung von Verbindung und Kompression der Daten, beeinflussen.
Zu diesem Zeitbedarf addiert sich die Laufzeit tw des Signals über die Verbindung,
also die Zeit, die vom Absenden des ersten Datenelements bis zu dessen Ankunft
vergeht. Auch diese Laufzeit wird als Latenz (der Kommunikationsleitung) be-
zeichnet. Sie stellt neben der Kapazität die zweite wichtige Kenngröße einer Ver-
bindung dar. Im Gegensatz zur Kapazität ist sie durch technische Mittel nur sehr
eingeschränkt beeinflussbar.
Die Summe aus tu und tw stellt die Übertragungszeit eines Vorgangs dar. Sie hängt
von der Datenmenge, der Leitungskapazität und der Leitungslatenz ab und geht in einen
typischen Interaktionsvorgang zweimal ein, für den Hin- und den Rückweg der Daten.
Während sich C und damit tu durch technische Mittel beeinflussen lassen, sind der Lei-
tungslatenz tw physikalisch untere Grenzen gesetzt.
Laut einer Studie im Auftrag der Firma Symantec vom Juli 2006 verbringen die An-
wender verteilter Applikationen im Durchschnitt 24 % ihrer Arbeitszeit mit Warten auf
eine Reaktion ihrer Anwendung. Auch wenn man für diesen Wert starke Schwankungen
je nach Art der Applikation annehmen muss, ist die Latenz also ein ernstzunehmender
Faktor in der Ergonomie verteilter Anwendungen.
25
Reinhard Fößmeier
______________________________________________________________________
Eine Gartner-Studie (Fabbi 2004) schätzt, dass in einem Netz mit C = 128 Kb/s die
Hälfte der Wartezeiten durch Leitungslatenz tw verursacht wird. Obwohl hier pauschal
von application delay gesprochen wird, ist vermutlich nur die Übertragungslatenz (ohne
die Verarbeitungszeit tp) gemeint, also tw =(tu + tw)/2, woraus sich tu = tw ergibt. Diese An-
nahme wird bestätigt durch den Hinweis in der Studie, dass bei einer Erhöhung von C
um einen Faktor 16 auf 2 Mb/s der Anteil von tw auf 95 Prozent wächst, denn das ergibt
sich näherungsweise aus der Annahme tu = tw:
tu = tw tw / (tu/16 + tw) = 16/17 = 0,941
Je mehr also die Kapazität der Leitungen wächst und damit tu sinkt, desto größer
wird der relative Einfluss der Leitungslatenz tw. Bei weltweit eingesetzten Geschäftsan-
wendungen international arbeitender Konzerne und Organisationen kann man in der Re-
gel von einer ausreichenden bis guten Kapazität der Verbindungen ausgehen. Während
sich Optimierungsmaßnahmen bei Netzauftritten für ein breites Publikum vielfach auf
die Verringerung von tu durch Minimierung der übertragenen Datenmengen konzentrie-
ren (King 2003), rückt hier die Latenz in den Vordergrund.
Verteilte Anwendungen stützen sich immer häufiger auf das Protokoll HTTP und auf
verbreitete WWW-Browser und HTML-Formulare als Client-Umgebung. Die Server-
Seite bilden dann meist Applikations-Server auf J2EE- oder .NET-Basis. Daher ist es
von Interesse, welche Grundsätze in diesem Umfeld zu beachten sind, um Latenzzeiten
in Grenzen zu halten. Der vorliegende Beitrag versucht eine Klassifizierung und Be-
schreibung der wichtigsten Techniken.
2 Typische Signallaufzeiten im Internet
Da auf der Erdoberfläche einfache Punkt-zu-Punkt-Entfernungen bis 20.000 km auf-
treten und Kommunikationsleitungen nicht immer den direkten Weg nehmen können,
ergeben sich bereits durch die Lichtgeschwindigkeit Signallaufzeiten von mindestens
140 ms (hin und zurück). In der Praxis ist mit mehr als dem doppelten Wert zu rechnen.
Noch längere Zeiten ergeben sich bei Netzzugang über Nachrichtensatelliten, der daher
möglichst zu vermeiden ist.
Tabelle 1 zeigt, dass bei Verbindungen um den halben Globus herum zehnmal so
lange Laufzeiten auftreten wie etwa innerhalb Deutschlands. Die Zeiten wurden mit
dem Kommando ping gemessen. Es wurden von jeweils vier Messwerten der größte eli-
miniert (potentieller Ausreißer) und die anderen drei gemittelt.
Bei jedem Zugriff vom Browser-Client auf den Server muss selbstverständlich eine
solche Hin-und-Zurück-Laufzeit („round-trip“) gewartet werden. Bei vielen WWW-
Anwendungen sind aber zwei oder mehr Kommunikationsvorgänge zum Aufbau eines
Anwendungsdialogs erforderlich, wodurch sich die Zeiten verdoppeln oder vervielfa-
chen. Dieses Phänomen wird als Ping-Pong-Effekt bezeichnet und ist nach Möglichkeit
zu vermeiden, da es zu schlechter Arbeitseffizienz und, wie [Syma06] ausführt, zu Frus-
tration bei den Anwendern führt. Nielsen (Nielsen 2000) gibt an, dass bereits bei einer
Wartezeit von einer Sekunde eine kritische Grenze liegt, bei der die Aufmerksamkeit
26
Latenz und Wartezeiten bei WWW-Anwendungen
______________________________________________________________________
des Anwenders nachlässt. King (King 2003) führt aus, dass lange Wartezeiten dem An-
wender ein Gefühl des Ausgeliefertseins (fehlende Kontrolle über das System) geben.
Land Adresse Zeit in ms
Deutschland www.bmw.com 25
www.uni-hamburg.de 39
Portugal www.cm-lisboa.pt 63
Russland (Moskau) www.mos.ru 87
USA, Ostküste www.suny.edu 116
www.ci.miami.fl.us 147
USA, Westküste www.tomsawyer.com 199
arachne.berkeley.edu 181
Japan hit-u.ac.jp 299
www.tokyometro.jp 283
Neuseeland www.airnz.co.nz 344
standards.co.nz 362
Tabelle 1: Ping-Zeiten bei Zugriff aus Süddeutschland
3 Techniken zur Verminderung der Latenz-Auswirkungen
Diverse Hersteller bieten spezielle Hard- oder Software zur Reduzierung von La-
tenzauswirkungen an, beispielsweise „Branch-Office-Boxes“, die zwischen das Internet
und das lokale Netz einer Zweigstelle geschaltet werden (siehe Skorupa 2005). Durch
Anwendung einiger elementarer Techniken lassen sich aber auch ohne solche Hilfsmit-
tel gute Ergebnisse erzielen. Solche Techniken sind nachfolgend beschrieben.
Einige der beschriebenen Techniken wirken sich auf die Struktur der Anwendung
aus und müssen daher bereits beim Entwurf der Anwendung berücksichtigt werden; an-
dere sind auch nachträglich bei fertigen Anwendungen einsetzbar.
3.1 Vermeidung von Latenzkaskadierung
Bestimmte Techniken der WWW-Programmierung führen zu einer Kaskadierung
von HTTP-Anfragen, wodurch sich die Latenzzeiten akkumulieren. Es ist nicht unge-
wöhnlich, dass dadurch Wartezeiten vom Sechs- oder Achtfachen der Leitungslatenz tw
auftreten. Fabbi (Fabbi 2004) hält Datenformate wie XML und HTML für ungeeignet
für verteilte Anwendungen, da sie diesen Ping-Pong-Effekt begünstigen. Die Formate
sind aber nicht pauschal zu verdammen; es kommt lediglich darauf an, einen möglichen
Ping-Pong-Effekt rechtzeitig zu erkennen und nach Möglichkeit zu vermeiden.
Generell entstehen solche Situationen, wenn ein vom Server zum Client übertrage-
nes Ergebnis sofort eine neue Server-Anfrage verursacht, weil das Ergebnis unvollstän-
dig war. Dafür gibt es eine Reihe möglicher Ursachen. Wichtige Beispiele sind:
Grafiken (Bilder) in HTML-Seiten: Die Grafik kann erst geladen werden, wenn
der HTML-Text angekommen ist, da er den Namen der Grafik enthält. Mehrere
im selben Dokument referenzierte Grafiken können parallel geladen werden, füh-
ren also nicht zu einer weiteren Erhöhung der Wartezeit durch Latenz.
27
Reinhard Fößmeier
______________________________________________________________________
Style-Skripten (style sheets) in HTML- oder XML-Dokumenten; auch hier kann
ein Skript erst geladen werden, wenn sein Name aus dem Dokument bekannt ist.
Und auch hier können mehrere im selben Dokument referenzierte Skripten paral-
lel geladen werden.
ausführbare externe Skripte in HTML-Dokumenten, z. B. JavaScript
externe Datenquellen („Datenanbindung“ über datasrc/datafld; vgl. (Rollmann
1997) und (Westermann 2002), „Programming with XML“)
inkludierte Skripte in inkludierten Skript-Dateien
Rahmen (frames oder iframes) in HTML-Seiten
Die Kategorien Style-Skripten und Rahmen sind besonders bedeutsam, da sie durch
Rekursion mehr als eine Kaskadenstufe von Server-Zugriffen verursachen können: So-
wohl das Inkludieren von Skripten als auch das Zusammensetzen von Rahmen lassen
sich beliebig schachteln.
3.1.1 Vermeidung von Rahmen-Strukturen
Manchmal ist die Technik, Dialogmasken in Rahmentechnik aufzubauen, nützlich,
da unveränderte Rahmen bei einem Dialogwechsel nicht neu übertragen zu werden
brauchen. Bei Verbindungen mit geringer Übertragungskapazität verringert die gesparte
Übertragung den Zeitbedarf deutlich.
Andererseits wirkt sich die Rahmentechnik negativ aus, wenn mehrere Rahmen-
Ebenen übertragen werden müssen. Die Übertragung der inneren Rahmen kann dann
erst beginnen, wenn der umfassende Rahmen vollständig übertragen ist, da vorher die
Adressen der inneren Rahmen nicht bekannt sind. Das bedeutet, dass pro Rahmenebene
die vollständige Zeit für den Weg zum Server und wieder zurück erforderlich ist.
Während größerer Datenumfang durch breitbandige Verbindungen kompensiert wer-
den kann, sind der Latenz durch die Physik untere Grenzen gesetzt. Daher ist die Rah-
men-Technik bei dialog-orientierten Anwendungen über weite Entfernungen eher zu
vermeiden.
Ein Kompromiss besteht darin, das Neuladen mehrerer Rahmen nicht über einen
übergeordneten Rahmen, sondern gezielt auf der innersten Rahmenebene anzustoßen,
was mit Hilfe von JavaScript möglich ist. Bild 1 zeigt das an einem Beispiel: Bei (A)
wird zunächst das Dokument seite_2.html geladen, das seinerseits ein Laden der Rah-
mendokumente links_2.html und rechts_2.html anstößt; es sind also zwei Schritte erfor-
derlich. Bei (B) dagegen bleibt der äußere Rahmen bestehen, und nur seine beiden Be-
standteile (links und rechts) werden neu geladen, was in einem einzigen Schritt gesche-
hen kann. Allerdings ist der Einsatz von JavaScript in Geschäftsanwendungen oft unbe-
liebt, da es große Verhaltensunterschiede zwischen verschiedenen Browser-Typen gibt.
seite_1.html
<frameset cols="50%,50%">
<frame src="links_1.html" name="links">
<frame src="rechts_1.html" name="rechts">
</frameset>
seite_2.html
<frameset cols="50%,50%">
<frame src="links_2.html" name="links">
<frame src="rechts_2.html" name="rechts">
</frameset>
28
Latenz und Wartezeiten bei WWW-Anwendungen
______________________________________________________________________
(A) Verweis auf
neue Rahmenstruk-
tur
Zu <a href="seite_2.html"
target="_top">Seite 2</a> gehen
(B) Setzen der Rah-
meninhalte über Ja-
vaScript
<script>
function seite2() {
parent.links.location='links_2.html';
parent.rechts.location='rechts_2.html';
}
</script>
Direkt zu
<a href="javascript:seite2();">Seite 2</a>.
Bild 1 Zwei Techniken zum Weiterblättern in Rahmen
3.1.2 Vermeidung kaskadierender Skripten
Das client-seitige Inkludieren von Skripten in HTML-Seiten ist im Prinzip sinnvoll,
da es die mehrfache Übertragung häufig gebrauchter Skripten einspart. Um jedoch kas-
kadierende Abfragen zu vermeiden, sollten Skripte keinesfalls weitere Skripte inkludie-
ren (Bild 2). Alle Inkludier-Anweisungen sollten in der obersten Stufe enthalten sein
(Bild 3).
Bild 2 Kaskadierende Inklusion bei Style-Sheets
Dieses Vorgehen widerspricht zwar manchmal einem strukturierten Aufbau von
Skripten, aber hier geht es ja nicht um den vom Entwickler verfassten Kode, der durch-
aus ähnlich aussehen kann wie in Bild 4, sondern um die im Netz übertragenen Inhalte.
Moderne Server können zwischen diesen beiden Welten Brücken schaffen, die beide
Seiten befriedigen. Beispielsweise kann die HTML-Seite aus einer JSP-Datei erzeugt
werden, in der ein Custom-Tag die Inklusionsketten durch die Skript-Dateien hindurch
verfolgt, dabei die Namen der Dateien aufsammeln und entsprechende Include-Anwei-
sungen in der HTML-Seite generiert.
JavaScript wird oft als ungefährlich bezüglich Lizenz-Kaskadierung angesehen, da
es keine Inkludieranweisung besitzt und also keine geschachtelte Inkludierung unter-
stützt. Allerdings ist es möglich, in JavaScript beliebige DOM-Strukturen dynamisch
aufzubauen, auch Javascript-Blöcke. Solche Techniken sind im Interesse kurzer Ant-
wortzeiten zu vermeiden und werden daher hier nicht näher erläutert.
Henderson (Henderson 2006) beschreibt eine Technik, mit der sich die von einer Sei-
te inkludierten Skripten zu einem einzigen zusammenfassen lassen, so dass nur ein ein-
ziger Server-Zugriff notwendig wird. Das ist nicht zuletzt deshalb wichtig, weil Browser
üblicherweise nur eine begrenzte Anzahl von Server-Zugriffen parallel ausführen.
29
Reinhard Fößmeier
______________________________________________________________________
Bild 3 Vermeidung kaskadierender Inklusion
3.1.3 Einsparen von Grafiken
Auch Grafiken, die in HTML-Seiten eingebettet sind, können erst dann vom Server
angefordert werden, wenn die umgebende Seite geladen ist, und verursachen damit
einen eigenen Latenz-Zyklus.
Nun haben viele eingebettete Grafiken durchaus ihren guten Sinn; manche Anwen-
dungen verwenden jedoch Grafiken als Schaltflächen, was zwar oft ansprechend aus-
sieht, aber eben zusätzliche Server-Zugriffe verursacht. Optisch ansprechende Schaltflä-
chen lassen sich jedoch auch als Hyperlinks gestalten, deren Farbgebung und Verhalten
bei Mausberührung und Mausklick über CSS-Skripten (Style-Sheets; vgl. Meyer 2005)
festgelegt wird. Solche Schaltflächen verursachen keine zusätzlichen Server-Zugriffe.
3.1.4 Einbetten von Grafikdaten
Für nicht allzu umfangreiche Grafiken gibt es die Technik der Data-URLs
(RFC2397), mit denen sich Grafikdaten direkt in HTML-Text einbetten lassen. Dadurch
sind die Grafikdaten nach der Übertragung der Seite sofort verfügbar. Ein Nachteil die-
ser Technik ist, dass sie jede Art von Caching der Grafikdaten verhindert. Der Haupt-
nachteil ist derzeit jedoch, dass der weit verbreitete Internet-Explorer von Microsoft sol-
che Data-URLs erst ab Version 8 unterstützt.
3.2 Caching und Replizierung
Unter bestimmten Umständen lassen sich Kommunikationsvorgänge dadurch ver-
meiden, dass man Kopien von Inhalten anlegt. Dabei ist zu unterscheiden zwischen der
Speicherung angeforderter Inhalte (Caching) und der vorsorglichen Replizierung.
3.2.1 Caching von statischem Inhalt
Das Protokoll HTTP (RFC2616) ermöglicht es einem Client, lokale Kopien von be-
suchten WWW-Seiten zu halten. Moderne WWW-Browser nutzen diese Möglichkeit
und vermeiden so unnötige Datenübertragungen. WWW-Seiten mit dynamischem In-
halt, zum Beispiel Seiten mit dem Ergebnis einer Datenbank-Abfrage, können von die-
sem Mechanismus nicht profitieren; für sie muss das Caching ausdrücklich ausgeschlos-
sen werden.
Für unveränderliche oder selten veränderte Teile, den so genannten statischen Inhalt,
ist das Caching sehr nützlich. Es ist allerdings zu beachten, dass der Browser üblicher-
30
Latenz und Wartezeiten bei WWW-Anwendungen
______________________________________________________________________
weise, bevor er ein Dokument (eine Ressource) aus seinem Cache verwendet, beim Ser-
ver nachfragt, ob sich dieses Dokument inzwischen verändert hat. Falls ja, wird in der
Antwort sofort ein aktueller Stand des Dokuments mitgeschickt.
Auch wenn das lokal vorhandene Dokument aktuell ist, erfordert das Nachfragen
beim Server einen vollständigen Zugriffszyklus zwischen Client und Server. Der Server-
Zugriff wird dadurch also nicht eingespart; nur der Umfang der Antwortdaten ist sehr
gering, wenn keine Änderung erfolgt ist.
Bei Ressourcen, die sich nur sehr selten ändern, lässt sich allerdings die Rückfrage
beim Server tatsächlich einsparen. Dazu muss der Server beim ersten Zugriff auf die
Ressource eine „Verfallszeit“ mitgeben. Damit drückt er aus, dass die Ressource auf je-
den Fall eine bestimmte Zeit gültig ist. Innerhalb dieser Zeit braucht ein Client wegen
dieser Ressource nicht beim Server nachzufragen. Der dadurch erzielte Zeitgewinn kann
erheblich sein.
Die Angabe einer Verfallszeit erfolgt in den HTTP-Kopfzeilen durch die Anweisung
Expires:“. Der verbreitete HTTP-Server Apache besitzt einen Mechanismus, um eine
solche Kopfzeile zu setzen. Dazu dienen die Konfigurationsanweisungen ExpiresActive,
ExpiresDefault und ExpiresByType aus dem Modul mod_expires. Bild 4 zeigt ein kom-
mentiertes Beispiel einer solchen Konfiguration.
Konfigurationsdatei .htaccess
# Verfallszeiten aktivieren:
ExpiresActive on
# Bilder erhalten 1.000.000 Sekunden
# (etwa 11,6 Tage) Gültigkeit ab Zugriff:
ExpiresByType image/gif A1000000
ExpiresByType image/png A1000000
ExpiresByType image/jpeg A1000000
Bild 4 Konfiguration von Verfallszeiten für Apache
Wenn sich nun eine solche Ressource doch einmal ändert, ergibt sich der Nachteil,
dass die Clients während der Verfallszeit noch ihre gespeicherten Kopien verwenden, al-
so nicht die aktuelle Version. Dieses Problem lässt sich aber leicht vermeiden, indem
man im Namen der Ressource eine Versionsnummer hochzählt. Dadurch erkennt der
Client, dass er die neue Version (die für ihn eine völlig neue Ressource ist) noch nicht
gespeichert hat, und lädt sie, behält allerdings die alte Version unnötigerweise noch eine
Weile in seinem Cache.
Verfallszeiten eignen sich besonders für eingebettete Grafiken, Style-Sheets und ak-
tive Skript-Dokumente. Sie sind mit gewissen Einschränkungen auch nachträglich bei
vorhandenen Anwendungen einsetzbar, ohne in deren Struktur einzugreifen, da sie zum
Beispiel bei Apache lediglich eine Änderung der Konfigurationsdaten erfordern.
3.2.2 Caching von dynamischem Inhalt
Die beschriebene Technik des Cachings mit Verfallszeit lässt sich auch auf dyna-
misch generierte Seiten anwenden, sofern sie nicht parametrisiert sind. Ein Beispiel sind
Suchmasken (Eingabefelder mit Beschriftungen) für Datenbank-Abfragen, deren Auf-
31
Reinhard Fößmeier
______________________________________________________________________
bau zwar von der Struktur, aber nicht vom Inhalt der Datenbank abhängt und sich daher
nur selten ändert. Gerade hier ist der Benutzer für kurze Reaktionszeiten dankbar, da er
spürt, dass keine echte Rechenarbeit geleistet wird.
Verfallszeiten von etwa einem Tag sind bei solchen Suchmasken fast immer akzep-
tabel und verbessern vor allem die vom Benutzer subjektiv erlebte Reaktionszeit des
Systems.
In Java-basierten Anwendungen lässt sich eine Verfallszeit über die Methode set-
Header der Schnittstelle javax.servlet.http.HttpServletResponse setzen.
3.2.3 Verteilung (Replizierung) von statischem Inhalt
In weltweit verteilten Anwendungen kann es nützlich sein, Kopien des statischen In-
halts auf mehrere Server zu verteilen, die entfernt voneinander stehen. Clients können
sich dann ihre Kopie vom nächst gelegenen Server holen und so von geringeren Latenz-
zeiten profitieren. Sie sind nicht auf einen lokalen Cache angewiesen, der erst gefüllt
werden muss oder auch gar nicht existiert.
Diese Art des Caching wird von dedizierten Geräten, so genannten Branch-Office-
Boxes, besonders unterstützt (s. Skorupa 2005). Entsprechende Dienste werden auch
kommerziell angeboten und englisch als content distribution network oder content deli-
very network (CDN) bezeichnet (Buyya/Pathan/Vakali 2008).
Bild 5 zeigt, wie nach einem Zugriff auf den zentralen Server und dessen Datenbank
weitere Ressourcen (Bilder, Style-Sheets) von einem verteilten Server geholt werden,
der sich relativ nahe beim Client befindet. Dadurch werden die Auswirkungen des Ping-
Pong-Effekts gemildert. Die Abbildung zeigt ebenfalls, dass es ein Irrtum wäre, auch
die Datenbankzugriffe auf den verteilten Server zu verlagern: Da dieser sich weit von
der Datenbank entfernt befindet, treten hohe Latenzzeiten auf; da ein Server-Zugriff vie-
le Datenbankzugriffe auslösen kann(durch drei Punkte in der Abbildung angedeutet),
würden sich diese Latenzzeiten vervielfachen.
Gegenüber dem client-seitigen Caching hat die Replizierung den Vorteil, dass sie be-
reits beim ersten Zugriff auf die Anwendung greift, wenn ein Cache erst befüllt werden
muss.
Bild 5 Zugriff auf verteilte Ressourcen
32
Client vert.
Server
große
Entfernung
zentr.
Server
DB
sehr geringe
Entfernung
geringe
Entfernung
Latenz und Wartezeiten bei WWW-Anwendungen
______________________________________________________________________
Ähnlich wie das Caching ist auch die Replizierung auf bestehende Anwendungen
anwendbar, ohne dass diese geändert zu werden brauchen, da die Zugriffssteuerung über
ein Request-Routing außerhalb der Anwendung erfolgt.
3.2.4 Replizieren von dynamischem Inhalt
Im Prinzip lassen sich unter den oben genannten Voraussetzungen (keine Parameter-
abhängigkeit) auch dynamische Inhalte auf verteilten Servern replizieren. Allerdings ist
es schwierig, diese Inhalte für die Replizierung in statischer Form zusammenzustellen,
da sie ja dynamisch erzeugt werden.
Eine Replizierung dynamischer Inhalte lässt sich dadurch erzielen, dass auf den ver-
teilten Servern eine abgespeckte Variante der Anwendung installiert wird, die nur die
nicht parametrisierten Anfragen beantwortet und alle anderen an den zentralen Server
weiterleitet. Ein entscheidender Nachteil dieses Vorgehens sind die Entwicklungskosten
einer solchen abgespeckten Variante, die einen Einsatz in aller Regel verhindern. Das
Verfahren ließe sich dann rechtfertigen, wenn durch eine geeignete Architektur die volle
und die abgespeckte Server-Variante zusammen entwickelt werden könnten.
3.3 Vorsorgliches Laden von Daten
Zugriffe auf statischen Inhalt oder auch auf Stammdaten lassen sich vermeiden,
wenn diese Daten bei einem früheren Zugriff sozusagen auf Verdacht mitgeschickt wer-
den. Dadurch erhöht sich zwar der Umfang dieses Zugriffs, aber die Übertragungslatenz
fällt nicht separat an.
Häufig angewandt wird diese Technik bei hierarchischen Menüs, von denen zu-
nächst nur die höchste Ebene angezeigt wird und die anderen Ebenen durch Anklicken
aufgeklappt werden. Damit nicht bei jedem Klick der betreffende Menüzweig nachgela-
den werden muss, wird das komplette Menü sofort geladen, wobei jedoch die tieferen
Ebenen zunächst verborgen bleiben. Das Verbergen kann durch geeignete CSS-Styles
geschehen, die beim Anklicken dynamisch umgesetzt werden.
Ein ähnliches Beispiel sind kaskadenartig voneinander abhängige Auswahllisten, bei
denen die Auswahlmöglichkeiten von der bereits getätigten Auswahl in anderen Listen
abhängen (Beispiel: Auswahl eines Landes, dann Auswahl einer Provinz im gewählten
Land usw.). Hier kann dieselbe Technik zum Einsatz kommen, wobei entweder die ab-
hängigen Listen dynamisch über JavaScript befüllt werden oder von mehreren Listen
immer nur eine dargestellt und die anderen durch CSS verborgen werden.
Die Nutzung solcher vorsorglich geladener Daten erfordert immer ein aktives Ele-
ment in den HTML-Seiten, also eine Veränderung nach Abschluss des ersten Seitenauf-
baus. Dieses aktive Element kann in JavaScript/Ajax oder einer proprietären Technik
wie Flex, Flash oder ShockWave von der Firma Adobe bestehen. Alle diese Techniken
ermöglichen es auch, bei hierarchischen Daten zunächst nur die erste nicht sichtbare
Ebene vorauszuladen und weitere Ebenen nachzuladen, während der Benutzer hof-
fentlich – noch mit der soeben geöffneten Ebene beschäftigt ist.
33
Reinhard Fößmeier
______________________________________________________________________
3.4 Beschleunigung des Seitenaufbaus
Die beschriebenen Techniken helfen zwar, die Ansammlung von Latenzzeiten in
Grenzen zu halten, können sie aber nicht unter bestimmte Grenzen drücken, die von der
Physik und von der Leistungsfähigkeit der Geräte gesetzt werden. Umso wichtiger ist
es, dass nicht noch weitere Wartezeiten hinzukommen. Solche Zeiten können beim Auf-
bau großer HTML-Seiten im Browser entstehen, zum Beispiel von langen Tabellen mit
Abfrageergebnissen.
Wenn der Browser den Aufbau einer Tabelle, vor allem die Breiten der Spalten, am
Inhalt ausrichten muss, kann er die gesamte Tabelle erst nach Erhalt und Verarbeitung
des gesamten Inhalts anzeigen. Mit etwas Unterstützung kann er die Tabellenzeilen nach
und nach anzeigen, während er sie vom Server erhält. Dazu braucht er Zusatzinforma-
tionen über die Spaltenbreiten, die mithilfe der HTML-Marken colgroup und col ange-
geben werden. Wenn der Browser diese Informationen richtig auswertet, kann sich die
subjektiv erlebte Reaktion des Systems deutlich verbessern. Allerdings ist die Auswer-
tung bei verschiedenen Browser-Typen unterschiedlich.
Das Phänomen, dass große Teile einer HTML-Seite erst nach vollständiger Daten-
übertragung erscheinen, tritt auch auf, wenn größere Seitenelemente wie Textabsätze
und Bilder durch Einbetten in Tabellen angeordnet werden. Diese Technik sollte vermie-
den werden. Die gewünschte Wirkung lässt sich fast immer auch durch CSS-Style-
Sheets erzielen.
Allgemein sollte der Benutzer möglichst sofort nach dem Eintreffen der Server-Ant-
wort eine sichtbare Reaktion des Systems erhalten, damit die Wartezeit nicht noch auf
Client-Seite erhöht wird. Noch besser ist es, wenn bereits in der Wartezeit eine Reaktion
erscheint, die bestätigt, dass die Anfrage an den Server abgeschickt wurde und bearbei-
tet wird. Das ist möglich durch den Einsatz von JavaScript, mit dem sich zum Beispiel
ein Warte-Mauszeiger oder auch ein Bestätigungstext anzeigen lässt. Besonders nützlich
ist diese Technik, wenn der verwendete Browser das Warten auf eine Server-Antwort
nicht oder nicht zuverlässig anzeigt. Nielsen (Nielsen 1994) empfiehlt eine solche
graphische Rückmeldung bereits bei Wartezeiten ab 0,1 Sekunden, also einer Zeit, die
bei großem Client-Server-Abstand zwangsläufig überschritten wird.
Bild 6 zeigt mehrere Möglichkeiten, über JavaScript dem Benutzer sofort optisch zu
melden, dass seine Anfrage angenommen wurde: a) wird der Mauszeiger auf der Sende-
schaltfläche zu einem Wartesymbol (Uhr, Sanduhr usw.) gemacht, b) wird die Schaltflä-
che deaktiviert, sodass ihr Aussehen sich ändert und außerdem ein versehentliches dop-
peltes Senden gar nicht möglich ist, und c) wird die Farbe des Dialogs geändert. Eine
solche Häufung von Hinweisen würde in der Praxis natürlich übertrieben wirken.
34
Latenz und Wartezeiten bei WWW-Anwendungen
______________________________________________________________________
3.5 Lokale Interaktion
Während die bisher beschriebenen Techniken darauf abzielen, die Häufung von La-
tenzzeiten in einer Transaktion zu verhindern, lässt sich die Verbindungslatenz komplett
einsparen, wenn die Aktion auf den Client verlegt werden kann. Das ist möglich durch
den Einsatz von JavaScript, wenn kein Zugriff auf die zentralen persistenten Daten er-
forderlich ist. Ein klassisches Beispiel ist die formale Überprüfung (Validierung) von
Eingabedaten; sie ermöglicht es, Fehler bei der Eingabe (z. B. Buchstaben in einer Zahl)
ohne Server-Zugriff zu erkennen und zurückzuweisen.
Das Validierungsmodul des Oberflächen-Frameworks Struts (siehe Husted/Du-
moulin/Franciscus/Winterfeldt 2002) erzeugt in HTML-Dialogen automatisch geeignete
JavaScript-Methoden, um die enthaltenen Eingabefelder zu validieren. Da diese Metho-
den den Umfang der Dialoge aufblähen, ist es auch möglich, sie in statische JavaScript-
Dateien auszulagern. Diese sollten mit den Techniken aus Abschnitt 3.1.2 und Bild 4 be-
handelt werden, um eine Rückkehr der Latenz durch die Hintertür zu vermeiden.
Außer über JavaScript ist lokale Interaktion mithilfe von Browser-Plug-Ins möglich,
die proprietäre Sprachen interpretieren, etwa die erwähnten der Firma Adobe.
3.6 Asynchrone Kommunikation
Die Latenzzeit der Netzverbindung wird vom Benutzer nur bei synchroner Kommu-
nikation als Wartezeit wahrgenommen, also dann, wenn der Benutzer nach dem Absen-
den einer Anfrage tatsächlich auf das Ergebnis „wartet“. Während der Benutzer einen
Dialog ausfüllt, besteht jedoch die Möglichkeit, die getätigten Teileingaben bereits für
Anfragen beim Server zu nutzen. So weit diese Zeit zur „Denkzeit“ des Benutzers ge-
hört, wird sie nicht als Wartezeit wahrgenommen, wenn die Kommunikation asynchron
erfolgt, also weitere Aktionen des Benutzers nicht blockiert werden.
Auf diese Weise können während des Ausfüllens eines größeren Formulars im Hin-
tergrund die bereits ausgefüllten Felder validiert und aufgrund der gemachten Eingaben
Vorschlagstexte für noch unausgefüllte Felder angeboten werden. Bei der Eingabe einer
Adresse könnte etwa nach Eingabe der Postleitzahl der Ort automatisch bestimmt und
angezeigt werden, während der Anwender noch Straße und Hausnummer erfasst. Er hät-
35
Schaltfläche zum Ab-
senden
<input type="button"
onclick="javascript:senden(this);"
value="los"/>
JavaScript-Funktion
zum Absenden:
a) Wartesymbol
b) Deaktivieren
c) andere Farbe
function senden(ausloeser) {
ausloeser.style.cursor="wait"; // a)
ausloeser.disabled = true; // b)
document.bgColor = "lightBlue"; // c)
document.forms[0].submit();
}
Bild 6 Optische Bestätigung des Absendens
Reinhard Fößmeier
______________________________________________________________________
te dann nur die Aufgabe, die angezeigte Ortsangabe zu prüfen und ggf. die Postleitzahl
zu korrigieren.
Diese Technik wird im Rahmen von Ajax (Asynchronous JavaScript And XML) ein-
gesetzt, um dem Benutzer im Idealfall ein nahezu latenzfreies System vorzuspiegeln.
Siehe zum Beispiel Bergmann/Bormann 2005.
4 Praktische Auswertung
Mehrere der beschriebenen Techniken wurden vor einiger Zeit in einem vertriebli-
chen Informationssystem eines Automobilherstellers eingeführt, vor allem der Wegfall
von Rahmen, die Einsparung von Grafiken und die verbesserte Unterstützung des Ca-
ching. Nicht eingesetzt wurde die Replizierung des statischen Inhalts, da sich infolge
des hohen Anteils an Daueranwendern das client-seitige Caching als ausreichend er-
wies. Der Einsatz von JavaScript für lokale Interaktion wurde auf ein geringes Maß be-
grenzt, um die Browser-Abhängigkeit und den Testaufwand in Grenzen zu halten.
Es zeigte sich, dass das durch den Wegfall der Rahmen-Technik teilweise erhöhte
Datenvolumen kaum ins Gewicht fiel, da nahezu alle Teilnehmer über ausreichende
Verbindungskapazität verfügten. Dagegen macht sich die Reduzierung der Zahl der Zu-
griffe sehr positiv bemerkbar. Anwender aus anderen Kontinenten, die zuvor über lange
Reaktionszeiten geklagt hatten, waren mit dem geänderten System sehr zufrieden.
Als wichtig stellte es sich heraus, die Caching-Einstellung der verwendeten Browser
zu prüfen, da durch zu strenge Einstellungen ein Caching verhindert werden kann. So
befindet sich unter den Einstellungen des Microsoft Internet Explorer der Punkt „ver-
schlüsselte Seiten nicht auf Festplatte speichern“; er ist standardmäßig aktiviert, da man
bei gesicherten Verbindungen von einem erhöhten Schutzbedürfnis auch auf dem loka-
len PC ausgeht, und führt dazu, dass bei Einsatz des gesicherten Protokolls HTTPS kein
lokales Caching erfolgt. Daher wurden den Anwendern genaue Vorgehensweisen zur
Einstellung des Cachings zur Verfügung gestellt. Auf das Risiko, dass im Cache ungesi-
cherte Kopien vertraulicher Dokumente verbleiben können, wurde hingewiesen.
5 Zusammenfassende Schlussfolgerungen
Bei HTTP-Zugriffen auf dialog-orientierte Anwendungen über große Entfernungen
machen sich die hohen Latenzzeiten störend bemerkbar. Der Einsatz breitbandiger Lei-
tungen verbessert die Leitungslatenz in der Regel nicht. Es gibt aber Techniken, um die
Anzahl der Server-Zugriffe zu verringern und dadurch häufig deutlich schnelleren Re-
aktionszeiten zu erzielen. Diese Techniken unterscheiden sich von den Techniken zur
Reduzierung des Datenumfangs, die häufig bei der Optimierung von Netzauftritten ein-
gesetzt werden.
Für mehrere dieser Techniken sind aktive Elemente auf Client-Seite, etwa in Form
von JavaScript, Voraussetzung.
Schrifttum
Bergmann, O., Bormann, C: AJAX - Frische Ansätze für das Web-Design. 1SPC TEIA Lehrbuch
Verlag, Berlin 2005.
Buyya, R., Pathan, M., Vakali, A: Content Delivery Networks. Springer-Verlag, August 2008.
36
Latenz und Wartezeiten bei WWW-Anwendungen
______________________________________________________________________
Fabbi, M: Latency: The silent killer of application performance. Gartner Research Note. 14. Septem-
ber 2004.
Gousios, G., Karakoidas, V., Spinellis, D: Tuning Java's memory manager for high performance
server applications, Alexios Zavras (Hrsg.), Proceedings of the 5th International System Admin-
istration and Network Engineering Conference SANE 06, 69–83. NLUUG, Stichting SANE,
Mai 2006.
Husted, T., Dumoulin, C., Franciscus, G., Winterfeldt, D: Struts in Action. Manning, Greenwich,
2002.
Henderson, C: Serving Javascript Fast. Thinkvitamin.com, 2006.
http://ap-project.org/Russian/Article/View/55/English_translation/
King, A. B: Speed Up Your Site: Web Site Optimization, New Riders Publishing, Indianapolis, 2003.
Meyer, E. A: Cascading Style Sheets – Das umfassende Handbuch, deutsch von J. W. Lang, O’Reilly
Verlag, Köln, 2005.
Nielsen, J: Usability Engineering, Morgan Kaufmann, San Francisco, 1994.
Nielsen, J: Designing Web Usability: The Practice of Simplicity. New Riders Publishing, Indianapolis,
2000.
The „data“ URL scheme. RFC 2397. Siehe: http://tools.ietf.org/html/rfc2397
Hypertext Transfer Protocol – HTTP/1.1. RFC 2616.
Siehe: http://www.w3.org/Protocols/rfc2616/rfc2616.html
Rollman, R: Data Binding in Dynamic HTML, Microsoft Internet Developer, Juli 1997.
Skorupa, J: BOBs help you make the most of branch office WANs. Gartner Research, ID G00131307.
14. Dezember 2005.
Symantec survey reveals that application performance slowdowns result in lost business.
http://www.symantec.com/about/news/release/article.jsp?prid=20060829_01
Westermann, E: Learn XML in a weekend, Muska & Lipman, Cincinnati, 2002.
Alle angegebenen URLs wurden im Januar 2011 kontrolliert.
Eingegangen 2011-01-08
Anschrift des Autors: OProf. Dr. rer. nat. Reinhard Fößmeier, Rahel-Straus-Weg 19,
DE - 81673 München. Netzpost: reinhard @.foessmeier.name
Respondo- kaj atendotempoj en retaj aplikaĵoj (Resumo)
Ŝlosilaj vortoj: Distribuitaj aplikaĵoj, atendotempo, TTT, optimumigo.
Resumo: Estas prezentata repertuaro da metodoj por optimumigi retajn aplikaĵojn koncerne
atendotempojn. Precipe ĉe grandaj distancoj inter la koncernataj komputiloj eblas signifa plibonigo de
la respondemo. Parto de la metodoj estas aplikebla al jam ekzistantaj aplikaĵoj.
Latency and waiting times in web applications (Summary).
Keywords: Distributed applications, latency, web, optimization.
Abstract: Designers of web applications are given a catalogue of techniques to optimize their applica-
tions for latency. Significant improvement of responsiveness, especially over large distances between
the computers involved, is possible. Part of these techniques is applicable to existing applications.
37
ResearchGate has not been able to resolve any citations for this publication.
Article
Full-text available
Java is a strong player in the application server market and thus the performance of its virtual machine is an important aspect of a server's performance. One of the components that affect the performance of a JVM is the memory manager, which also includes the garbage col- lector. Modern virtual machines offer a multitude of options for tuning the memory manager, which can have a significant impact on server application performance. In this paper, we examine the effect of tuning the garbage collection in an application server environment. By employing both synthetic and real world application benchmarks, we assess the various garbage collection strategies offered by two popular virtual machines. Finally, we present a comprehensive list of generally applicable garbage collection guidelines.
M: Latency: The silent killer of application performance
  • Fabbi
Fabbi, M: Latency: The silent killer of application performance. Gartner Research Note. 14. September 2004.
A: Cascading Style Sheets – Das umfassende Handbuch
  • E Meyer
Meyer, E. A: Cascading Style Sheets – Das umfassende Handbuch, deutsch von J. W. Lang, O'Reilly Verlag, Köln, 2005.
BOBs help you make the most of branch office WANs
  • J Skorupa
Skorupa, J: BOBs help you make the most of branch office WANs. Gartner Research, ID G00131307. 14. Dezember 2005.
Estas prezentata repertuaro da metodoj por optimumigi retajn aplikaĵojn koncerne atendotempojn Precipe ĉe grandaj distancoj inter la koncernataj komputiloj eblas signifa plibonigo de la respondemo
  • Resumo
Resumo: Estas prezentata repertuaro da metodoj por optimumigi retajn aplikaĵojn koncerne atendotempojn. Precipe ĉe grandaj distancoj inter la koncernataj komputiloj eblas signifa plibonigo de la respondemo. Parto de la metodoj estas aplikebla al jam ekzistantaj aplikaĵoj.
The silent killer of application performance. Gartner Research Note
  • M Fabbi
  • Latency
Fabbi, M: Latency: The silent killer of application performance. Gartner Research Note. 14. September 2004.
  • Henderson
Henderson, C: Serving Javascript Fast. Thinkvitamin.com, 2006. http://ap-project.org/Russian/Article/View/55/English_translation/
Spinellis, D: Tuning Java's memory manager for high performance server applications
  • G Gousios
  • V Karakoidas
Gousios, G., Karakoidas, V., Spinellis, D: Tuning Java's memory manager for high performance server applications, Alexios Zavras (Hrsg.), Proceedings of the 5th International System Administration and Network Engineering Conference SANE 06, 69-83. NLUUG, Stichting SANE, Mai 2006.