LSL versus Mono Performancevergleich

Michael Wald — Wed, 16 Apr 2008 08:40:13 +0000

Die in Second Life® verwendete Programmierspache LSL wurde ja bekannter weise um eine weitere Sprache namens Mono ergänzt. Hier sieht man im Video einen Vergleich bezüglich der unterschiedlichen Leistungspotenziale. Links im Bild Code mit LSL, rechts mit Mono ausgeführt. Beide Scripte wurden Zeitgleich gestartet.

Secondlife != Secondlife: Performancetuning

Patrick — Sat, 07 Apr 2007 10:01:45 +0000

Second Life® ist nicht gleich Second Life®. Das merkt man an den unterschiedlichen Regionen, insbesondere an deren Gestaltung und natürlich deren Performance. Genau darum soll es in diesem Artikel gehen. Im Zeichen der Breakpoint, einer Veranstaltung auf der die 20 Jahre alte Multi-Media-Avant Garde zeigt, was vielleicht in 6 Jahren in Second Life® möglich ist, ging es urspünglich wie auch heute um Performance, um das Maximale aus einer Maschine herauszuholen. Nun haben wir das Problem, mit Second Life® qualitativ mit einem Abstand von etwa 6 Jahren dem hinterherzulaufen was möglich ist. Dafür haben wir aber mit Second Life® die 3D-Vernetzung , ähnlich der Vernetzung, wie wir sie vom 2D-Internet her kennen. Und damit das Ganze Spaß macht und nicht in eine ruckelige Arie und heilloses Chaos abgleitet, möchte ich in diesem Artikel etwas zum Thema Second Life® und Performance schreiben.

Randbedingungen

Aufgrund der Natur von Second Life®, hinkt Second Life® in der 3D-Qualität ca. 6 Jahre dem hinterher, was heute möglich ist. Dafür bietet Second Life® andere Features wie einfache Vernetzung in einem dreidimensionalem virtuellen Raum für Jedermann, mit einem durchschnittlichen Rechner und einem durchschnittlichen Internet-Zugang. Darüber hinaus bietet Second Life® jedem Resident die Möglichkeit, dem GRID Content im Sinne von Web 2.0 hinzuzufügen. Das heißt, der einzelne Resident ist TEIL DER WELT (der Second Life® Welt, er gestaltet sie mit). Diese Features definieren auch die Randbedingungen, d.h. mit durchschnittlicher Benutzer-Bandbreite, durchschnittlichem Rechner usw. usf. nimmt man eine qualitativ schlechtere Grafik in Kauf. Möchte man eine Region schaffen, die weitestgehend ruckelfrei und mit Spaß explorierbar ist, enstehen hierbei besondere Herausforderungen für den Modellierer, den Programmierer und den Konzepter (!) Diese Herausforderungen möchte ich hier skizzieren und ein paar Tips geben, wie man an diese Herausforderungen herangehen kann.

Voraussetzungen

Ich setze voraus, das der Leser Region Estate Manager ist. Dies bedeutet i.d.R. das man das Land bei Linden Lab® gekauft hat oder von dem Zwischenhändler den Status eines Real Estate Managers zugewiesen bekommt. Ein Region Estate Manager hat u.a. das Recht einen Rollback für eine komplette Region anzustoßen und hat Zugriff über die Region Estate-Tools, welche ihr im Menupunkt World->Region/Estate im Second Life® Client findet. Ein Region-Estate-Manager sollte sehr vorsichtig und sorgsam mit den Funktionen umgehen, die er über dieses Menu erreicht. Ebenso sollte sich der Owner einer Region genau überlegen, wem er die Rechte eines Region-Estate-Managers zuweist. Wenn ihr euch im Dialog des Region Estate Tools befindet, habt ihr folgende Tabs zur Verfügung: Region, Debug, Ground Textures, Terrain, Estate, Covenant. Ich möchte im Zusammenhang mit einem LSL-Performance-Tuning auf den Tab "Debug" eingehen. Hier gelangt ihr über den Button "Get Top Scripts" an eine Übersicht aller auf der Region aktiven Scripte.

Performance Analyse

Nun erscheinen alle Scripte. Hier seht ihr in der ersten Spalte die anteilig verbrauchte Zeit pro Frame. Diese Zeit sollte in der Summe auf keinen Fall 25 ms überschreiten (!). In unserem Fall, verbrauchen 184 Scripte insgesammt 2.7 ms. Später werde ich noch auf das Statistik-Tool eingehen, aus dem die Summe der verbrauchten Zeit für die Scripte hervorgeht. In der zweiten Spalte geht der Name des Prims hervor, indem das einzelne Script eingebettet wurde. Merke: Die ist nicht der Name des Scriptes, sondern der Name des Prims.

Ich habe euch hier einmal ein schlechtes Beispiel konstruiert, um zu zeigen, wie es NICHT sein sollte. Benennt eure Prims immer ordentlich, der Name für den fokusierten Prim im obigen Screenshot ist nichtssagend und erschwert die Analyse. In der dritten Spalte seht ihr aber den Namen des Verantwortlichen, ups, ..., das bin ja ich Und in der letzten Spalte sehr ihr die Koordinaten des Objektes. Wenn ihr auf "Show Beacon" klickt wird euch das Objekt InWorld durch den roten Leuchtstreifen und einen roten Pfeil markiert, sodaß ihr das Objekt leichter finden könnt. Ein Region Estate Manager sollte regelmäßig einen Blick auf diese Liste haben, schauen ob die Liste der Scripte und die verbrauchte Zeit nicht zu hoch ist und vor allem schauen, welche Scripte in welchen Objekten von wem laufen. Lasst uns nun zu einem weiteren wichtigen Tool kommen, um die Performance einer Region zu analysieren: das Statistik-Tool. Ihr erreicht es über die Tastaturkombination Ctrl+Shift+1 oder über den Menueintrag View->Statistics Bar. Bei Aktivierung dieser Funktion werden euch permanent die Statistikwerte der aktuellen Region im oberen rechten Bereich des Screens eingeblendet.

Die Statistiken bestehen aus drei Hauptunkten: Basic, Advanced und Simulator. In diesem Screenshot habe ich Simulator mit Klick auf den Text Simulator aufgeklappt und dann habe ich den Unterpunkt Time aufgeklappt. Hier seht ihr auch die Summe der komplett verbrauchen Zeit pro Frame: 3.8 ms. Mit diesen Infos könnt ihr euch ja einmal auf einigen SIMs bewegen und diese miteinander vergleichen. Ihr werdet enorme Unterschiede feststellen. Wichtig für einen ruckelfreien SIM ist auch der Wert (Frames per second). Weitere Informationen über euren SIM erfahrt ihr auch unter das About-Fenster eures Second Life®-Clients. Im folgenden Screenshot sehr ihr die IP-Adresse des SIMs Frankfurt West.

Mit dieser Info lässt sich zum Beispiel die Ping-Response-Time des Servers, auf dem Frankfurt West läuft, von außen herausfinden. Meiner Meinung handelt es sich hier allerdings auch um ein Sicherheitsloch. Diese Information eignet sich hervorragend für eine DDOS-Attacke. Ich sollte eigentlich keinen Zugriff auf diese Information der Region haben, da ich weder Owner noch Region Estate Manager von Frankfurt West bin.

Zusammenfassung

Zusammenfassend habe ich natürlich nur an der Spitze des Eisberges der Möglichkeiten des Performancetunings gekratzt. SLTalk & Partner schreibt aber gerade die Erfahrungen über SL-Performance in einem Whitepaper zusammen und sobald dieses fertig ist, werden wir es veröffentlichen. Bis dahin hier noch ein paar Tips:

Modellierung: Detailgrad der Prims
Programmierung LSL
SIM-Management

Wachstum bei Linden Labs / Secondlife

Patrick — Fri, 16 Feb 2007 11:03:00 +0000

Linden Labs braucht aufgrund des hohen Wachstums dringend Hilfe im Bereich IT-Betrieb. Am Grid ist dies deutlich zu spüren. Es ist oft sehr langsam, ich vermute Linden Labs kommt mit dem Aufbau neuer Hardware nicht hinterher. In dem Blogbeitrag schreibt Philip Linden, dass Sie vor technischen Herausforderungen bzgl. des Wachstums stehen, die viele Firmen noch nie gesehen haben. Das kann ich mir gut vorstellen. Der Zeitraum zwischen Bestellung eines SIMS (Insel) und der Freigabe kann bis zu 8 Wochen dauern. Linden Labs betreibt tausende von Linux-Servern (über 3000) an zwei Standorten, haben einen Traffic-Peak von 6Gbit pro Sekunde (!) und 100 Millionen MySQL-Transaktionen pro Tag. Aufgrund des hohen Datenvolumens für 3D-Daten (trotz Parametric Modelling) steht Linden Labs möglicherweise vor Herausforderungen in der Größenordnung eines Googles, Amazon, Ebay. Möglicherweise sogar höheren Herausforderungen. Ebenso ist ein hoher Anstieg an Kundenfragen zu verzeichnen, die eine SL-Repräsentanz ihrer RL-Firma realisieren wollen. Professionelle Projektabwickler sind deshalb gut beraten aufgrund der hohen SIM-Wartezeiten eine eigene SIM-Queue aufzubauen oder bestehende Inseln zu kaufen, die jedoch im Preis teilweise doppelt so hoch gehandelt werden, als eine Direktbestellung bei Linden Labs.