Moteur de jeu 2D
#21
Tu te poses trop de questions pour des problèmes de perfs minimes... Tu verras bien à l'usage ce qu'il se passera. Il ne faut pas avoir les miquettes d'un "mon jeu a trop de succès!" ce serait franchement dommage...!

Pour répondre aux points techniques (donc, pas ceux de quantification de perfs dont on se tamponne un peu tant et que tu verras plus tard):
• Je ne sais pas pour la mémoire... OVH laisse une marge sur les mutus, pour autoriser un dépassement temporaire en pointe de charge, mais s'il persiste, ils te lockent cette mémoire et t'invite à monter en gamme, tout simplement. 50€/an ou 3 mois de dev? A toi de voir ce qui te "coûte" le moins cher.
• Bof, AJAX ou pas AJAX, t'as exactement les mêmes performances, la seule différence se fait sentir au niveau de la quantité de données retournée (et encore, si Gzippée côté serveur, une page web HTML et un JSON n'ont pas une diff de ouf). Ton impression de vitesse vient probablement plus du fait que l'AJAX n'a pas à être parsé puis rendu par le navigateur
• Une requête UPDATE ou un SELECT simple sont kiff kiff niveau vitesse. Si t'as des différences, c'est que t'as peut-être foiré tes index SQL
• Plus il y a de joueurs... requêtes SQL. Oui, il manque un mot dans la suite logique. Donc je vais supposer: + de joueurs => + de requêtes HTTP => plus de requêtes SQL. Un SQL peut lire plusieurs lignes de tables en même temps, cela ne pose aucun soucis. Donc, les traitements de requêtes ne changeront pas des masses.
• MySQL traite les requêtes de sessions parallèle "au mieux", donc, autant que possible, en parallèle. Les requêtes deviennent séquentielles uniquement si l'une bloque l'autre (transaction non fermée ou verrou sur une ligne qu'une autre requête veut lire/écrire). Il faut pas s'arrêter aux perfs de MySQL: elles sont excellentes (bon, OK, Oracle lui fout probablement une branlée, mais le goulot d'étranglement n'est *pas* le serveur SQL lui-même, sauf si on l'utilise comme un cochon). Si t'as un bundle de 3-4 requêtes à faire et que tu trouves que des latences se font sentir, alors c'est probablement un soucis de connexion PHP-MySQL. Tu peux le résoudre par les connexions persistantes (mais elles ont des effets de bord) ou par des appels de procédure (qui réduisent les N requêtes à 1 seule). Donc, il suffit de bien savoir gérer ses transactions et la notion de verrou en lecture/écriture pour avoir 0 soucis de perf ('fin bon, évidemment, tu feras pas un Twitter avec un SQL privé de 256Mo de RAM hein... mais bon! 2 ).
• Hum, je ne sais pas pour ton "hit, miss, not, pass": où les as-tu vus (je dirai au niveau d'une page de stats de cache SQL peut-être)?
• Le temps de latence peu venir des deux réseaux: entre ta machine et le serveur (ordre de grandeur: 100ms à 1s) et entre le PHP et le MySQL (ordre de grandeur chez OVH: 1ms, ordre maxi: 5-10ms)
Répondre
#22
Citation :Et est-ce que, plus y a de joueurs, plus les traitements de requêtes sont longs ? J'ai cru comprendre que SQL faisait une pile et traitait les requêtes dans l'ordre alors que Node.JS traitait les requêtes en même temps. (Ca pour le coup j'espère que ça ralentira pas trop, je me rends pas compte en terme de chiffres).

Ça serait plutôt exactement l'inverse, js est monothread (ne pas confondre avec asynchrone) et traite donc les instructions les une à la suite des autres (apache/mysql peuvent être au contraire multithread si configuré pour, en fait node.js peut aussi être configuré pour du multithread). Mais ne te focalise pas trop dessus, un monothread bien géré peut largement être aussi/plus performant que du multithread.

De manière générale ne te soucie pas trop de la montée en charge maintenant, car en fait tu devrait espérer et non redouter qu'elle se produise un jour. Ceci dit c'est fréquent lors du premier projet de se faire peur à anticiper une réussite imprévue. Malheureusement on déchante le plus souvent (carte trop grande car pas assez de joueurs ect...).

Par contre effectuer plusieurs requêtes à la seconde, je pense que ça peut devenir problématique un jour (a mettre en relation avec les messages précédent sur le choix techno pour du temps réel).
Répondre
#23
(Tout d'accord, mais je souhaite juste rebondir sur "plusieurs requêtes à la seconde": m'est avis que tu peux de toute façon les regrouper en une seule requête HTTP, qui fera éventuellement les 3 actions nécessaires côté serveur, et tu tripleras tes perfs [en gros] donc pas de "peur" d'avoir choisi la mauvaise techno pour le moment: t'as de la marge)
Répondre
#24
Non mais quand j'ai peur niveau perf, c'est pas pour 100 joueurs hein, c'est rien que 20 joueurs simultanées, parce que ça me paraissait beaucoup 10% de mémoire à 2 joueurs. Et puis bon, un jeu à plus de 300 joueurs a eu un peu moins de 200 joueurs en simultané. Du coup plus de 50% ! Ca voudrait dire qu'à 40 membres inscrits il est possible que yait 20 joueurs en même temps, c'est pas grand chose 40 joueurs inscrits (notamment en comparant aux forums RP, sachant que le forum RP rebute il me semble beaucoup plus que le jeu web).

Et mon jeu a une carte vraiment petite : 30 zones à batailler, sachant qu'un joueur impacte assez faiblement les conquêtes (si c'est trop lent parce que ya trop peu de joueurs, je peux réduire les coûts pour les contrôles du territoire, ce sera même beaucoup plus agréable à jouer, mais bon faut pas non plus que ça soit trop rapide). Mais bon je n'ai pas fais du tout un jeu trop grand, 20/30 joueurs reste quand même un minimum pour que ça tourne bien je pense. Et puis les améliorations que je vais apporter amélioreront autant la partie solo du jeu que la partie en groupe. Et puis peu importe que le jeu ait du succès ou nom, il sera en ligne, tournera, je l'améliorerai, à côté je referai bien mon forum RP que je ferai tourner aussi avec pas mal de pub pour les deux, et je finirai l'édition de mon livre etc, l'idée c'est d'avoir un site solide et utilise qui réunisse mes différents projets CLEAN, pros, utilisables etc. Après, j'espère que ça va marcher 1 Si ça peut me rapporter un peu de sous par la suite ce serait le rêve ~_~

De toute façon je pense clairement qu'on peut faire un succès de tout, si on sait comment s'y prendre. Ce qui n'est pas vraiment mon cas hein 1 Mais je potasse je potasse. T'as des pros de la com qui te montre comment faire un site daub et avoir un trafic de fou dessus hein. Faut juste 1. réussir à avoir de la visibilité (max référencement) 2. réussir à inciter le visiteur à passer à l'acte (communication béton pour dire inscris toi) 3. fidéliser les visiteurs (contenu qui dure)
Mais bon, dans tous les cas, l'idée est que mon site soit un petit havre de dépaysement pour qui veut, à travers les différents éléments. Et puis mon jeu franchement, j'ai toujours voulu en faire un, je suis super heureux, et j'en suis content, et je pense que les améliorations qui vont venir vont être trop bien j'ai hâte 1 (La seule peur que j'ai c'est de m'être foiré niveau technique et que le projet s'écroule parce que techniquement ça tient pas la route. Mais bon, j'imagine que ya toujours moyen de reprendre en main les choses et les adapter pour surpasser même un gros problème technique).

Et puis bon, vous inquiétez pas, j'ai fais des forums RP pendant 10 ans, avec plus ou moins de succès, j'ai eu max 50 joueurs actifs sur un forum, et j'ai monté une association d'art dans une petite impasse paumé en banlieue parisienne avec assez peu de transports à côté, on arrive maintenant à avoir 60 visiteurs par mois (physiques hein) (c'est clairement pas assez hein, on travaille pour augmenter ça), mais je sais ce que c'est la difficulté de se faire connaître 34 Ce qui est sûr, c'est que la persévérance et la remise en question, ça paie petit à petit 1
Répondre
#25
Démarre ton PC, regarde ton gestionnaire de tâches: tu verras que même sans rien faire tourner, t'as 30% de RAM bouffée par l'OS. Avoir 10% de RAM occupée quand t'as 2 joueurs ne présage en rien de ce qui sera bouffé par 20. Comme dit: ce n'est pas forcément linéaire (peut-être affine, ou peut-être en racine carrée, ou peut-être en exponentielle, mais là, ça sera plus chiant 2 )

Commence par atteindre 300 joueurs actifs (et pas juste les 2 premiers jours parce que les gens d'ici se sont inscrits pour essayer), et on verra après 16

Passe plutôt ton temps sur ces réflexion d'équilibrage du gameplay, ce sera plus utile (et intéressant à mon avis). Car 20 joueurs actifs en permanence, tant mieux si t'y arrives, mais c'est déjà énorme à terme...

Mais faire du trafic, ça te serviras à quoi, hein?! 2 Pose-toi cette question aussi, car les commerciaux ne font ce genre de chose que pour ramasser du pognon. Et comme ils ont pris le parti de (tartiner) mettre de la pub, il leur faut du traffic pour faire du pognon. Suivant ton modèle économique, t'auras peu-être un objectif différent. Et sans modèle économique, t'en auras un autre 16 T'es donc pas obligé de t'engager sur cette même veine, surtout que perso, je pense que c'est une approche qui bouffe du pognon que tu n'auras pas à injecter.

D'expérience (= de ce que je vois ici, au pif, mais faudrait des stats pour être objectif), ce n'est jamais la technique qui plante les projets de jeux. C'est:
• L'absence de suivi (on release et rien après)
• La sur-gonflette du cahier des charges (on veut faire un truc de ouf, et rien ne paraît, ou juste une ébauche minable qui déçoit face aux annonces)
• L'absence de temps (le projet s'arrête un jour sans info, et parfois le mec revient dire "bah, j'ai laissé tombé")
• La qualité trop faible (c'est moche/pas ergonomique/pas jouable/pas graphique/pas attachant etc)
• Le copier/coller (les mamafia et autres jeux-clones d'un truc existant, qui n'intéresse pas franchement)
Je n'ai *jamais* vu un projet ici se planter parce que l'hébergement ne "suivait" pas.
Répondre




Utilisateur(s) parcourant ce sujet : 1 visiteur(s)