Das war unter anderem das Thema der Bürostunde von Zero Linden am Dienstag, die allerdings diesmal von Ian Linden durchgeführt wurde (da Zero wohl gerade Papa wird – herzlichen Glückwunsch! :-) ). Es wurde im speziellen diskutiert, woran z.B. die Engpässe liegen, die von vielen Bewohnern in Second Life wahrgenommen werden.
Nun ist es ja so, dass nicht jede Sim ihren eigenen Server hat, sondern diese per CPU aufgeteilt werden, d.h. es ist garantiert, dass jede Sim ihre eigene CPU hat, Speicher und Netzwerkkarte usw. werden aber von allen Sims auf einem Rechner geteilt, und das sind heutzutage normalerweise 4 Stück.
Wenn nun jemand Probleme in Second Life hat, so muss das daher nicht unbedingt an der eigenen Sim liegen, sondern kann auch an einer Sim liegen, die mit seiner auf dem gleichen Rechner liegt (z.B. weil diese 100 Avatare bedienen muss). Es wurde dann weiter diskutiert, wie man denn herausfinden kann, wer mit wem auf einem Rechner liegt bzw. ob man das irgendwie beeinflussen kann (so wäre es ja hilfreich, wenn man die eigenen 4 Sims auf einem Rechner hat, denn dann kann man selbst eher kontrollieren, wie die Gesamtperformance ist). Leider aber geht weder das eine, noch das andere. Man kann höchstens rausfinden, wie die IP-Adresse der Sim ist, auf der man sich befindet, aber nicht, welche ausserdem noch darauf liegen (es sei denn man testet alle Sims durch).
Wo liegen die Engpässe?
Die Diskussion ging dann weiter zu der Frage, was denn die Engpässe an sich sind. Und während ich naiverweise immer annahm, dass es die Netzwerkaktivität einer Sim sei (und bei 4 Sims auf einem Rechner dann eben die 4-fache Aktivität), so wurde dies von Ian wiederlegt, denn er meinte, dass das Netzwerk bis zu 60.000 Pakete pro Sekunde verträgt, ein Avatar aber nur 10-50 braucht.
Das eigentliche Problem aber sei der Dataserver. Leider kenne ich die Architektur einer Sim und deren Backend-Datenbanken nicht wirklich, aber bei jeder Aktion muss wohl der Dataserver kontaktiert werden und das Problem hier ist, dass dieser die Anfragen nur sequentiell abarbeiten kann. Daher also der Engpass.
Was wird getan?
Es gibt Projekte bei Linden Lab, die diesen Engpass abstellen wollen. Und das grösste davon ist, das gesamte Second Life-Protokoll umzustellen (unter „Protokoll“ versteht man sozusagen die Sprache in der sich Client und Server also Sim unterhalten). Im Moment ist das recht kryptisch und bei jeder Änderung an diesem Protokoll muss leider auch der Client geändert werden, was der Grund für die vielen Client-Updates ist.
Beim Studio Icehouse unter Zero Linden’s Leitung wird aber seit einiger Zeit an einem neuen Protokoll gebastelt, welches flexibler ist und unter dem Namen LLSD firmiert (leider habe ich nicht herausfinden können, wofür das genau steht). Weiterhin werden z.B. Texturen dann nicht mehr über ein eigenes Protokoll geschickt, sondern wie bei Web-Browsern per HTTP (welches ein gut verstandenes, da viel benutztes Protokoll ist, mit dem sich seit jeher Web-Client und -Server unterhalten). Diese Änderung ist sogar heutzutage schon online.
Im Zuge dieser Umstellung auf LLSD wird dann auch der Dataserver entfallen (Ian nannte es das „Kill Dataserver“-Projekt) und damit auch der Engpass.
LLSD wird nun nach und nach auf dem Maingrid eingeführt, wobei aber sichergestellt wird, dass das alte Protokoll noch funktioniert, d.h. sollten Probleme mit dem neuen Protokoll auftreten, so kann (ohne Neustart) auf das alte zurückgeschaltet werden.
In irgendeiner Zukunft (wer aber weiss schon wann?) wird dann das gesamte Grid auf LLSD umgestellt worden sein. Dies nennt Zero Linden „The Day of Liberation“ (Feierlichkeiten sind geplant ;-) ).
Was sind die Vorteile von LLSD?
Mit dem Entfall des Engpasses könnten dann also auch mehr als 100 Avatare auf einer Sim sein ohne dass es zu den bekannten Engpässen auf der Server-Seite kommt (das alles übrigens ohne Gewähr, das ist die Hoffnung, ob es so kommt, wird man sehen). Abgesehen davon bleibt natürlich die Frage, ob alle Clients das mitmachen.
Ein anderer Vorteil ist, dass nicht mehr alle Leute den gleichen Client auf dem Maingrid benutzen müssen, es kann einen Mix von Client-Versionen geben, denn jeder Client kann per LLSD dem Server mitteilen, welche Features er unterstützt und welche nicht. Dadurch muss man also nicht andauernd neue Clients runterladen, wenn man dies nicht möchte (es sei denn man will auch die Features haben). Andersherum kann auch eine Beta-Version schon auf Teilen des Grids veröffentlicht werden, die man dann mit einem speziellen Client benutzen kann (d.h. es entfällt die Benutzung des Beta-Grids zumindest für nicht ganz so drastische Änderungen).
Also 1000 Avatare pro Sim?
Einerseits ist die Frage, ob das wirklich so kommen wird, denn evtl. kommen nach dem Dataserver doch noch andere Engpässe zum Tragen (wie z.B. die Physics-Engine) und zum anderen ist doch sicherlich die Frage relevant, ob das überhaupt Sinn macht. In Second Life geht es ja sehr stark um Community Building und da sind größere Events sicherlich hilfreich, aber sooo große vielleicht dann eher wieder nicht. Wer schonmal ein Townhall-Meeting erlebt hat, der weiss, dass auch 200 Avatare schon ein Kommunkationschaos ohne Gleichen erzeugen können, bei 1000 (oder 4000 bei einer 4-Sim-Ecke) wird es wohl kaum anders aussehen.
Für Second Life macht eher eine kontinuierliche Präsenz Sinn, die eben die Leute nicht alle zu einem Zeitpunkt auf genau einen Platz bindet, sondern eben ein andauernder Anlaufpunkt ist.
Trotz allem wäre es natürlich schön, wenn schon die 100 Avatare auf einer Sim nicht eine solche Last erzeugen würden, so dass man ein Problem weniger hätte (und damit dann auch die anderen Sims auf dem gleichen Rechner). Wünschen wir Studio Icehouse also viel Glück! :-)
Literatur
Chat von Zero Linden über das neue Message-System
LLSD beim Second Life Wiki
Die Linden Lab Bürostunden
Technorati Tags: secondlife, virtuele welten, llsd, lindenlab, zero linden, avatare, sim, performance, protokoll, protocol, mrtopf