Revision as of 06:29, 14 August 2017

Languages:

English    Deutsch    Français

Introduction

Les performances de OpenSimulator sont un problème trés complèxe. Les performances peuvent être affectées par un grand nombre de choses, incluant le nombre de prims sur une région, le nombre de régions, le nombre d'avatars, la qualité du réseau entre le serveur et le client, la qualité du réseau entre le simulateur et les services de la grille, etc...

Nous pouvons décomposer les domaines d'influence sur la les performances performances ainsi :

1. les problèmes liés au réseau (bande passante et latence entre viewer et simulateur, entre les simulateurs, entre un simulateur et les services de grille).

1. les problèmes liés au simulateur (par exemple, nombre d'objets dans la scène, nombre de textures, nombre de scripts)

1. les problèmes liés à la grille (principalement le dimensionnement de services comme les assets, l'inventaire, etc... pour servir plus de simulateurs et utilisateurs).

Les problèmes les plus importants sont probablement les problèmes de réseau et de simulateur.

Pour lancer un simulateur vous devez avoir une bonne bande passante (pour charger les textures), une bonne latence (de sorte que les mouvements et les actions soient traités au bon moment sans proviquer de lag) et une bonne qualité (de sorte qu'une perte aléatoire de paquets ne provoque pas de perte d'action ou d'autres problèmes).

Vous devez aussi faire attention aux capacités de votre matériel. Plus vous avez d'objets, de scripts et d'avatars dans la scène, plus la mémoire et les CPU seront utilisés.

Les problèmes de grille sont moins importants si vous n'atteignez pas la taille d'une grille plus grande (par exemple, plus de 60 utilisateurs simultanés).

Monitoring des performences

La collecte des données en vue d'analyser les problèmes de performence d'OpenSimulator est un domaine qui évolue. Nous pouvons la diviser en deux sous-domaines :

• la surveillance côté client (en) ( par exemple : les statistiques que vous pouvez voir dans la fenêtre des statistiques du viewer),
• l'analyse des performences côté serveur. Elle impliquera la surveillance du serveur OpenSimulator et l'utilisation d'outils systèmes généraux (par exemple sous GNU/Linux le programme "top" surveille les besoins CPU/mémoire des processus et des outils de surveillance plus généraux tels que Zabbix).

Conseils généraux

• Dans la mesure du possible, quand vous pensez que quelque chose est un goulet d'étranglement, mesurez le! Vous pouvez penser que votre base d'assets est grande, par exemple, mais même une grande base de données d'assets peut rarement causer de réels problemes.

• Faites autant le plus d'objets fantômes possibles. Les objets fantômes n'ont pas besoin d'être testés pour les collisions avec les avatars et les autres objets, ce qui réduit le temps de frame physique et améliore les performences.

• Faites aussi peu d'objets physics que possible (par exemple: soumis à la gravité, déplacement par des avatars). Les objets physics ont besoin de beaucoup plus de tests de collision que les objets ordinaires non fantômes.

• Il peut être difficile de pratiquer des mesures actuellement étant donné que peu d'outils de mesure existent. Cependant, l'un d'eux est pCampbot qui est fourni avec OpenSimulator. Il peut instancier un certain nombre de clients libomv sur un simulateur qui peuvent effectuer certaines actions comme cliquer sur les objets et sautiller tout autour. Leur aspect (ex : apparence) est actuellement assez buggé et génère beaucoup de problemes de connexion.

• Si vos avatars se heurtent beaucoup ou volent de façon incontrôlable, c'est souvent le signe d'une perte de paquets dûe à un problème de réseau. Le simulateur essaie d'envoyer 3 fois les paquets importants, mais après cela,il les abandonne. Dans la console du simulateur, la commande "show queues" (afficher les files d'attente) indiquera le nombre de paquets que le simulateur doit renvoyer et le nombre total de paquets envoyés. Si le nombre total renvoyé est supérieur à 10% c'est le signe qu'il y a un problème de réseau, au moins entre un viewer particulier et le simulateur. Le poblème peut se situer côté utilisateur (par exemple : utilisation du wifi via un routeur défectueux, un FAI peu performant). Dans ce cas, il est difficile de trouver des solutions.

3 types de Ticks

Si vous mesurez le temps en C#, sachez que le mot "Tick" est surchargé : il y a 3 usages différents pour Tick et il est important de ne pas les mélanger.

1. Chronomètre - les résolutions dépendent du système d'exploitation. Stopwatch.Frequency contient le nombre de ticks par seconde. Pour Windows, il s'agit d'environ 300 ticks par milliseconde.
2. TimeSpan - 10,000 ticks = 1 milliseconde
3. Environment.TickCount - 1 tick = 1 milliseconde

Il est recommandé d'utiliser la classe Stopwatch pour le chronométrage parce qu'elle peut mesurer des temps inférieurs à la milliseconde. Vous pouvez obtenir la valeur du chronomètre en ms en appelant Stopwatch.ElapsedMilliseconds.

Si vous voulez ajouter des temps, par exemple pour obtenir le temps d'exécution d'un script, puis cumuler les résultats de l'utilisation de Ticks de Stopwatch : à nouveau, car c'est la seule minuterie haute résolution disponible. En faisant cela, vous obtiendrez une variable 'longue' qui contient le nombre de ticks. Si vous souhaitez convertir cette valeur en temps écoulé, utilisez un code comme celui-ci :

long numStopwatchTicks = xxxx;
TimeSpan elapsed = TimeSpan.FromMilliseconds((numStopwatchTicks * 1000) / Stopwatch.Frequency);

MetricsCollectorTime (pas traduit)

The class MetricsCollectorTime may be useful to you. It implements a sliding window that collects performance measurements. For example, its' used to calculate the total execution time over the past 30 seconds for each script. For example, instantiate it as follows:

MetricsCollectorTime executionTime = new MetricsCollectorTime(30000, 10);

This creates a sliding window that covers 30 seconds (30000 ms), and has 10 "buckets". The buckets determine the granularity of the window: in this case, it's 30/10 = 3 seconds.

Whenever you get a timing sample, add it to the collector:

Stopwatch timer = new Stopwatch();
// Measure something with 'timer'...
collector.AddSample(timer);

Whenever you want to get the total value in the collection window, call:

int elapsedMS = collector.GetSumTime().TotalMilliseconds;

MetricsCollectorTime is actually a subclass of the generic MetricsCollector class. The generic class can use any data type as the Sample value. It uses a circular buffer for its buckets, so it's highly efficient.

Sujets liés à la performance du viewer

Les problèmes de performance peuvent être aussi résolus côté viewer. Cela implique généralement d'abaisser les paramètres graphiques du viewer (par exemple réduire la distance d'affichage du viewer). Pour plus d'informations, voir cette page en anglais : https://community.secondlife.com/knowledgebase/english/how-to-improve-viewer-performance-r601/

Sujets liés à la performance du simulateur

Besoins matériels

Malheureusement, c'est une question tres difficile à la lumière de tous les facteurs mentionnés dans l'introduction. Les éléments les plus importants sont listés et développés ci-dessous :

CPU

Cependant, nous pouvons dire qu'OpenSimulator ne fonctionne pas bien quand il a seulement accès à un seul CPU - vous devriez penser au minimum à une machine dual-core.

Une règle approximative de base consiste à dire qu'il faudrait avoir un core par région normalement utilisée avec un total minimum de 2 cores. Ainsi, un simulateur de 4 régions aurait besoin de 4 cores. Cependant, cela suppose une utilisation continue de ces régions - on peut probablement s'en sortir avec un nombre de régions plus élevé si ces régions sont moins utilisées (ou ne sont pas utilisées simultanément).

Sur OpenSimulator 0.7.6, nous avons également observé qu'une région peu active (avec très peu de scripts, tous inactifs et sans avatar sur la région même et les régions voisines) requiert approximativement 2,5% de CPU. Les besoins avant OpenSimulator 0.7.6 étaient plus élevés.

Nous pouvons aussi dire, encore une fois de façon très approximative, que chaque avatar actif utilisise 8% de CPU. Un avatar actif est un avatar qui se déplace et la cause principale de cette charge est le traitement des physics par le plugin ODE, moteur de physics. D'autres moteurs de physics, comme Bulletsim, nécessitent moins de CPU.

Les scripts qui fonctionnent en continu (comme les scripts avec timer)vont également générer une charge CPU continue pour la région. Quelques scripts de ce type ne vont probablement pas avoir trop d'impact, mais un nombre plus important de scripts va commencer à consommer plus de ressources CPU.

Finalement, les objets physiques (qui ont la case à cocher physics activée dans le viewer et qui peuvent être déplacés par la gravité ou des collisions) généreront aussi une charge CPU physic pour le simulateur, s'ils ne sont pas au repos.

Mémoire

En règle générale, une région avec beaucoup d'avatars, 15000 ou plus de primitives et 2000 scripts peut utiliser 1 Go de mémoire. Donc un simulateur avec 4 régions de ce type peut avoir besoin de 4 Go. Mais on peut utiliser moins de mémoire, si toutes les régions ne sont pas occupées simultanément par des avatars, ou par exemple, s'il y a moins de scripts.

Disque

Au niveau du simulateur, les performances de stockage ne sont pas un gros problème, à moins d'utiliser des scripts qui nécessitent des performances extrêmement élevées pour rezzer et dérezzer des objets. Même dans ce cas, les disques durs de bureau ( 7200 trs/min, 3.5") devraient suffir. Les problèmes commencent seulement avec des disques dur moins performants, tels que ceux trouvés dans des ordinateurs portables.

Au niveau de la grille, un stockage plus rapide peut être utile lorsque vous devez gérer un grand nombre de requêtes sur les assets, les inventaires ou autres services.

Réseau

Les bandes passantes ascendante et descendante et la latence (lag) sont importants.

L'utilisation la plus importante de bande passante de transfert (du point de vue serveur) concerne l'envoi des textures aux viewers. Ainsi, un réseau domestique avec une faible bande passante (par exemple 384 kbits) impliquera un mauvais résultat côté viewers, au moins, jusqu'à ce qu'ils aient reçu toutes les données de texture. Les besoins de bande passante de transfert sont au maximum quand un viewer entre dans une région pour la première fois ou après un nettoyage de cache. La quantité de bande passante nécessaire varie considérablement avec le nombre de textures sur la région. Une règle de base très approximative est d'avoir 500 kbit par avatar enregistré simultanément sur une région, du fait que tous les avatars vont charger les textures de cette région au même moment.

L'utilisation la plus importante en bande passante de téléchargement (point de vue serveur) concerne la réception continue des messages UDP des mouvements des avatars connectés. Cependant, par rapport au téléchargement de textures, la bande passante requise est bien moindre : une règle approximative la définit à 10k (80 kbit) par avatar.

La latence est essentielle au téléchargement et au transfert vers le simulateur, car tout retard affectera les paquets liés au mouvement de l'avatar (téléchargement sur le serveur depuis le viewer) et les mises à jour du viewer pour les changements de position des autres objets/avatars (transfert du serveur vers le viewer). Il est plus difficile de donner des conseils dans ce cas, bien que des pings de plus de 350 millisecondes commenceront à dégrader l'expérience de l'utilisateur pour le déplacement de leur avatar.

Exemples

Ci dessous, voici quelques examples de machines que des personnes ont utilisé/possédé. S'il vous plait, n'hésitez pas à en ajouter à la liste (sur la page anglaise) ou ajouter toute information dans les études de performances et la section des articles de blogs. Ceci sont des exemples pour vous aider dans votre sélection et ne sont pas des recommandations nécessaires.

Elements d'objets ~= # prim

Les capteurs et timers sont généralement plus intensifs que les scripts simples, donc spécifiez la quantité de chacun.

Base de données

Par défaut, OpenSimulator est configuré pour utiliser une base de données SQLite. C'est vraiment pratique pour une expérience immédiate car cela ne nécessite pas de configuration. Cependant, ce n'est pas conçu pour une utilisation lourde, donc si vous construisez tres vite ou avez plus que quelques personnes sur votre simulateur alors vous commencerez à voir des problèmes de performances.

Par conséquent, nous vous recommandons de basculer sur MySQL aussi tôt que possible. Ceci fournira une bien meilleure expérience mais prendra un petit peu de travail pour la configuration.

Malheureusement, les outils pour migrer les données SQLite d'OpenSimulator vers MySQL sont actuellement limités. La migration est également possible en sauvegardant les OAR/ IAR de vos données à partir de sqlite et en les chargeant après avoir reconfiguré votre installation pour utiliser MySQL.

Il y a aussi un plugin pour MSSQL mais il n'est pas bien maintenu entre les versions de OpenSimulator.

En mode standalone, les services et le simulateur lui-même peuvent utiliser SQLite. En mode grille, SQLite n'est pris en charge que pour les données du simulateur, les instances ROBUST doivent utiliser une base de données MySQL (ou MSSQL).

En général, une seule instance MySQL pour l'ensemble des instances des services ROBUST servira parfaitement les petits, moyennes et grandes grilles. C'est une configuration largement utilisée même pour des sites assez volumineux.

Scripts

Voir Scripts Performance.

Bidouilles de configuration

Il y a quelques bidouilles de configuration d'OpenSimulator que vous pouvez faire pour augmenter significativement les performances de charge des scripts dans certaines situations. Ces bidouilles peuvent être faites dans votre fichier de configuration OpenSim.ini. Ceux ci s'appliquent au code actuel de developpement (0.7.3) d'OpenSimulator et peuvent être appliquées à 0.7.2 mais certainement pas en dessous.

Définir DeleteScriptsOnStartup = false

[XEngine]
DeleteScriptsOnStartup = false

Ceci veut dire que OpenSimulator ne supprimera pas toutes les DLL des scripts compilés au démarrage (ne vous inquiétez pas, ce réglage ne touche pas les scripts LSL actuels dans votre région). Ceci va énormément faire progresser les performances de démarrage. Cependant, si vous faites des mises à jour de OpenSimulator sur place (par exemple, si vous mettez fréquemment à jour votre installation de OpenSimulator depuis le code de développement) , alors vous pouvez occasionnellement voir des problèmes si le code change et vos DLL précédemment compilées peuvent ne pas trouver leurs anciennes références.

Dans ce cas, vous pouvez définir DeleteScriptsOnStartup = true pour un redémarrage dans le but de nettoyer et recompiler les DLL de scripts ou bien vous pouvez supprimer manuellement les fichiers bin/ScriptEngines/<region-uuid>/*.dll.*, qui forceront OpenSimulator à les recompiler. Vous pourriez aussi supprimer le dossier bin/ScriptEngines/<region-uuid> au complet mais vous perdrez tous les états persistants de script (qui sont gardés dans les fichiers <script-item-id>.state).

Définir AppDomainLoading = false

[XEngine]
AppDomainLoading = false

Par défaut, OpenSimulator charge chaque DLL de script dans son propre AppDomain. Si il est défini sur false, alors les script sont chargés dans le AppDomain par défaut de OpenSimulator à la place.

Ceci va énormément faire progresser les temps de démarrage des scripts et réduire la surcharge mémoire initiale par script.

Cependant, définir cela sur false va aussi empêcher les DLL des script dérezzés d'être supprimées de la mémoire (seulement tout le AppDomain peut être déchargé). Ceci peut créer un dépassement de mémoire avec le temps quand les avatars avec des scripts attachés viennent et partent de la région. Si cela sera un problème pour vous va dépendre de facteurs comme comme la population d'avatars sur votre grille.

De plus, les utilisateurs de Windows ont reporté des problèmes de chargement de scripts avec AppDomainLoading = false, quoique je (justincc) n'ai pas été capable de reproduire cela avec le code de OpenSimulator sur ma machine WindowsXP.

Augmenter MaxPoolThreads dans [Startup]

À l'heure actuelle, OpenSimulator utilise jusqu'à trois ensemble de threads pour ses opérations.

Tout d'abord, threadpool VM est toujours utilisé pour traiter les données réseau entrantes.

Deuxièmenent, par défaut, une instance d'un paquet threadpool triers appelé SmartThreadPool est utilisée pour exécuter de courtes tâches OpenSimulator. Ici, la performance est importante car de nombreuses demandes émanant des viewers sont traitées par des threads de ce threadpool.

Troisièmement, XEngine génère son propre threadpool pour les tâches du moteur de scripts. Cependant, les performances ici ne sont pas critiques.

Lorsque vous utilisez SmartThreadPoll, dans OpenSimulator 0.8 et versions antérieurs le paramètre par défaut MaxPoolThreads s'est avéré vraiment trop bas (à 15 threads) pour des nombres importants à modérés d'avatars (par exemple 40). Dans le code de développement actuel, la valeur par défaut est passée de 15 à 300. Donc, si vous rencontrez des problèmes de lag dans le viewer et que les ressources CPU ne sont pas dépassées, vous pouvez corriger cette valeur. Pour définir ce paramètre à 300, vous pouvez effectuer la modificaion suivante dans OpenSim.ini.

[Startup]
MaxPoolThreads = 300

Bien que cela permette de créer plus de threads (ce qui va utiliser plus de ressources serveur), de toute façon, c'est probablement ce que vous voudrez, si cela est possible, car l'aternative est d'être confronté à un retard du traitement des données UDP entrantes du viewer. Les threads supplémentaires ne seront créés que s'ils sont nécessaires.

Changer async_call_method dans [Startup]

Alternativement, vous pouvez modifier complètement le threadpool général des tâches.

SmartThreadPool a été défini par défaut pour des raisons historiques. La performance du threadpool mono était plutôt médiocre.

Cependant, les versions récentes de Mono proposent de meilleures solutions (en particulier pour 3.x et suivant). De plus, les performances générales de thread de Windows peuvent être meilleures que SmartThreadPool.

Donc, sur ces systèmes, vous pouvez essayer d'expérimenter une configuration comme :

[Startup]
async_call_method = UnsafeQueueUserWorkItems

sous Windows et même Mono.

Sous Mac OSX, il existe un système appelé Grand Central Dispatch qui implémente efficacement un threadpool sous le niveau VM. Sur ces systèmes, cette simple configuration permet d'améliorer la performance d'OpenSimulator.

[Startup]
async_call_method = Thread

Cependant, au moins sur OSX, vous devrez augmenter le nombre de fichiers gérés par un processus. Voici ce que Gavin Hird dit à ce sujet :" j'ai constaté qu'en utilisant async_call_method = thread, le système manquait de fichiers ouverts par processus car un grand nombre de threads ont accédé aux fichiers floatsamcache simultanément. Pour tout *nix vous devez ajuster le paramètre 'limit-n'.

Sur OS X, le fichier /ect/launchd.conf a besoin d'une ligne contenant "maxfiles limite 2048 65536" où 2048 est le nombre de fichiers ouverts autorisés par processus, et le nombre le plus élevé de fichiers ouverts par système. Le fichier doit être créé s'il n'existe pas. Alternativement, le fichier peut être créé à ~ / launchd.conf pour l'utilisateur exécutant OpenSim.exe si vous ne voulez pas que ce soit un paramètre système."

Sujets liés à la performance de la grille

Agrandir une grille est une tâche tres complexe et tres portée sur la technique. C'est aussi un endroit étudié attentivement. Le conseil suivant va considérablement changer dans le temps car OpenSimulator et son environnement changent et nous apprenons plus à propos des problèmes de performances.

Quand souhaitez-vous commencer à répondre à des questions d'échelle de grille ? Tout comme une règle pessimiste et arbitraire au doigt mouillé, vous allez probablement commencer à penser aux choses quand vous dépasserez 50 régions contenant un grand nombre de prims ou 50 utilisateurs simultanés avec de grands inventaires, mais ceci sera plus ou moins énorme dépendant de votre situation. Si vous avez des milliers de régions avec seulement quelques prims est beaucoup plus supportable que 50 régions avec chacune 45000 prims.

Vous allez rencontrer des problèmes à deux endroits - la base de données et les services.

Database

Assets

Le problème

Dûe à l'architecture distribuée de OpenSimulator, quand les régions exécutent un certain nombre de machines à travers un réseau, il est extrèmement difficile d'identifier les assets qui ne sont pas en utilisation et qui peuvent donc être supprimés. Egalement, le fait que les assets soient en agrandissement permanent dans la base de données des assets.

En théorie, on pourrait identifier les assets inutilisés si on pouvait identifier toutes les références dans les simulateurs et les inventaires des utilisateurs. Cependant, c'est tres difficile car les machines sont distribuées sur un réseau. Si une grille possède seulement quelques simulateurs tous controlés par la même entité formant une grille, alors ils deviennent plus facilement traçables mais impliquerait une certaine durée de mise hors service. Aucun outil public existe pour faire cela.

L'effacement des assets serait plus facile pour une grille avec un seul simulateur ou une standalone. Cependant, meme le code à implémenter pour la destruction des assets sur les standalones n'a pas été implémenté et nécéssiterait un temps d'arrêt significatif du simulateur.

Un terrain de recherches prometteur implique l'amélioration de l'enregistrement des temps d'acces aux assets d'OpenSimulator (ex : enregistrer les assets périodiquement). Alors les assets qui ne sont pas utilisés depuis une longue durée (comme une année) pourraient être supprimés ou déplacés vers un autre enregistrement comme un dvd. Ceci n'evite pas le probleme des assets cachés en permanence par les simulateurs mais peut ceci peut être résolu par les simulateurs effectuant un "ping" occasionnel au service d'assets l'informant sur les assets qu'ils ont en cache.

Une autre étape pour réduite la taille de la base de données des assets est d'éliminer les doubles par le "hashing". Il existe un service s'asset expérimental en développement pour cela. D'autres services comme [SRAS] font aussi cela.

Solutions possibles

• Ne rien faire. MySQL peut stocker une tres grande quantité de données avant de recontrer des problemes - apres tout, il est utilisé pour des sites web énormes et d'autres applications. Ceci assume que vous ayez l'espace disque.

• Utiliser un service externe comme [SRAS]. SRAS, en particulier, est un service d'assets tiers partie qui effectue une déduplication et enregistre les assets sur le disque au lieu de la base de données. Il possède aussi des fonctionnalités interessantes comme la prévention de fourniture d'assets sans les supprimer. Il est utilisé par OsGrid par exemple. Cependant il fonctionne d'une façon différente au service d'assets fourni avec OpenSimulator (ex : enregistrer les assets sur le disque nécessites des étapes supplémentaires comparé au simple stockage en base de données). Il nécessite aussi une étape de migration qui peut prendre un temps considérable si vous avez une collection d'assets déjà existante.

• Sauver chaque région dans un OAR et chaque inventaire utilisateur dans un IAR. Nous estimons que c'est équivalent à trouver chaque asset référencé et peut être fait manuellement. Cependant, c'est tres laborieux pour les installations avec un grand nombre d'utilisateurs et nécessite un temps d'arrêt de la grille. Des outils peuvent être écrits pour améliorer cela, particulierement en sauvant systématiquement les inventaires de tous les utilisateurs dans des IARs.

Autres bases de données

L'emplacement requis par les assets l'emporte sur les besoins de stockage donc seules les données des assets est généralement un problème.

Services

Le problème

L'autre problème est de supporter le nombre de requetes aux services quand le nombre de simulateurs ou utilisateurs grandit. Le service d'assets n'est généralement pas un problème car les simulateurs mettent en cache tous les assets utilisés, par contre il peut y avoir un étranglement lors d'upload des OAR. Le plus gros problème est généralement causé par les utilisateurs, principalement dû à l'acces à l'inventaire et peut être lors de la mise à jour de la derniere position dans le service GridUser (et la table de la base de données).

ROBUST utilise un [serveur HTTP en C#] intégré. Les comparaisons de performances avec les autres serveurs web comme Apache n'ont pas été réalisées (?) mais les réponses apparaissent vraiment plus lentes. Comme il a été interrompu, il y a peu de chances que ses performances soient améliorées. Dans le futur, OpenSimulator devrait intégrer un autre serveur HTTP mais ce n'est pas du tout prévu à court terme.

Solutions possibles

• Séparer les services. Par défaut, ROBUST exécute chaque service dans un processus. Cependant, comme les services sont séparés entre eux, vous pouvez exécuter quelques services comme l'inventaire dans des instances différentes de ROBUST même si ils pointent vers la même base de données. Comme le serveur web en C# intégré est lent et possiblement pas tres concurent, ceci peut effectuer des performances significatives même si les instances de ROBUST s'exécutent sur la même machine.

• Instancier des copies supplémentaires de ROBUST copiant le problème des services comme l'inventaire. A cause du fait que les services sont indépendants comme un webservice, vous pouvez equilibrer la charge des requetes entre de multiples instances en utilisant un proxy inversé comme nginx. Encore une fois, étant donné que le serveur web intégré est probablement innéficace, vous pouvez effectuer des améliorations de performances en exécutant de multiples copies des services sur la même machine.

• Utiliser un service externe basé sur un serveur HTTP plus efficace. Encore une fois, SRAS est une application Ruby on Rails qui peut être exécutée sur Apache. Malheureusement actuellement seul un service d'assets externe est disponible.

• Ecrire vos propres services pour les exécuter sur un serveur externe. Ceci ne devrait pas être trop difficile à faire avec quelque chose comme PHP, quoiqu'il faille travailler sur des liaisons non documentées. Si vous faites cela, s'il vous plait, tenez nous au courant :)

Etudes de performances et articles de blogs

Ceux ci fournissent des données intéressantes sur les limitations de performance d' OpenSimulator à différents moments dans le temps.

• https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html - Quelques informations intéressantes de Mr Blue. Les objets physiques et les avatars sont limités par un seul thread de performance dans OpenSimulator.
• http://www.sciencesim.com/wiki/doku.php/vwperf/start - Liens vers les études de performances de ScienceSim en incluant certaines tres récentes.
• Improving Performance - Vielle page de Juillet 2009 détaillant les problèmes de performances sur OpenSimulator. Certains de ces problèmes sont encore valides (ex: problèmes avec ODE).
• NHibernate Performance Testing — SQLite et MySQL test de performance avec NHibernate.
• LibSecondLife performance problems - Autre vieille page de November 2007 détaillant les problèmes avec libsecondlife (maintenant appellé libopenmetaverse).
• Experiences from Operating a 3D Region Server in OSGrid - Part 1
• Experiences from Operating a 3D Region Server in OSGrid - Part 2