(26.01.2013, 15:13)LyAvain schrieb: Nein, man ist unabhängig. Man installiert Surabaya parallel zu den Sims die darauf zugreifen sollen...
Es nimmt den Sims nur die Kommunikation mit Inventar und Assetserver ab und schickt die Daten direkt zum Viewer. Ist also eine Auslagerung dieser Funktionen. Mehr eigentlich nicht.
Akira kann das aber noch besser erklären.
Na ja, die Erklärung ist schon mal ganz gut :-)
Aber zuerst mal etwas Geschichte: Surabaya ist aus einer Notlage entstanden. Das gesamte Jahr 2012 über kämpfte ich an allen Fronten die Freitagsparty im OSgrid, welche regelmässig von 20-30 Leuten besucht wird am Laufen zu halten.
Immer wieder passierte es, dass der Sim ausflippte. Dies äusserte sich darin, dass beispielsweise der Presence Service nicht mehr normal funktionierte und die Gäste danach nicht mehr an die Party telporten konnten. Irgendwas lief da schief.
Im Log äusserte sich dies vorallem dadurch, dass Anfragen an den zentralen Server oft horrend lange Zeit benötigten ( Mehrere Minuten ). Am schlimmsten war es dann wenn Leute mit leerem viewer Cache ankamen und begannen im Hintergrund das Inventar zu laden.
Da die Entwicklungsumgebung für Mono schon sehr rudimentär ist und eigentlich keine komfortablen Tools fürs Profiling zur Verfügung standen bin ich zwischenzeitlich kurz auf Windows umgestiegen und habe mit einem entsprechenden Profiler die Sims während der Party beobachtet. Sehr schnell stellte es sich heraus, dass in den Threads ( ein modernes Programm arbeitet heutzutage parallel oder wenigstens pseudo parallel, die einzelnen "Arbeiter" die da rumschuften nennt man Threads, die "gleichzeitig" laufen ).
Wann immer jemand auf der Partyregion landete wurden gleich ein paar Dutzend Threads gestartet die irgendwelche Aufgaben erledigten. Solche Aufgaben sind:
- Texturen holen
- Inventar laden
- Freundesliste aktualisieren
usw.
Unter Windows lief die Geschichte mit den Threads ganz gut, obwohl es auch da Situationen gab, wo JustinCC ( der aktivste der Entwickler ) dazu meinte, dass es sich wahrscheinlich um einen Thread Lock handelt. Bildlich gesprochen ist ein Thread Lock eine Situation wo zwei Threads ( Arbeiter ) auf eine Resource ( beispielsweise eine Schaufel ) zugreifen wollen. Bei einem guten Verhältnis, nimmt der erste Arbeiter die Schaufel,füllt eine Ladung in seine Schubkarre, gibt die Schaufel dem andern Arbeiter, der füllt ebenfalls eine Ladung in seine Schubkarre und gibt die Schaufel wieder dem ersten Arbeiter ... Wenn sich die beiden nun absolut nicht verstehen und koordinieren können, dann werden sie sich stundenlang um die Schaufel prügeln und die Schubkarren bleiben leer ... so etwa funktioniert es auch bei Threads die gegenseitig auf etwas zugreifen wollen. Wenn die Software gut programmiert ist können sich die Threads die Resourcen teilen, falls nicht, prügeln sie sich zwar nicht, sondern bleiben einfach stehen. Thread Locks traten aber nur sehr selten auf und waren nicht mein Hauptproblem, also musste im Mono etwas speziell sein.
Also war das Problem schon mal umzingelt... aber noch nicht zu meiner Zufriedenheit. Ich hatte ja erst ins Windows reingeschaut und gesehen, dass es dort bis auf einige Ausnahmen recht gut funktioniert. Ich wollte aber ins Mono rein sehen. Also musste ich etwas machen. Ich habe daraufhin das Logging so erweitert, dass ich auch im Mono die Threads beobachten konnte. Witziges Detail nebenbei... Es gibt im .NET Framework Statistikfunktionen mit welchen man die Anzahl Threads anschauen kann.. im Mono steht jedoch bei diesen Funktionen der lapidare Kommentar: "Not implemented" noch nicht implementiert. Jemand nettes hat mir dann aber eine ganz einfache Routine zur Verfügung gestellt mit der ich wenigstens in der Lage war die Anzahl der Threads abzufragen. Dazu musste ich aber erst den Sourcecode des Mono anpassen und Mono selbst umwandeln.
Wie dam auch sei, nun hatte ich meinen Monitor und mit der Zeit kannte ich den Sim dermassen gut, dass ich anhand des Kurvenverlaufs schon sehen konnte, ab wann der Sim instabil wurde ... dummerweise ging es jeweils seeeehr schnell, so dass meist keine Zeit zum Reagieren war. Was ich auch feststellen konnte, war die Tatsache, dass vorallem die neueren V3 Viewer die Problemverursacher waren. Insbesondere seit die Empfehlung rausgegeben wurde, die Capabilities "GetTexture, GetMesh, FetchInventory2, FetchInventoryDescendents2" auf "localhost" zu setzten. Das bewirkte intern, dass im OpenSim die entsprechenden "Handler" ( Programmteile, welche die entsprechenden http Anfragen entgegen nehmen und an die Threads ( Arbeiter ) weiterleiten ) auch gestartet werden.
Erster logischer Gedanke, und Test: Schalten wir die Dinger wieder aus... die Viewer funktionieren auch ohne ( wenn auch nicht so super schnell ). Das hat auch recht gut funktioniert aber leider nicht in jedem Fall.
Als dann wieder ein paar Parties gecrasht sind ( inzwischen konnte ich auch mit meinem Monitoring sehr rasch herausfinden, welcher Viewer der Verursacher war) , haben wir dann die Notbremse gezogen: Verbannung der V3 Viewer. Das hat einen riesigen Sturm der Empörung ausgelöst. Insbesonders am Geburtstagsfest des OSgrids hab ich mir einige böse Kommentare [Schimpfwörter nach eigenem Gutdünken einfügen] anhören müssen. Aber wir sind nicht gecrasht. Im Gegensatz zu der Vollversammlung am nächsten Tag :-)
Dennoch, die Situation war nicht gut. Auch als Prinz auf Michelles Regionen einen Woche lang Oktoberfest feierte, hatten wir nichts als Probleme, obwohl auch Michelle die entsprechenden Viewer verbannt hatte. Ich hatte in der Zeit auch wieder massiv Probleme die wahrscheinlich auch darauf zurückzuführen waren, dass an der zentralen Infrastruktur im OSgrid nicht ganz alles rund lief.
Ich hatte in der Zeit riesig lange Diskussionen mit Michelle und anderen Leuten und wir haben festgestellt, dass zum einen die Distanz zu den zentralen Servern für uns Europäer problematisch ist. Die Server waren ja zu dem Zeitpunkt irgendwo im Netzwerk einer Californischen Uni integriert ( obwohl auf einer der offiziellen Serverlisten geschrieben wurde, dass sie in Dallas liegen ) egal, auf alle Fälle einige Tausend Kilometer von unseren Servern entfernt.
Bei mir wurde es langsam eng, ich hatte ja meinen grossen Urlaub geplant und während des Urlaubs habe ich nicht die Zeit die Server gross zu hätscheln, geschweige denn während der Party die Monitore zu beobachten. Also war der naheliegende Schluss, wenn die zentralen Server nicht zu mir kommen, dann gehe ich zu den zentralen Servern. Die Amazon Cloud erstreckt sich ja weltweit über mehrere Rechenzentren. Eines dieser Rechenzentren ist in California aufgebaut und dort habe ich mich dann eingerichtet um dort für die Freitagsparty jeweils einen Rechner hochzufahren ... sicherheitshalber unter Windows. Das funktionierte soweit ganz gut und gab mir etwas Luft.
Auch andere hatten inzwischen das Problem und Melanie hat uns sogar einen Patch gemacht, der ein Problem lösen sollte. .Net ist irgendwie so spezifiziert, dass zwischen zwei IP auf demselben Port genau zwei Verbindungen aufgemacht werden. Das kann man natürlich übersteuern und genau das hat Melanie eingebaut. Eigentlich logisch, wenn der Viewer achtfach parallel Texturen beim Region Server anfrägt und die Anfragen Region Server nur zweifach parallel an den zentralen Asset Server gehen, dass es dann Staus gibt. Bloss unter Mono funktioniert das Erweitern der Anzahl Verbindungen nicht !!! Grrr... und wann dieser Bug gefixt wird ... das wissen wahrscheinlich nicht mal die Mono Entwickler, und so wird dieses Problem wahrscheinlich genau so wie meine Anfrage nach den Thread Statistiken irgendwo auf einer ToDo Liste landen.
Während der Diskussionen mit Michelle und andern kam auch die Idee auf, dass wir mehr im Flotsam Cache machen müssten um weniger abhängig von den zentralen Servern zu sein. Flotsam heisst ja übersetzt "Treibgut"... Irgendwann sagte ich zu Michelle, eigentlich will ich gar nicht ein verbessertes "Treibgut" sondern einen richtig guten Schiffshafen, wo der Warenverkehr in geordneten Bahnen abläuft. Ich hab etwas rumgegooglet und dann gesagt, wenn ich Projekt starten würde, dann nenn ich das Surabaya ... Viele ??? kamen dann aus dem Chat zurück und meine Antwort war: Guggst du hier:
http://de.wikipedia.org/wiki/Surabaya
Surabaya ist eine grosse Hafenstadt in Indonesien auf der Insel Java. Java ist nicht nur eine Insel, sondern auch ein Wort für den ( scheusslichen ) amerikanischen Kaffee ... und ... eine Programmiersprache / Laufzeitumgebung welche in vielen grossen Unternehmen eingesetzt wird. Im Gegensatz zu .NET welches die Antwort von Microsoft auf Java ist und leider nur auf Windows Rechnern funktioniert (abgesehen von Mono, welches ein Nachbau der .NET Spezifikation unter Linux ist), ist das bevorzugte Betriebssystem für die Java Virtual Machine: Unix ( davon natürlich die Abwandlung Solaris, weil der "Erfinder" von Java, die Firma Sun, Rechner verkaufte auf denen das Unix System "Solaris" lief. Aber selbstverständlich gab es auch Java Versionen für alle andern Betriebssysteme inklusive Windows und die waren ALLESAMT von Sun unterstützt! Java wurde von der Entwicklergemeinde (ausser den auf Windows fokussierten) begeistert aufgenommen und recht schnell wurden in der kommerziellen aber auch in der OpenSource Szende tausende und abertausende Lösungen für beinahe jedes Problem entwickelt.
Und auch eines hat Sun recht schnell begriffen: Man muss die grossen Unternehmungen unterstützen, damit sie schön viele Sun Rechner kaufen. Also wurde sehr schnell Unternehmens Standards in Java entwickelt, genannt Java Enterprise Edition. Grosse Unternehmen im Banken-, Versicherungs- und Verwaltungsbereich machen eigentlich nichts anderes als dauernd auf Datenbanken zu schreiben und von Datenbanken zu lesen und in der Zeit hatten auch viele Unternehmen das Problem ihre Computer immer mit der neusten Software auszustatten, also wollten diese Unternehmen einfache zentral administrierbare Lösungen, die mit einem normalen WebBrowser zu bedienen sind, so dass nicht mehr gross Software verteilt werden muss. Genau zu diesen Problemen hat Sun eine Referenzlösung gebaut und Hersteller wie BEA, und IBM haben diese Lösung mit ihren Produkten wie "WebLogic" und WebSphere" verfeinert. Auch im OpenSource Bereich wurde einiges gemacht und Lösungen wie "JBoss" und andere wurden geboren. Aber auch an der Werkuzeug Front hat sich einiges getan, und mit Eclipse und Netbeans und IntelliJ stehen uns super komfortable Entwicklungsumgebungen zur Verfügung und weil viele Unternehmen auch oftmals Probleme mit der Performance haben, können wir inzwischen auf ein recht grosses Sortiment an überaus komfortablen und mächtigen Profilern zugreifen. Sprich das Oekosystem von Java lebt und gedeiht und entwickelt sich prima neben der Microsoft Monokultur.
Da ich kurz vor dem Urlaub auch noch einen chat mit jemandem hatte, der ebenfalls an einer Java Lösung für OpenSim arbeitet ( er fokussiert sich jedoch eher auf den Ersatz der zentralen Server ) war für mich der Plan klar. Das Abarbeiten von HTTP Requests ( dort wo JEE echt stark ist ) aus dem OpenSim auslagern in eine Java Lösung unter Zuhilfenahme von allem was mir das Java Oekosystem bieten kann. Mit dieser Idee setze ich mich in den Flieger und ziemlich genau sechs wochen später kehrte ich mit einer Lösung, die einigermassen funktionierte ( Jede Lösung hat Kinderkrankheiten insbesondere wenn ich sie im Urlaub nur lokal und nicht unter Grid Bedingungen testen konnte ) zurück.
In der Surabaya Lösung sind die HTTP Zugriffe für GetTexture, GetMesh, FetchInventory2 und FetchInventoryDescendents2 implementiert. Eine kleine Aenderung musste ich im OpenSim machen, diese Aenderung macht aber nichts anderes als dem Viewer ( der HTTP Aufrufe tätigen kann ) mitzuteilen: "Hey Viewer, hol doch bitte deine Texturen, und das Inventar mit allen Unterverzeichnissen beim Surabaya Server und nicht beim OpenSim Server" und nett wie die Viewer sind, machen sie auch genau das. Dies hat nun einen riesigen Vorteil. Im Gegensatz zu Mono, kann der Surabaya Server in beliebiger Parallelität Anfragen gegen den Asset Server schicken. Ly und ich haben es mal ausprobiert. 64 fach parallel vom Viewer aus, das geht kein Problem! Und der Mono OpenSim Server kriegt von dem alles nix mit ( braucht er auch nicht, Inventar und Texturen ist etwas was nur der Viewer benötigt ). Selbstverständlich hab ich auch ein Caching eingebaut. Mit Infinispan oder EHCache stehen da Industrie erprobte Lösungen zur Verfügung. Ich habe Infinispan gewählt weil es mit dem JBoss gleich mitgeliefert wird.
Fazit der Uebung. Der OpenSim Server kann sich nun auf seine Kernkompetenzen konzentrieren, die da sind: UDP Pakete verarbeiten, Scripts ausführen, Physikberechnungen durchführen. All die andern Aufgaben wo der OpenSim Region Server eh nur Durchlauferhitzer spielt soll nun der Surabaya Server übernehmen und da er so schön skaliert, kann er dies gleich für mehrere Region Server erledigen.
Wer braucht nun so was? Kurz: Potentiell alle, welche richtig viel Leute gleichzeitig auf ihren Regionen haben wollen, und deren Server unter Mono laufen. Für Sims mit bis zu 10 Leuten ist ne Surabaya Lösung massiv überdimensioniert, das bringt nichts. Speziell wenn die zentralen Server weit weg von den Region Servern sind, so wie es im OSgrid der Fall ist, kann Surabaya seine Stärken ausspielen. Für Grids wie Dorenas World oder Metropolis, wo alles recht nahe beisammen ist, kann mit einer Surabaya Lösung wahrscheinlich erst ab 40 bis 50 Leuten eine spürbare Verbesserung erreicht werden. Aber ich habe noch keine Installationen, geschweige denn Erfahrungswerte in den entsprechenden Grids.
Wie geht es weiter? Aktuell hab ich noch schmerzen in der Gegend der Friends Services und der Groups Services. Mit richtig grossen Freundeslisten ( ich habe im OSgrid 840 Leute in meiner Liste ) und richtig grossen Gruppen ( ab 500 Leute ) kann man dem OpenSim Region Server noch mächtig Schmerzen bereiten. Da werd ich sicher noch etwas machen. Eventuell bieten sich weitere CAPS an die auf den Surabaya Server implementiert werden können "UploadBakedTexture" ist eines, was mir in der letzten Woche Sorge bereitete, denn mit dem Erscheinen vom Singularity 1.7.3 waren plötzlich alle Texturen der Avatare auf einem von Surabaya unterstützten Sim nur noch grau ( nicht so auf einem ganz normalen OpenSim ) und mir war recht schnell klar, dass hier der OpenSim Server das kurzzeitige Abspeichern und den andern Avataren zur Verfügung stellen der "gebackenen" Texturen übernimmt, also eine Aufgabe die der Surabaya Server auch ganz gut übernehmen kann. Deshalb hab ich da eine erste Lösung eingebaut, die muss aber auch noch unter Last getestet werden.
Soweit ist das Projekt sicher noch seehr Alpha ... und sicherlich noch nicht für eine breite Oeffentlichkeit gedacht. Dokumentation gibt es auch noch nicht und schon gar nicht Installationsanleitungen mit bunten Bildchen. Und Support werde ich sicher auch noch keinen leisten. Also im moment abwarten und Tee rauchen und an Parties kommen :-)
LG Akira
obwohl ich alleine auf dem Sim war*g*
