Performance/fr
From OpenSimulator
m (Robot: Cosmetic changes) |
m (Robot: Replacing 'OpenSim' to 'OpenSimulator', which is the precise name) |
||
| Line 3: | Line 3: | ||
= Introduction = | = Introduction = | ||
| − | Les performances de | + | 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... |
== Logiciel == | == Logiciel == | ||
| Line 26: | Line 26: | ||
DeleteScriptsOnStartup = false | 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 | + | 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 | + | 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==== | ====Définir AppDomainLoading = false==== | ||
| Line 56: | Line 56: | ||
!Description | !Description | ||
!Systeme d'exploitation (svp, ajoutez la version de Mono si approprié) | !Systeme d'exploitation (svp, ajoutez la version de Mono si approprié) | ||
| − | !version de | + | !version de OpenSimulator |
!RAM/AVG_USE_% | !RAM/AVG_USE_% | ||
!CPU | !CPU | ||
| Line 167: | Line 167: | ||
== Etudes de performances et articles de blogs == | == Etudes de performances et articles de blogs == | ||
| − | Ceux ci fournissent des données intéressantes sur les limitations de performance d' | + | 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 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 | + | * [https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html 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 http://www.sciencesim.com/wiki/doku.php/vwperf/start] - Liens vers les études de performances de ScienceSim en incluant certaines tres récentes. | * [http://www.sciencesim.com/wiki/doku.php/vwperf/start 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 | + | * [[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. | * [[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). | * [[LibSecondLife performance problems]] - Autre vieille page de November 2007 détaillant les problèmes avec libsecondlife (maintenant appellé libopenmetaverse). | ||
Revision as of 22:53, 3 March 2012
 |
Languages: |
|
Contents |
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...
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 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.
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 OpenSimulator | 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' 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
