Performance/fr - Revision history

Acryline: /* Introduction */

2025-02-12T15:32:10Z

‎Introduction

Manni at 10:42, 4 December 2023

2023-12-04T10:42:26Z

Acryline: Translation update

2021-08-19T08:05:41Z

Translation update

Show changes

Acryline: /* Introduction */

2017-11-13T08:29:18Z

‎Introduction

Acryline: /* Introduction */

2017-11-13T08:28:12Z

‎Introduction

Acryline: /* Introduction */

2017-11-13T08:27:18Z

‎Introduction

Acryline: /* Disque */

2017-08-15T15:07:08Z

‎Disque

Acryline: /* Etudes de performances et articles de blogs */

2017-08-15T08:55:04Z

‎Etudes de performances et articles de blogs

Acryline: /* Etudes de performances et articles de blogs */

2017-08-15T08:53:38Z

‎Etudes de performances et articles de blogs

Acryline: /* Solutions possibles */

2017-08-15T08:46:38Z

‎Solutions possibles

@@ Line 7: / Line 7: @@
 Nous pouvons décomposer  les domaines d'influence sur  les performances  ainsi :
 # 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).
 # les problèmes liés au simulateur (par exemple, nombre d'objets dans la scène, nombre de textures, nombre de scripts)
 # 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).

← Older revision		Revision as of 10:42, 4 December 2023
Line 1:		Line 1:
−	{{~~Languages~~\|Performance}}	+	{{Quicklinks\|Performance}}

	= Introduction =		= Introduction =

@@ Line 14: / Line 14: @@
 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).
+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.

@@ Line 5: / Line 5: @@
 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 la les performances performances ainsi :
+Nous pouvons décomposer  les domaines d'influence sur  les performances  ainsi :
 # 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).

@@ Line 3: / Line 3: @@
 = 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...
+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 la les performances performances ainsi :

@@ Line 97: / Line 97: @@
 ===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 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.

← Older revision		Revision as of 08:55, 15 August 2017
Line 437:		Line 437:

	-->		-->
		+	[[Category:French Translations]]

@@ Line 373: / Line 373: @@
 Ceux ci fournissent des données intéressantes sur les limitations de performance d' OpenSimulator à différents moments dans le temps.
+* [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. 2011
-* [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.
 * [[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).
 <!--

@@ Line 362: / Line 362: @@
 === 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.
+* 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 s'ils pointent vers la même base de données. Comme le serveur web en C# intégré est lent et probabement pas tres conflictuel, cela peut améliorer considérablement les performances 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.
+* Instancier des copies supplémentaires de ROBUST copiant les services qui causent des probmèmes comme l'inventaire. Parce 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 insuffisant, 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.