- Blogübersetzung -
Seit Ende 2012 gibt es ein Projekt zur Verbesserung der HTTP-Verbindungen zwischen dem Viewer und den Grid-Diensten. Eine der Metriken, die wir versucht haben zu verbessern, ist die maximale Abfragerate: die Anzahl von HTTP-Anfragen, die in einer Zeitspanne ausgegeben und beantwortet werden können. Die Verbesserung dieser Kennzahl ist eine Herausforderung gewesen. Es gibt immer Faktoren außerhalb unserer Kontrolle, wie etwa die Eigenschaften des heimischen Netzwerks, die Methoden und Leistungen der Internetanbieter, die physikalische Entfernung zu den Diensten und vorübergehende Netzwerkprobleme, um nur ein paar zu nennen. Wir können allerdings etwas bei anderen Faktoren unternehmen, die unter unserer Kontrolle stehen.
Diese Faktoren können feste Grenzwerte sein, die dazu bestimmt sind, eine Drosselung der Abfragerate durchzuführen. Oder sie können auch Nebeneffekte von anderen Entscheidungen sein, wie etwa die Bearbeitung von Verbindungen. Die Auswirkungen von festen Grenzwerten und der Handhabung von Verbindungen werden in der folgenden Abbildung gezeigt, die beim Abrufen von Texturen und Mesh erstellt wurde. Die unterste Kurve (rot) stellt die höchste Abfragerate dar, bei Verwendung einer einzelnen Verbindung für jede HTTP-Anforderung und einem Maximum von fünf (5) gleichzeitigen Verbindungen. Die Kurve darüber (blau) zeigt eine Verdoppelung der Grenzwerte für die Abfragerate, wenn HTTP-Keepalives verwendet werden. Und diese beiden Grenzwerte werden stark von den Paketdurchlaufzeiten (Ping) beeinflusst. Und schließlich stellt die horizontale Linie (orange) bei 100 RPS eine ungefähre Grenze der Abfragerate dar, die unabhängig von den Pingzeiten sind.
Zu Beginn dieses Projektes war der größte Teil des HTTP-Datenverkehrs, insbesondere der Download von Texturen, auf die Region "A" eingeschränkt. Dies war das Ergebnis einer Kombination von Faktoren. Einer war das Fehlen von Keepalive für Verbindungen. Dies erzwang ein Handshake der TCP-Verbindung vor jeder HTTP-Anfrage. Ein anderer Faktor war die Verzögerung beim Abschicken neuer Anfragen erst nach dem Abschluss der vorherigen Anfragen.
Viewer 3.4.3
Im Frühjahr 2013 erschienen, hatte der Viewer 3.4.3 eine neue Bibliothek eingebaut, die llcorehttp, die damit begann, die oben genannten Probleme anzugehen. Es war grundlegend, dass die Bibliothek keines der obigen Probleme direkt bekämpfte (sowie weitere Probleme, die hier nicht erörtert werden), sondern dass sie eine Struktur einführte, die es ermöglichte, die Probleme über einer Reihe von weiteren Veröffentlichungen zu beheben.
Obwohl die Ziele bescheiden waren, wurden bei der Verbesserung der Effizienz und Latenz einige gute Fortschritte erzielt. Das Holen der Texturen war die erste Komponente, die die neue Bibliothek nutzte und bei der sowohl Durchsatz als auch Zuverlässigkeit erhöht wurden, während die Tendenzen zum Stillstand verschwanden. Mit diesen Änderungen gelangte der Textur-Download fest in den "B"-Bereich des Diagramms.
DRTSIM-203
Aufgespielt im April 2013, enthielt der DRTSIM-203 Server-Release die erste Unterstützung für HTTP Keepalive-Verbindungen zwischen Viewer und Simulator-Host. Für kleinere Übertragungen halbierte sich die Anzahl der erforderlichen Durchläufe, um ein Objekt zu holen. Für größere Übertragungen wurden die Auswirkungen eines TCP Slow-Start ebenfalls reduziert. Es gab mehrere andere positive Nebeneffekte und der größte von ihnen war das Erzeugen von weniger TCP-Verbindungen für eine bestimmte Arbeitslast. Eine hohe Rate von erzeugten Verbindungen, genannt Connection Churn, ist einer der Faktoren bei der Destabilisierung vieler Heim-Router. Symptome dafür sind: Der Router wird neu gestartet, Verlust der Konnektivität, Zeitüberschreitungen und DNS-Fehler.
Keepalive-Verbindungen wurden für das Holen von Texturen und SSL-verschlüsseltem HTTP zwischen Viewer und Simulator-Hosts aktiviert. Dies verschob die Grenze in den Bereich "C" und erhöhte den Durchsatz beim Textur-Download. Mesh-Downloads benutzten weiterhin das ursprüngliche Verbindungsschema und es wurden Überwachungs- und Kontrollwerkzeuge hinzugefügt, um gemeinsame Dienste vor Monopolisierung zu schützen.
Was kommt als nächstes?
Wir werden weiterhin unsere HTTP-Protokolle auswerten mit dem Ziel, unser Benutzererlebnis zu verbessern. Hier sind einige unserer neuesten, interessanten Bereiche.
DRTSIM-216/229 + Viewer DRTVWR-329
Das Herunterladen von Mesh, genauso wie von Texturen, ist eine relativ schwere Arbeit im Viewer. Es braucht Zeit, diese Assets zu erwerben und in einer Szenerie anzuzeigen. Also wird das Holen von Mesh der nächste Bereich sein, der die oben genannten Verfahren erhält, was diese Funktion ebenso in die Region "C" bringen wird.
Die Herausforderung dabei ist, dass der Abruf von Mesh auf extrem viele gleichzeitige Verbindungen setzt. Ein neuer Leistungsdienst, genannt "GetMesh2", wird den bestehenden "GetMesh"-Dienst ersetzen. Dieser ist auf den Einsatz von wenigen gleichzeitigen Verbindungen ausgelegt. Das wiederum wird Keepalive-Verbindung erlauben und sogar HTTP-Pipelining ermöglichen und gleichzeitig einen höheren Durchsatz, weniger Aufwand und verbesserte Router-Stabilität in Aussicht stellen.
Pipelining
So bedeutend die oben genannten Änderungen sind, befinden sich dennoch die meisten Benutzer unterhalb einer Grenze, die stark von der Ping-Zeit beeinflusst wird. Europa und Asien haben in der Regel mehr als 100ms und Südafrika berichtet häufig von 250ms. Es wird immer eine "Ping-Steuer" für diejenigen geben, die sich weit entfernt von den Grid-Diensten befinden. Aber es gibt etwas, was wir tun können: HTTP Pipelining.
Pipelining reduziert die Auswirkungen der Ping-Zeit durch das Versenden mehrerer HTTP-Anfragen auf einmal, ohne auf die Antworten zu warten. Dies ermöglicht es unseren Servern den Download-Datenstrom laufend zu füllen, anstatt zwischen den Anfragen zu stoppen. Der Mesh- und Textur-Abruf wird erst einmal beim Pipelining zu Bruch gehen. Es werden neue Probleme auftauchen. Eine äußerst wichtige Bibliothek, die libcurl, hat gerade erst damit begonnen, Pipelining zu unterstützen. Wir müssen ebenso einige unserer Dienste aktualisieren. Aber das werden wir in den Griff bekommen und das Holen von Asset-Daten wird beginnen, in Region "D" zu arbeiten.
Nur der Himmel ist die Grenze
Die Fortschritte werden mit Pipelining nicht aufhören. Es gibt weitere Möglichkeiten, um nach oben in "E" und "F"- Regionen vorzustoßen. Ein paar der Möglichkeiten:
- Wenn ihr am DRTSIM-203 Beta-Test teilgenommen habt, hattet ihr die Möglichkeit, unsere "Happy"-Regionen (TextureTest2H, MeshTest2H, usw.) auszuprobieren. Diese Regionen liefen auf Hosts mit erhöhten Grenzwerten, um zu sehen, was passieren würde. Die Ergebnisse waren positiv und fordern zu einer dauerhafte Erhöhung zur Verbesserung des HTTP-Verhaltens auf.
- Aktualisieren von anderen HTTP-basierten Diensten, um sie auf der Durchsatzkurve nach oben zu bewegen. Dies würde Dienste betreffen wie Inventar-Operationen und Auffinden von Displaynamen, was schwere und gebündelte Abfragen verursacht.
- Anschauen von weiteren Transportprotokollen. SPDY ist interessant und versucht, einige der Schwierigkeiten zu lösen, die in Second Life auftreten. Wie gut sie gelöst werden, muss man noch prüfen.
Dies sollte man nicht als Verbindlichkeiten oder als "in Stein gemeißelte" Pläne betrachten, denn Prioritäten und Ziele können sich verschieben, aber wir haben gute Ergebnisse aus unserer Arbeit mit dem HTTP-Projekt gesehen und freuen uns darauf, weiterhin die Infrastruktur von Second Life zu verbessern.
Quelle: Raising the Roof: The HTTP Project
........................................................................................................................................................
Anm.:
Dieser Blogpost von Linden Lab wurde gestern Abend erst nach meinen beiden Postings zu den LL-Viewern veröffentlicht. Sonst hätte ich wahrscheinlich noch darauf Bezug genommen. Für mich klingen die Verbesserungen, die mit HTTP möglich sind, jedenfalls recht gut. Interessant wäre einmal eine Betrachtung, ob die Verbesserungen vom Projekt Interesting Viewer und der schnellere Download vom HTTP-Projekt Viewer sich beide addieren, wenn diese Methoden in einem Viewer vereint werden. In zwei bis drei Wochen werden wir es ja dann erleben, denn beide Viewer befinden sich seit gestern im RC-Kanal.
Insgesamt ist das hier auch viel Technobabble, der nicht einfach zu übersetzen war. Aber wenn ich gerade den zweiten Abschnitt betrachte, hat Linden Lab durchaus vor, auch in diesem Jahr durchgehend an Verbesserungen für Server und Viewer zu arbeiten. Die Vermutung einiger Leute, sie würden es langsam auslaufen lassen, weil ja High Fidelity in den Startlöchen steht, trifft also eher nicht zu.
Keine Kommentare:
Kommentar veröffentlichen