Latest revision as of 02:42, 4 December 2023

 

Home

 

Download

 

News

 

Support

 

Admin

 

Dev

 

Screen Shots

 

Grid List

 

Bugs

Languages:

English    Deutsch    Français

[edit] Introduction

Les performances de OpenSimulator sont un problème trés complexe. 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 les 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 provoquer 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).

[edit] 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).

[edit] 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.

[edit] 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);

[edit] MetricsCollectorTime

La classe MetricsCollectorTime peut vous être utile. Elle implémente une fenêtre mobile qui collecte les indicateurs de performance. Par exemple, elle est utilisée pour calculer le temps d'exécution total au cours des 30 dernières secondes pour chaque script. Par exemple, instanciez-la comme suit :

MetricsCollectorTime executionTime = new MetricsCollectorTime(30000, 10);

Cela crée une fenêtre mobile qui couvre 30 secondes (30000 ms), et a 10 "buckets". Ces derniers déterminent la granularité de la fenêtre : dans ce cas, c'est 30/10 = 3 secondes.

Chaque fois que vous obtenez un échantillon de chronométrage, ajoutez-le au collecteur :

Stopwatch timer = new Stopwatch();
// Mesurer quelque chose avec 'timer'...
collector.AddSample(timer);

Chaque fois que vous voulez obtenir la valeur totale dans la fenêtre de collection, appelez :

int elapsedMS = collector.GetSumTime().TotalMilliseconds;

MetricsCollectorTime est en fait une sous-classe de la classe générique MetricsCollector. La classe générique peut utiliser n'importe quel type de données comme valeur d'échantillon. Elle utilise un tampon circulaire pour ses buckets, ce qui la rend très efficace.

[edit] 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/

[edit] Sujets liés à la performance du simulateur

[edit] 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 :

[edit] 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.

[edit] 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.

[edit] 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 suffire. 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.

[edit] 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.

[edit] 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.

[edit] 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.

[edit] Scripts

Voir Scripts Performance.

[edit] 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.

[edit] 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).

[edit] Définir AppDomainLoading = false

[XEngine]
AppDomainLoading = false

• Mettre cette option à true a un coût élevé sur la performance. Le croisement d'information entre les domaines d'application devient très lent, une opération de quelques microsecondes peut se transformer en une opération de plusieurs ms. Il est préférable de mettre cette option à false et de redémarrer la région périodiquement pour éviter les problèmes d'utilisation excessive de mémoire, car les scritps ne sont jamais supprimés de la mémoire.

Le moteur de script Yengine n'a pas cette option ou ces problèmes.

[edit] Augmenter MaxPoolThreads dans [Startup]

Actuellement, OpenSimulator utilise jusqu'à plusieurs types de threads pour ses opérations.

Premièrement, le threadpool principal par défaut de .net est utilisé par les méthodes du framework .net, comme IO etc, certaines méthodes d'OpenSimulator l'utilisent également, ou peuvent y être invitées.

Deuxièmement, un paquet de threadpool tiers appelé SmartThreadPool est utilisé. C'est le pool par défaut utilisé, et il est utilisé par plusieurs parties d'opensim (comme Xengine).

L'utilisation de ce pool permet la réutilisation des threads, épargnant ainsi beaucoup d'opérations très coûteuses de création et de destruction de threads.

SmartThreadPool a une option pour définir le nombre maximum de threads qu'il peut utiliser.

[Startup]
MaxPoolThreads = 300

Notez que chaque thread a un coût, à la fois en termes de ressources, mais aussi en termes de CPU pour la gestion. Le fait d'en autoriser trop dégradera les performances, au lieu de les améliorer. Le point d'inflexion dépend du nombre de cœurs de processeur, et du nombre d'applications qui en ont besoin sur la machine. Beaucoup de mauvaises utilisations de threads dans les versions précédentes d'opensim ont été corrigées, faisant une utilisation plus efficace de chaque thread. Actuellement, un grand nombre de threads est encore nécessaire pour gérer les opérations IO lentes (comme le réseau), ceci devra être amélioré.

[edit] Changer async_call_method dans [Startup]

Par défaut, il est configuré pour utiliser SmartThreadPool. Alternativement, vous pouvez changer cela pour utiliser le threadpool principal de .net ou même pour utiliser un nouveau thread.

Le pool de threads principal de .net s'est beaucoup amélioré, mais certains rapportent des situations où il induit lui-même la disparition des threads et cesse totalement de fonctionner.

Pour l'utiliser :

[Startup]
async_call_method = UnsafeQueueUserWorkItems

L'utilisation d'un nouveau thread n'est pas recommandée, car la création d'un thread est une opération coûteuse, d'où l'introduction des pools.

[Startup]
async_call_method = Thread

Notez que plusieurs composants d'opensim ont un usage codé en dur d'un type particulier de pool.

[edit] 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.

[edit] Base de données

[edit] Assets

[edit] Le problème

En raison de l'architecture distribuée de OpenSimulator, quand les régions exécutent depuis un certain nombre de machines au travers d'un réseau, il est extrèmement difficile d'identifier les assets qui ne sont pas utilisés et qui peuvent donc être supprimés. De plus, le nombre d'assets augmente continuellement 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 cela impliquerait une certaine durée de mise hors service. Pour des grilles autonomes, ou pour des environnements où les assets ne sont pas passés entre les grilles (c'est à dire : donner une texture à un ami sur une autre grille), Wizardry and Steamworks fournissent un script expérimental qui ferait exactement cela. Ce projet de nettoyage d'assets et publié sous licence MIT.

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.

[edit] Solutions possibles

• FSAssets est destiné aux grandes grilles pour lesquelles la taille de la base de données dépasse les 50 Go. Cette option va placer les assets dans un système de fichiers à l'opposé du service par défaut qui stocke tous les assets au format blob dans la base de données. Elle permet aussi de dédupliquer les assets. Chaque asset sera haché quand il arrive pour être stocké et si cet asset existe déjà, le service d'asset va le lier au fichier existant au lieu de stocker une deuxième copie.

• 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.

[edit] 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.

[edit] Services

[edit] 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.

[edit] Solutions possibles

• FSAssets est destiné aux grilles plus importantes où la taille de la base de données devrait dépasser 50 Go. Cette option permet d'enregistrer les ressources dans un système de fichiers, contrairement au service par défaut qui stocke les ressources sous forme de blobs dans la base de données. Cette option fournit également des capacités de déduplication, chaque ressource est hachée lorsqu'elle est reçue pour le stockage et si la ressource existe déjà, le service de ressources établira un lien vers le fichier existant plutôt que de stocker deux copies. AVERTISSEMENT : ceci utilise à la fois une base de données et des fichiers sur le système de fichiers. Vous devez sauvegarder les DEUX".

• Si vous gérez une grille pour vous-même ou si vous gérez une grille où vous ne donnez pas votre contenu, alors le nettoyeur d'assets de Wizardry et Steamworks peut être une bonne solution pour traquer les assets perdus et les supprimer automatiquement de la base de données. Il est basé sur le dumping des OAR et des IAR, comme pour la deuxième option de cette section, mais après les avoir dumpés, il effectue automatiquement la recherche pour vous et vous invite à supprimer plusieurs assets supportés. Le développement actuel vise à exporter automatiquement les OAR et les IAR depuis PHP afin que la procédure soit transparente.

• Sauvegarder chaque région dans un OAR et l'inventaire de chaque utilisateur dans un IAR. Nous pensons que cela équivaut à trouver tous les actifs référencés et peut être fait manuellement. Cependant, c'est très laborieux pour les installations avec un grand nombre d'utilisateurs et nécessite un temps d'arrêt du réseau. Des outils pourraient être écrits pour améliorer cela, notamment en sauvegardant systématiquement tous les inventaires des utilisateurs dans les IAR. À des fins de sauvegarde, assurez-vous qu'ils stockent bien les assets, en utilisant les options correctes.

• Ne rien faire. MySQL peut stocker une très grande quantité de données avant de rencontrer des problèmes - MySQL est utilisé pour des sites web et d'autres applications extrêmement volumineux après tout. Cela suppose que vous disposiez de l'espace disque nécessaire.

• Utilisez un service de ressources externe tel que [SRAS]. SRAS, en particulier, est un service de ressources tiers qui effectue la déduplication, la compression des ressources, et stocke les ressources sur le disque plutôt que dans une base de données. Il possède également des fonctionnalités intéressantes, comme empêcher les ressources d'être fournies sans les supprimer. Il est utilisé par OSGrid, par exemple. Cependant, son fonctionnement est différent de celui du service d'assets intégré d'OpenSimulator (par exemple, la sauvegarde des assets sur disque implique des étapes supplémentaires par rapport à la simple sauvegarde d'une base de données). Il nécessite également une étape de migration qui peut prendre un temps considérable si vous avez une collection d'assets existante. Notez que FSassets écrit en c# et inclus dans opensim ressemble beaucoup à SRAS.

[edit] 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 M. Blue. Les objets physiques et les avatars maximum sont limités par les performances d'un seul thread dans OpenSimulator.
• 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).

[edit] Conseils au sujet des performances

Voici quelques mesures spécifiques que vous pourriez prendre pour améliorer vos performances :

[edit] Exécuter Squid sur votre serveur de région en tant que reverse proxy du serveur d'assets

1. Télécharger et installer le Proxy Squid (CentOS/RHEL/Fedora: "dnf install squid", Debian: "apt install squid") 2. Créer votre fichier de configuration squid.conf.
3. Changer votre configuration de serveur d'assets dans votre OpenSim.ini pour pointer vers http://localhost:3128/
4. Démarrez le tout!

Maintenant les assets seront mis en cache dans le cache de squid sur le serveur de région, et seront servis beaucoup plus rapidement, spécialement au moment des redémarrages de région.