+- 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 : Architecture pas optimisée (/showthread.php?tid=7617)
RE: Architecture pas optimisée - Ter Rowan - 07-04-2016
(07-04-2016, 09:58 AM)LOmniscient a écrit : Mais en fait niahoo, là on à quelque chose comme ça :
Seconde 1 : affichage - requête A 1s
Seconde 2 : affichage - requête B 1s
Seconde 3 : affichage - requête C 1s
Alors que tout sur une page ça ferait :
Seconde 1 : affichage
Seconde 2 : affichage
Seconde 3 : affichage requête A B C 2s
Seconde 4 : requête A B C 2s
En comptant 1 seconde en moins pour les 3 requête en 1 page parce que ça n'appelle la page des requête qu'une fois au lieu de trois.
Du coup, j'ai peur que ce soit plus long. Mais bon, j'essaie tout ça et je vous redis.
lorsque la croyance balaie les faits la peur entre en jeu.
RE: Architecture pas optimisée - Xenos - 07-04-2016
Citation : tester les temps de chargement pour prendre le plus rapide
Mauvaise approche (à mon sens), mieux vaut:
Make it work, make it right, make it fast
T'as un truc qui fonctionne, étape 1 réussie (c'est là où je suis d'accord d'ailleurs pour ajouter d'éventuels tests anti-régression). Maintenant, make it right: applique ce que niahoo a dit, car 3 requêtes lancées par le JS pour 1 seul clic, ça sent le purin. Surtout qu'il va se passer quoi si je modifie le code et que j'en lance 4, ou que je les lance dans le désordre, ou que j'en lance 2 sur les 3?
Après, tu t'occuperas d'un "make it fast" en benchmarkant N solutions propres pour n'en prendre que la meilleure (benchmarker N solutions dont des sales ne sert à rien: le temps machine est moins important que le temps développeur, surtout dans nos projets).
RE: Architecture pas optimisée - L'Omniscient - 07-04-2016
Bah non, 1 clic appelle 1 fois la page Ajax qui lance les 3 conditions pour les différentes requêtes SQL.
Mais il y a 5 explorations, 2 clics par explorations, dont le deuxième appelle une nouvelle requete AJAX qui lance les trois conditions.
Donc en gros, actuellement, 5 requêtes AJAX, chacune appellée tous les 2 clics.
Du coup ce que vous me proposez, c'est que plutôt qu'une requête AJAX tous les 2 clics, c'est 1 requête AJAX au 5eme clic, d'où le fait que j'ai peur que finalement ce soit plus long.
(Je n'avais pas du comprendre ce que vous aviez compris, mais 1 clic = 1 requête AJAX, pas plus. D'ailleurs ça sert à rien d'appeler plusieurs requêtes AJAX en 1 clic Oo sauf si on a des pages de traitement différentes)
Haha Ter Rowan, c'est juste que entièrement modifier un code qui fonctionne pour qu'il soit plus rapide, je préfère être sûr que ça peut être plus rapide. Là j'avoue que j'y crois pas trop.
RE: Architecture pas optimisée - Xenos - 07-04-2016
Y'a les outils de versionning qui permettent de se lancer dans des refactoring sans avoir les miquettes de tout détruire définitivement (perso, Mercurial, maintenant, je suis fan).
Ok, j'avais effectivement mal compris. Apparemment, tout est "préparé" avant que le joueur n'entame son exploration, donc, oui, on peut aussi avoir l'approche consistant à dire que l'exploration, c'est simplement des checkbox que le client coche pour savoir ce qu'il veut récupérer, et une seule requête en bout de course pour indiquer au serveur les choix du client. Mais ta propre solution me semble également convenir. C'est un peu plus lourd, inutilement, mais vu que le serveur est certainement sur-dimensionné (aka pas assez de trafic pour que la lourdeur du système soit un problème), inutile de passer du temps dessus pour le moment.
RE: Architecture pas optimisée - Ter Rowan - 08-04-2016
je pense qu'on avait tous mal compris l'histoire de clic / requete ajax (si je comprends bien c'est une requête ajax lance arrive à une page php qui lance plusieurs requêtes sql ?)
bah
entre
faire 5 fois :
select toto where id = "id"
et
faire une fois :
select toto where id in ("id1", "id2", "id3","id4", "id5")
ça m'étonnerait que le serveur mette plus de temps dans la deuxième solution (à mon sens il mettre juste 5 fois moins de temps mais bon)
Après tu dois peut être avoir une réflexion plus large : est il utile dans ton ergonomie de demander tous ces clics au joueur en si peu de temps ?
- Soit le joueur passe plus de temps sur une case et clique si besoin
- Soit le joueur crée son chemin, crée ses instructions (checkbox de Xenos - dans le concept hein, pas dans l'esthétique mais après c'est une histoire de goût) et clique une fois pour toute pour voir le résultat de ses choix
- Soit d'autres idées
- Soit rester tel quel pour des raisons qui n'apparaissent pas dans le message mais qui sont complètement valables
RE: Architecture pas optimisée - Xenos - 08-04-2016
(08-04-2016, 01:35 PM)Ter Rowan a écrit : entre faire 5 fois :
select toto where id = "id"
et faire une fois :
select toto where id in ("id1", "id2", "id3","id4", "id5")
ça m'étonnerait que le serveur mette plus de temps dans la deuxième solution (à mon sens il mettre juste 5 fois moins de temps mais bon)
Vrai à petite échelle, mais faux à grande échelle avec PHP+PDO (sur MySQL 5.5, cf courbe verte=WHERE IN préparé, bleue=boucle d'ids). A voir sur les autres SGBD. J'ai été très étonné de voir que la préparation d'une requête semble être en O(n²)...
Mais dans le cas de 5 ids, oui, un WHERE IN sera clairement plus véloce et recommandé.
(oui, les checkbox, c'est le concept, mais ça se style très bien, avec l'aide des <label>)
RE: Architecture pas optimisée - Ter Rowan - 08-04-2016
je n'avais pas cette notion de temps à grosse échelle, mais de toute façon j'avais des notions de limite oracle (sur le sgbd que j'avais vu pas plus de 1000 id dans le in) mais effectivement c'est intéressant
RE: Architecture pas optimisée - niahoo - 08-04-2016
A mon taf on transite beaucoup de données, du coup on fait des
WHERE id IN (<1000 ids>) OR id IN (<1000 ids>), etc ... Après sur 5 ID généralement je prends ce qui se code de façon la plus lisible
RE: Architecture pas optimisée - Akira777 - 08-04-2016
D'accord avec toi niahoo, pour quelques IDs le `WHERE id IN (<ids>)` est cool et lisible !
En revanche t'as pas vu une bonne différence de perf en faisant une `subquery`plutôt que de passer autant d'ID ? (Même si en général avec des index bien foutu, c'est pas lent...)
RE: Architecture pas optimisée - niahoo - 09-04-2016
houla c'est comme ça depuis 10 ans et le truc qui formate cette partie de la requête c'est pas une fonction c'est un p*tain d'include, donc moi j'y touche pas et pis voilà. Mais non ce n'est pas lent, on déploie pour des gens qui ont les moyens faut dire.
Mais une subquery c'est chaud car nous on reçoit les ID via requête HTTP. Quand il y en a vraiment trop et pour des requêtes complexes on les insère dans une table avec un token et on fait une jointure comme ça oui, mais en termes de perf ça ne change pas grand chose. J'ai pas trop fait de benchmark toute façon, c'est du code de merde et selon moi il faut le refaire.