Choix dans la conception jeu en ligne par navigateur

[Akira777]

@fortz, l'idée de coder en local puis de pousser sur le dépôt distant n'est pas propre à tortoise, Git le gère très bien ! En passant, cet outil est génial si tu es sous Mac (http://www.gitboxapp.com/), en gratuit (Windows, OSX) tu as SourceTree (https://www.sourcetreeapp.com/).
Mais la ligne de commande reste indispensable à mes yeux ! Par exemple pour le remisage (git stash).

@xenos, je serai curieux de voir des exemples de code. Par contre contrairement à ce que tu dis, justement le but de l'ORM et donc "une classe php === une table" te rends justement totalement indépendant de ta sgbd, et c'est très bien ! Tu veux passer à du sqlite, aucun problème ! Tu veux faire du test unitaire, aucun problème ! Tu peux faire plein d'opération sur tes entities, une relation ou des tables et choisir quand commiter vers la bdd. Je trouve que ça apporte un confort de code non-négligeable !

[Xenos]

[Akira777]

@xenos, intéressant ! Je n'ai jamais travaillé de cette manière (qui me semble encore un peu exotique, mais ça ira mieux avec le temps) donc je me risquerai pas dans la comparaison mais tu as l'air d'avoir mis ça en place intelligemment donc pourquoi pas

Mais concrètement dans mon cas, je me préoccupes principalement des types de mes colonnes et de mes index (via ma classe Schéma) et je manipule tout ça en PHP via mon ORM (qui n'est qu'une DBAL un peu plus haut niveau et configurée pour un environnement SGBD en particulier...).
Pour le coup, je fais très peu de calcul complexe en SGBD, PHP le gère très bien dans ce cas de figure.

Ce qui est marrant, c'est que pour moi, je suis plus à même de changer de SGBD que de langage back-end (ce que tu appelles front-end, ce sera plus AngularJS pour moi). Le goulot d'étranglement se retrouve être plus souvent la BDD que mon language serveur...
D'ailleurs, en travaillant comme cela avec de la procédure stockée comment gère tu le scénario de la forte charge et la réplication par exemple ?

[Xenos]

Oui, c'est le "front/back" de la partie back Mais je ne sais pas trop comment le formuler...

Les problèmes de réplication ou de forte charge ne se posent pas encore, mais de ce que j'en sais, il est plus aisé d'ajouter des instances MySQL pour répartir la charge du SGBD que des "instances PHP" pour répartir la charge PHP. En tous cas, j'ai pu trouver de la doc pour "ajouter" des instances MySQL, mais je n'en ai pas trouvé pour faire facilement la même chose coté PHP (apparemment, il faudrait un load-balancer amont).

Sinon, ton goulot d'étranglement étant le SGBD, j'ai l'impression que tu es dans le même problème qu'à mon boulot (oui, je m'y réfère souvent, mais bon). A mon sens, ce goulot d'étranglement vient justement du fait que le SGBD est "sous-exploité", en servant juste des données et en passant à coté de certains traitements par lots qu'il saurait faire efficacement.
Pour reprendre l'exemple précédent, le cas type du "je récupère des objets, je les mets dans PHP, puis je complète ces objets avec d'autres objets que je construis là encore en les demandant au SQL" alourdit énormément les traitements (cf Techniques d'utilisation de WHERE IN pour MySQL) car il y a un trafic énorme entre les deux logiciels (PHP et MySQL).


Ayant pu comparer les deux méthodes (taff vs perso), je trouve la 2nde plus agréable, même si les deux fonctionnent

---

PS: un truc que je trouve pratique aussi avec cette archi, c'est que je peux changer la structure interne des tables sans devoir altérer les classes PHP (je ne sais pas si c'est faisable avec un ORM où la classe PHP "génère" les tables SQL). Par exemple, je ne peux pas utiliser extension MySQL Geometry (car OVH est en v5.5 et non 5.6). Du coup, en interne, mes coordonnées 2D sont sous la forme de 2 colonnes (x; y). Quand OVH passera en 5.6, je pourrai altérer la structure interne des tables pour utiliser 1 seule colonne, de type GEOMETRY. Je n'aurai alors que les procédures SQL à corriger (avec en plus, l'auto-complétion de l'IDE puisque ces fichiers sont des .sql purs), rien à toucher ou regénérer coté PHP.

---

PSS:
Quand j'aurai fait une release viable d'Eclerd (si je peux faire une telle release), j'essaierai de présenter cette technique et de la mettre bien en forme (façon blog-tuto-pas-à-pas).

[Akira777]

Juste pour revenir sur le point de la charge, justement, je n'ai jamais eu le cas où PHP est un goulot, mais justement l'inverse.
Quand j'ai des pics à 10-15 000 requêtes / secondes, ce n'est pas PHP qui bloque mais la base de données (ce qui paraît logique).

Exemple : je bosse dans le sport, quand tu fais de la stat live (match en temps réel, avec commentaire sur chaque action, ...) PHP n'a jamais posé problème. Le traitement n'est pas gros, c'est la masse de requête (INSERT, UPDATE) qui pose problème. Là ça se résout vachement bien avec une stack Redis qui se fallback sur MySQL.

Pour info dans ce cas précis :
- CDN pour les fichiers statiques
- Stack Redis pour les Sessions PHP
- Load Balancer <=> Stack Nginx / PHP 5.6
- Stack Redis en amont de la stack MySQL en réplication
C'est du caviar niveau performance / coût.
Ca va de quelques centimes / heures (par machine) en période basse, quelques euros / heures en période de charge.
Pour du 300k pages vues (40 000 utilisateurs connectés) par heure ça coûte quelque chose comme 4€ HT. Lissé au mois (avec 2 grosses périodes de pointe) on est dans le 90€ HT. (A noter que je mélange directement Site web + API Mobile)