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 une discussion sur les performances avec les problemes de simulateurs (ex : performances de scripts, performances de base de donnees de région) et les problèmes de grille (principalement le dimensionnement de services comme les assets, l'inventaire, etc... pour servir plus de simulateurs et utilisateurs).

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.

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.

Simulateur

Besoins matériels

Malheureusement, c'est une question tres difficile à la lumière de tous les facteurs mentionnés dans l'introduction.

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

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.

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

Malheureusement, les outils pour migrer les données de OpenSimulator depuis SQLite vers MySQL sont actuellement limités. La migration est aussi possible en sauvant des OAR/IAR de vos données depuis sqlite et les charger ensuite une fois que vous avez reconfiguré pour utiliser MySQL.

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.

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