Architecture pas optimisée

[Akira777]

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.

+1, je compatis. Je crois qu'on a tous (au taf) ce genre de truc qui traîne xD

[L'Omniscient]

Du coup niahoo, je me suis renseigné sur le long longpolling javascript jquery, mais du coup il faut un code qui va chercher une page php annexe toutes les secondes pour récupérer les valeurs issues de la BdD? Ca me paraît vachement lourd côté client, j'en ai d'ailleurs un pour mon tchat (sauf que c'est du load mais qui reload juste quelques lignes, mais comme c'est une boucle qui attend pas que le rechargement finisse, c'était peut-être le cumul de trop de requêtes qui faisaient ramer). Ou alors j'ai rien compris au longpolling(ce qui est possible). J'ai notamment trouvé deux exemples français, un qui actualisait toutes les 3 secondes, et l'autre qui actualisait au clic sur un bouton.

D'autre part, j'imagine que c'est difficile de faire à la milliseconde, mais si deux joueurs font une requêtes au même moment, ça se confronte comment ? :o

(Ok, ma deuxième question est débile, j'imagine que les requêtes ont un ordre et qu'il faut gérer cette éventualité. Par contre du coup, pour de nombreuses requêtes simultanées ça a pas l'air terrible. Websockets c'est plus rapide ? Parce qu'un joueur pourra faire presque une action toutes les trois secondes qui devra d'actualiser immédiatement pour les autres joueurs, interactions croisées)

[Xenos]

Nan, le long polling, c'est une seule requête lancée par le client que le serveur "fait trainer" le temps d'avoir une réponse (ce "fait trainer" pouvant être un while (true) qui teste si une nouvelle info est apparue en BDD, plutôt lourd coté serveur donc, ou un système d'évènement qui limite ces attentes actives).
"Pinger" toutes les secondes une page pour récupérer une info, c'est une approche différente, et un long-polling devient intéressant quand ce "ping toutes les secondes" renvoie "rien de neuf!" trop souvent.

Si deux joueurs différents font une requête, en PHP, cela sera traité en parallèle. Si la BDD est impliquée, alors la BDD traitera une requête après l'autre, dans l'ordre de chaque page mais en mélangeant peut-être les pages. C'est à dire que si la page fait plusieurs requêtes RA RB RC et qu'elle est demandée par J1 et J2, alors tu peux avoir RA1 RB1 RC1 RA2 RB2 RC2 (chance!) ou RA1 RA2 RB2 RB1 RC2 RC1. Si ces requêtes interfèrent, le mieux est donc d'encapsuler les requêtes de la page dans une transaction (cherches le net, tu trouveras à quoi cela sert).

Websocket sert juste à faire du "temps réel" (en fait, un tunnel client->serveur ET serveur->client à peu près temps réel, autant que le net sait le faire en fait), cela ne change en rien ce qui se passe coté BDD.

[L'Omniscient]

Et t'entends quoi par fait traîner ?
Tu crois que c'est adapté pour mon histoire du coup ? Si chaque joueur peut effectuer une action par 3 secondes, à partir de combien de joueurs simultanés environ ça risque de saturer? (Bon c'est toujours plus simple à mettre en place que du websocket.)

Edit: oh oui les transactions c'est parfait ^^ ça doit rendre un long pop long bien plus efficace

[L'Omniscient]

Pour être très précis sur le fonctionnement de mon jeu :
Un joueur utilisera sa puissance pour construire bâtiments et armée sur une carte divisée en 6 partie. Les armées pourront attaquer et se déplacer, et ces mouvements devront être retranscris aux autres joueurs en temps réel. (Le système d'armée et de combat que j'ai pour le moment imaginé ne me convient pas, ça ne me semble pas assez fluide, du coup je ne peux pas vous en dire plus, par contre les bâtiments, il y aura des jauges mentionnant le nombre de constructions max qui indiqueront le nombre de bâtiments construit, et des petites images qui changeront en fonction de quelle faction contrôle le lieu, ainsi que la liste de toutes les bâtiments construit par les différents joueurs)

[Ter Rowan]

perso comme plan d'action je dirais :

si tu veux en priorité faire un jeu

1) commence par faire de l'ajax
2) pose des transactions pour sécuriser si tu as vraiment peur des "effets simultanés"
3) test le jeu, sa performance, sa maniabilité, son interface
4) si quelque chose ne te satisfait pas, alors regarde comment l'améliorer

si tu veux en priorité apprendre le développement

1) laisse tomber l'idée de jeu dans un premier temps
2) fais plusieurs tests avec chaque techno pour bien les comprendre, les maitriser (ajax, chaussettes, long polling)
3) si après ca tu as envie de faire un jeu, alors fais le


tel que t es parti tu vas pas t'en sortir

[Xenos]

D'accord avec Ter Rowan, soit tu fais du contenu (un jeu) soit tu fait du meta-projet (t'apprends).

[L'Omniscient]

J'aime bien apprendre sur le tas, autrement j'arrive à rien. Et puis mon jeu a atteint sa première phase... Je vais pas m'arrêter comme ça ! Avant de passer à autre chose j'ai envie d'en faire une version agréable et pleinement jouable.

Ter Rowan, tu dissocie AJAX et long polling, mais les deux sont étroitement liés non ? Dans les exemples que j'ai vu, pour récupérer une donnée via long polling, ils passent toujours par l'AJAX il me semble. (dans le cas du JS / JQuery).

Les sockets en fait, de toute façon, je pense que je peux pas pour l'instant, ça demande trop de frais à cause du SSL (qui est essentiel pour la sécurité il me semble ?). Je vais essayer le long polling, et voir ce que je peux déjà faire avec ça ^^

Désolé de vous harceler comme ça de questions, je réunis le plus d'infos possible avant de me lancer (de toute façon j'ai les illustrations à faire avant de me lancer sur la deuxième phase de développement.

__________

Pour ce qui est de l'inventaire qui met trop de temps à s'actualiser, je ferai quelques tests et et prendrai des renseignements chez l'ami chez qui le temps d'attente a été particulièrement long. Parce que l'inventaire qui met du temps à s'actualiser après les explorations c'est pas top :/
D'ailleurs Ter Rowan, j'ai bien retenu le fait qu'il est possible que ce soit plus rapide en 1 fois plutôt qu'en 5, j'avais pas pensé à ça ^^ J'essaierai, même si je pense qu'en 4 secondes (le temps de collecter la ressource suivante), 1 requête a le temps de se faire. Actuellement, en privé ya 418B transférés, load 29 ms (donc ça x 5). En tout donc 2050B et load 145ms. Je sais pas bien à combien de temps ça correspond si on prend une connexion internet basique ? (j'ai pas la fibre, mais je croix que j'ai une connexion supérieure à la moyenne). D'ailleurs le TTFB (time to first bite) prends 10ms pour 1 requête (avec une seule page on aurait 10ms en tout au lieu de 50ms j'imagine, mais effectuée à la toute fin de l'exploration, donc augmentant le temps de chargement au moment du rechargement de l'inventaire). Sinon je force la mise en cache de Ajax.php au moment du chargement peut-être ? Comme ça le chargement de l'inventaire sera direct.

[Akira777]

Les sockets en fait, de toute façon, je pense que je peux pas pour l'instant, ça demande trop de frais à cause du SSL (qui est essentiel pour la sécurité il me semble ?). Je vais essayer le long polling, et voir ce que je peux déjà faire avec ça ^^

Pourquoi parler de SSL pour utiliser une socket ? J'ai pas compris pour le coup...

[Ter Rowan]

a mon sens y a trop de méconnaissances (c'est normal comme tu débutes) du coup tu te noies dans trop de choses commence par faire simple

et je dis ça sachant que j'ai jamais fait de long polling (par contre j'ai fait de l'ajax) et encore moins de web socket, je ne pense pas avoir le niveau et pas envie d'acquérir ces compétences aujourd'hui. Par contre je me sens quand même plus costaud que toi pour les questions, d'où mon conseil, faire simple, avoir des bases plus solides mais à scope plus réduit, et quand tu seras meilleur que moi (ce qui ne saurait tarder) , alors vois si tu as besoin de trucs plus sophistiqués