Performance/fr

From OpenSimulator

Revision as of 14:57, 17 February 2012 by Ssm2017 (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

Introduction

Les performances de OpenSim 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...

Logiciel

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 OpenSim sur place (par exemple, si vous mettez fréquemment à jour votre installation de OpenSim 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 OpenSim à 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.

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

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.

Description Systeme d'exploitation (svp, ajoutez la version de Mono si approprié) version de OpenSim RAM/AVG_USE_% CPU #/type de regions # avs simultanés #scripts/timers/Capteurs Emplacement #Elements d'objets
Xen VPS hébergé Ubuntu Intrepid (8.10) Inconnu 540MB/? 1x quad-core 2.5GHz Xeon (L5420) 1 region + 9 voids généralement 1-2 few Knifejaw Atoll & surrounding on OSGrid ?
Xen VPS hébergé Ubuntu Jaunty (9.04) Inconnu 360MB/? 2x dual-core 2.0GHz Xeon (5130) 1 void généralement 1-2 aucun Knifejaw Road on OSGrid ?
Serveur dédié de A+ Windows Server 2003 Inconnu 1 Meg 1x single-core 2.8GHz Celeron 2regions per server 6 at once with no issues Waterfalls, texture anims, window texture switchers, lots of sound loops Pleasure Planet Welcome center & Region Pleasure Planet in OSGrid 20000 prims per region
Amazon EC2 "high-CPU medium instance" (Xen VM) Windows Server 2003 Inconnu 1.7GB 1x dual-core 2.3GHz (Intel E5345) 1 region with sailing race course 7 avs, 4 in boats scripted start line Castle Rock, OSGrid
Serveur dédié de simhost.com SuSe 11.2 x64 Inconnu 8gb / 50% 4x Core2Quad Q9300 2.6ghz 1 region (Wright Plaza) utilise approximativement 4gb ram 20-25 utilisateurs Magasin de freebies / Centre de conférences / Cinéma @osgrid.org Simulateur tres utilisé 17500 prims aprox 1500 scripts
Machine à la maison Windows XP SP3 0.7.0.1 (Diva r13558) 3GB / 15-40% incl. Opensim and MySQL 4x Core2Quad Q6600 2.4 GHz. Utilisation: generalement, 0-10% 11 regions 1-6 utilisateurs Beaucoup d'objets scriptés (1934 scripts) Condensation Land 38,065 prims
Machine à la maison Ubuntu Lucid 10.04 (32 bit pae) 0.7.0.1 (Diva r13558) 160Mb no users, add 5Mb/user incl Opensim and MySQL I7-920 (dual threaded quad core), 3.8Ghz, 6Gb RAM, 0-10% de charge 4 regions (Config par défaut de Diva) 1-4 utilisateurs (approx 20Kb/sec bande passante/utilisateur) Peu d'objets scriptés (<10) Mars Simulation- Based on Erik Nauman's Open Blackboard 158 prims
Hosted Parallels Virtuozzo 4.5 Win/Net (32 run) 0.7.0.2 (D2) 420Mb total, incl OS, Opensim and MySQL i7 Quad 950 (Bloomfield) 3.07GHz, 8 Core, 2Gb RAM, 0-2% Avg Load 16 regions (4x4 mega-region) <6 utilisateurs ojets scriptés de véhicules (<5) Metaverse Sailing <1000 prims
VPS Debian Lenny 5 (mono 2.4.2.3) OSgrid 0.7.1 (Dev) cd4d7a7: 2010-10-15 655MB average out of 1722MB RAM, incl. MySQL Intel Quadcore 2.5 Ghz (1 core assigné au vps) utilisation moyenne: 40-45% 20 regions <4 utilisateurs environs 20 scripts différents d'éclairage, mais nous expérimentons aussi avec des scripts HUD plus lourds (timers, beaucoup de ll(Get/Set)PrimitiveParams et de grosses listes) et un relai IRC perso Phoenix Rising Isles on OsGrid 3727 prims

Etudes de performances et articles de blogs

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


Personal tools
General
About This Wiki