+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Vitesse d'un RPG AJAX : la faute au serveur ? (/showthread.php?tid=5268)
Vitesse d'un RPG AJAX : la faute au serveur ? - Cawrotte - 19-02-2011
Bonjour à tous,
je suis sur le développement d'un RPG/Gestion multijoueur et il fonctionne en AJAX comme la majorité des RPG en ligne.
Seulement voilà : je me pose des questions sur l'origine de l'intervalle de temps entre le moment ou l'on clique pour se déplacer et le déplacement même.
Il fonctionne de la manière suivante :
Click pour se déplacer -> AJAX vers une autre page qui UPDATE la BDD -> Rafraichissement de la zone de jeu.
Des fois ca va super vite, des fois l'intervalle dépasse 2 secondes : c'est le seuil de l'injouabilité.
Mais d'où vient ce ralentissement ?
Du serveur perso ?
Devrais-je voir une différence si je prends une offre mutu' plus chère ?
Merci d'avance !
:heuuu:
RE: Vitesse d'un RPG AJAX : la faute au serveur ? - Horace - 19-02-2011
Je suggère quelques pistes :
- poids total des nouvelles images transmises trop lourd ?
- Différences de temps liées à la mise en cache côté serveur (PHP, MySQL, HTML) <-- j'y pige rien
- loguer (ou transmettre ajax) le temps de génération php des pages
- vérifier la durée des requêtes SQL (dans phpMyAdmin) ; peut-être la requête SQL ou la BdD n'est pas optimisée
- Extensions Firefox pour webmaster permettant de déterminer les temps de transmission des images/scripts/etc d'une page.
- Tester avec d'autres hébergeurs : puissance du serveur (waiting), bande-passante serveur ou client (sauf si ton serveur en local)
- problème côté client (RAM insuffisante) : tester sur autre navigateur, autre ordi
Voir aussi ancien post Combien de temps maximum doit prendre la page à charger ?
Bon courage !
RE: Vitesse d'un RPG AJAX : la faute au serveur ? - Sephi-Chan - 19-02-2011
Je pense que la technologie n'est pas adaptée. Ajax pour recharger un plateau où d'autres bougent, c'est contreproductif.
Le push me semble bien plus pertinent, d'autant que c'est très accessible, même gratuitement, même sur du mutualisé. Cf. BeaconPush, PubNub.
Sephi-Chan
RE: Vitesse d'un RPG AJAX : la faute au serveur ? - Cawrotte - 19-02-2011
Merci beaucoup !
Mais tôt ce matin, ca allait très très vite et dès 9 ou 10 heures c'est passé d'une intervalle d'environ 0.5 seconde à 2 secondes !
Ca doit sûrement venir du serveur non ?
Regarde ca par exemple :
http://img210.imageshack.us/img210/2191/chromeo.png
Que signifie Waiting ? C'est bien le temps qu'a mis le serveur ?
Le serveur SQL ?
Je suis un peu perdu ^^
@SephiChan
J'ai essayé beaconpush, c'est effroyablement instable et ca ne fonctionne pas partout.
Des fois ca fonctionne d'autre fois il faut actualiser...
Ajax c'est simple et fiable !
Ca marche à tous les coups !
C'est peut-être un peu lent mais justement je cherche une technique pour réduire le labs de temps.
Le push... vraiment c'est pas mon truc.
Nombre de MMORPG fonctionnent très bien en AJAX...
Mais le MMORPG est fait en case-par-case, pas avec un arrière plan.
C'est un des principes du jeu : chacun modifie sa map... C'est assez gourmand : une centaine d'images à recharger à chaque fois.
Je pense donc que ca vient du serveur. Un mutu plus puissant serait-il une solution ?
RE: Vitesse d'un RPG AJAX : la faute au serveur ? - Ieyasu - 19-02-2011
Sur mutualisé, la charge de ton serveur dépend des visites sur les sites d'autres personnes.
Sur les heures de pointes des visites hébergés sur le même serveur que toi, tu perd en performances.
Il n'y a qu'à voir, upload un gros fichier via ton ftp et charge une image sur ton navigateur en même temps, tu constateras un ralentissement flagrant.
Concernant ton utilisation d'Ajax, je pense que tu n'as peut être pas optimisé la chose, alors si j'ai bien compris tu fais :
Requête Ajax pour enregistrer l'action utilisateur sur la bdd, puis reload de la page pour afficher cette modification.
Dans ce raisonnement, tu recharge ta page, ajax ne te permet que d'envoyer l'upload de la base, ce qui n'est pas la fonction de ce système de requête.
Ajax permet de naviguer en envoyant des requêtes asynchrones, permettant de ne pas rafraichir la page mais seulement les informations nécessaires.
Tu devrais donc après upload via ta requête Ajax recevoir un message en retour du script exécuté, message qui te permet de mettre ta page à jour via Javascript.
Si tu optimises tes transferts d'information, par exemple en envoyant en retour un Json contenant tous les objets modifiés tu ne pollue pas la bade passante, et surtout tu e rafraichis pas inutilement ta page (pas de reload des images, de la structure du site...).
Si tu cherche encore à réduire la charge de ton jeu, tourne toi vers la compression de tes pages. Le protocole HTTP permet une compression zip, qui te permettra d'économiser encore un poil de BP.
Garde à l'esprit qu'Ajax n'est pas adapté pour des requêtes très rapprochés. Le protocole HTTP est assez lent, u rafraichissement des informations toutes les 20 /30 secondes sur du mutu est une bonne alternative, à ajuster en fonction de la fréquentation et de la charge de ton serveur.
Le jeu par navigateur avec les outils actuel ne peut pas bénéficier d'un rafraichissement assez performant pour le temps réel.
Tu seras toujours asservis à un "ping" de quelques secondes au mieux.
RE: Vitesse d'un RPG AJAX : la faute au serveur ? - Cawrotte - 19-02-2011
D'accord.
Donc si je garde mon système ce sera toujours aussi lent quelque soit le mutu' ?
D'autant plus que la page à rafraichir comporte 170 images de 30*30 px...
[b]Pour essayer le jeu si vous voulez mieux le comprendre : MP moi
RE: Vitesse d'un RPG AJAX : la faute au serveur ? - Ieyasu - 19-02-2011
Si tu lance un chargement de page après chaque modification, il y a des chances.
Après, au petit bonheur la chance, tu peux tomber sur un serveur contenant des sites très peu visités, mais c'est un gros coup de poker, disons que ton système actuel n'est pas adapté à un rafraichissement fréquent.
Renseigne toi sur le fonctionnement d'Ajax et le principe de rafraichissement asynchrone de tes pages, en gros :
Tu lance l'exécution d'un script de manière asynchrone coté client, admettons un update bdd.
Cette requête de renvois une réponse : Admettons de manière très synthétique un boolean, et un message d'"erreur".
Si la requête te renvois TRUE le moteur js coté client affiche les modifications adéquats (le déplacement en l'occurrence), si tu reçois false tu interprète le message d'erreur.
De cette façon, tu ne fait quasiment rien transiter sur ta bande passante.
Tu peux rajouter d'autres infos sur le retour du script, comme un Json contenant par exemple les ID des objets ayant bougés depuis la dernière requête et leurs nouvelles coordonnées. (ou un xml... que tu n'auras qu'à parser avec ton moteur JS)
Favorise le développement d'un moteur javascript riche coté client, cela allègera d'autant le travail coté serveur.
mais ce n'est que mo humble avis
RE: Vitesse d'un RPG AJAX : la faute au serveur ? - Cawrotte - 19-02-2011
Mais ca doit être très compliqué de coder ca !
Je ne vois pas du tout comment mettre ca en oeuvre
RE: Vitesse d'un RPG AJAX : la faute au serveur ? - Ieyasu - 19-02-2011
Pas vraiment, mais ca demande pas mal d'organisation de tes données.
Après, peut-être que quelqu'un aurait une autre idée pour t'aider je ne sais pas :S
RE: Vitesse d'un RPG AJAX : la faute au serveur ? - Sephi-Chan - 19-02-2011
Je viens d'aller tester ton jeu : il génère beaucoup trop de traffic.
Presque 1 requête par seconde. Pourquoi ? La plupart du temps, pour rien puisque rien ne change : je n'avais pas bougé et personne n'a parlé sur le chat. Au secours le gâchis, quoi !?
C'est ta conception qui est à revoir : ton jeu ne tiendra absolument pas la charge à ce train.
Ce que tu aimes ou n'aimes pas n'entre pas en ligne de compte si tu te soucie de la qualité de ton jeu.
Ajax, c'est bien, mais c'est pas adapté à ton cas.
Je vais essayer de faire une démonstration d'une version plus économe.
Sephi-Chan