[Question - Vb.Net] Les performances d'une application.

Bonjour/Bonsoir à tous,

Donc voilà quelque temps que je développe un serveur de jeu avec un amis. Une de mes fonctions et de développer la partie gestion des maps, des zones (Une partie du monde qui contient un certain nombre de maps (Ex: Donjon) ) ...

Ma vision des choses (Corrigez-moi si je me trompe) :

Récupérer les informations de la zone directement depuis la base de données (Maps, Monstres pouvant accéder à celle-ci ...). Puis appeler une fonction qui générerait le monde en générant les monstres, les vendeurs ... sur les maps disponibles

Ce qu'il faut savoir, c'est qu'une zone peut contenir de 30 à 3000 cartes et qu'il y a à peu près 40 zones. Le chargement est quand même assez lourd.

Donc ma question est :

Dois-je créer un nouveau thread pour chaque initialisation de zones et associer le thread à la zone concernée ou tout simplement générer toutes les zones depuis le thread principale ?

Le fait de créer énormément de thread n'est il pas "dangereux" pour les performances de l'application ou même de la machine ?

En espérant être clair :mouarf:

un serveur (physique) de nos jours a entre 8 et 32 cores
en utiliser un seul est une perte de performance

après le nombre de thread ne dit pas tout, sql server par exemple peut avoir des centaines de threads, et ca ne pose pas de problèmes
tout dépend de l'activité de ceux ci
si tu as 50 threads qui travaillent à 100% alors que tu n'as que 8 coeurs il y a une surement légère perte de performance, mais peut etre moindre par rapport au fait de travailler avec un seul thread ^^

sinon il y a le threadpool (et d'autres classes pour ca surement) qui permettent de gérer automatiquement le nombre de thread par rapport à la machine pour une série de tâches données
donc si tu as 3000 trucs à faire, tu les ajoutes, et la classe s'occupe de traiter x threads et de leur donner du travail (quand une des choses à faire est finie, une autre est commencée)

Salut,
mais tu génères tes maps sur ton serveur ? normalement le seul rôle du serveur c'est de gérer le positionnement des éléments et l'interaction entre ceux-ci, c'est au client de générer les maps et tout ce qui a attrait à l'affichage, la plupart des élément sont en plus codé en dure côté client (les pnj, les dongeons ...) seul les éléments mobile ont une utilité à être renvoyé par le serveur pour connaitre leur position actuel (les monstres, les joueurs ...).

Et bien déjà merci à tous pour vos réponses :)

Pol63 : C'est vrai que le principe est pas mal j'en avais déjà entendu parler mais sans plus :/
Les threads vont s'occuper de gérer les combats, les récoltes, les déplacements des monstres ... je sais pas si la manipulation de listes demande de grosses performances ?

YoutPout978 : Comme dis plus haut, pour moi, la génération des maps c'est placer les monstres sur celles-ci, s'occuper de les faire bouger et tout ça. Chaque modification est envoyée à tous les clients se trouvant sur la map en question.

Enjoy ! :)

Citation:

---

Envoyé par Tazman99

je sais pas si la manipulation de listes demande de grosses performances ?

---

non, en .net c'est l'affichage qui n'est pas génial
les traitements sont assez performants, tu peux gérer plein de liste avec des millions d'objets sans que ca se voit sur le processeur, enfin si c'est bien codé

au passage tu peux te renseigner sur les problèmes inhérents au multithreading, et comment les éviter (erreur de calcul par accès simultané, inter blocages, ...)

Merci Pol63 pour tes réponses claires, précises et rapides :)
J'aurais encore un petite question :aie:

Programmer le core de son application sous forme d'une dll et d'ensuite lancer celle-ci depuis une console ou encore un form est-il :
- Plus gourmand
- Exactement pareil
- Moins gourmand

en ressources que de développer directement son application sur une console (Form ...) ?

pourquoi cela aurait il une différence ?

Après il y a des astuces pour éviter de faire trop de traitement tu peux décider de traiter les mêmes infos pour des joueurs qui sont sur la même zone ce qui n'est pas illogique en somme, actualiser l'emplacement réel des monstres toutes les secondes ou demi-seconde.

Sinon je ne sais pas si tu mesures le temps de traitement de tes différentes fonctions mais ça pourrait être intéressant pour savoir d'où vient le goulet d'étranglement.

Pol63 : C'est un ami à moi qui m'a dit que le fait de tout "stocker" dans une dll était plus lourd :calim2:

YoutPout : "Après il y a des astuces pour éviter de faire trop de traitement tu peux décider de traiter les mêmes infos pour des joueurs qui sont sur la même zone". En effet, c'est déjà comme ça que je fonctionne :mouarf: Sauf que pour mon cas, on parle des joeurs qui sont sur la même map :zoubi:

"Sinon je ne sais pas si tu mesures le temps de traitement de tes différentes fonctions mais ça pourrait être intéressant pour savoir d'où vient le goulet d'étranglement." C'est vrai que je n'y avais pas pensé ... un simple timer fait l'affaire je suppose ..

Merci beaucoup en tout cas :oops:

Citation:

---

Envoyé par Tazman99

Pol63 : C'est un ami à moi qui m'a dit que le fait de tout "stocker" dans une dll était plus lourd :calim2:

---

faire trop de dll c'est lourd à gérer vu que ca fait plein de références
mais ca ne change en rien le temps d'exécution (enfin ca doit quand même faire un pouillème (= portion de micro seconde) au 1er chargement de la dll ^^)
et en faire un peu ca permet de délimiter des fonctionnalités
par exemple une dll de bas niveau de gestion de plein de petites choses (tcp, data ...) sera alors facilement dans d'autres projets sans amener de trucs qui n'ont rien à voir

Citation:

---

Envoyé par Tazman99

"Sinon je ne sais pas si tu mesures le temps de traitement de tes différentes fonctions mais ça pourrait être intéressant pour savoir d'où vient le goulet d'étranglement." C'est vrai que je n'y avais pas pensé ... un simple timer fait l'affaire je suppose ..

---

pour chronométrer le temps d'exécution entre 2 points : system.diagnostics.stopwatch