[PHP] gestion requetes concurrentes

[Myrina]

Pour être sur de la bonne mise à jour de la donnée critique, il faut:
- débuter la transaction
- locker l'enregistrement de la table
- sélectionner l'enregistrement de la table
- effectuer les traitements sur les données de l'enregistrement
- mettre à jour l'enregistrement en base de données
- commiter

Le lock au début est important surtout si les traitements sur les données peuvent prendre un peu de temps sinon, dans certains, les traitements du premier process peuvent disparaitre écrasés par les traitements du second qui se sera basé sur des données d'avant le traitement du premier process.

[Sephi-Chan]

Ou bien faire passer toutes les modifications par une queue.
Mais là, bonjour le goulot d'étranglement potentiel : à faire de manière intelligente.

[Xenos]

Pour le "30ms c'est rien", c'est relatif, car sur des jeux qui peuvent traiter une centaine de cases ou plus, ca devient important (s'il faut sauver des infos sur une centaine d'unités du jeu, si chaque sauvegarde prend 30 secondes, on atteint aisément les quelques secondes, ce qui peut non seulement ralentir le serveur, mais aussi rebuter les joueurs).
En revanche, d'accord avec Myrina, bien que je préfère généralement m'arranger pour ne pas avoir ce genre de problèmes (par exemple, en ne laissant qu'un seul script faire la simulation, et à ce moment là, utiliser MyISAM permet d'accélerer ce script qui donc, peut faire des trucs plus lourds, et être le seul à les faire)

[niahoo]

Clairement pour un jeu web ce qui va être lent c'est l'IO serveur/client et pas les accès à la base de données. Donc tout balancer dans une queue me semble un bon plan. Enfin, c'est du moins ce que je compte faire.

Mais comme j'utiliserai websockets et ajax si les réponses du serveur sont un peu lentes ça ne se sentira pas grâce à l'affichage « prédictif » (ça se dit ?).

Dans le cas d'un rechargement de page PHP à l'ancienne effectivement si tu as plein de requêtes ça peut être chiant.

De plus, une centaine d'unités peuvent être mises à jour en une seule requête.

Enfin, j'utilise prestashop qui est un bouzin qui balance 40 000 requêtes SQL par requête web, que je fais tourner en innoDB sur un serveur bien correct et ça va très vite !

[php_addict]

par défaut le niveau d'isolation des transaction est "Read committed" en innodb forcement

http://dev.mysql.com/doc/refman/5.1/en/s...ction.html
http://www.ovaistariq.net/597/understand...on-levels/
http://zetcode.com/databases/mysqltutori...nsactions/

tu mettre par defaut je sais plus comment en serializable mais tout devient hyper lent car ca lock tout et tout le temps

pour un maximum d'isolation:

Code :

$query   = " SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE ";

après et c'est là ou je me permet une question sur ce topic qui n'est pas le mien:

y a t il moyen de configurer apache pour qu'il ne soit pas multi-thread et d’exécuter les scripts les uns après les autres, cela résoudrait des problèmes non?

[niahoo]

heuuu je crois que ça ferait un serveur vraiment très très lent, déjà qu'apache c'est pas la panacée.

Il faut utiliser autre chose pour ça ... par exemple mochiweb ou cowboy avec un seul worker. Mais forcément c'est lent aussi.

Quelle idée ... si on veut faire du multijoueur il faut au contraire une architecture la plus concurrente possible. À vous de gérer votre code serveur et l'architecture de votre jeu pour permettre ça.

Pour les jeux un peu complexes, oubliez le PHP papa-maman au rechargement de page systématique.

[srm]

Tu fais un système de queue, tu es sur de pas avoir de soucis, tout en étant le plus simple à gérer
Et tu ne perds pas en rapidité si tu veux travailler plusieurs jobs sur ta queue.

[Sephi-Chan]

Le problème d'un système avec tout en queue, c'est que les requêtes Web qui conduisent à des changements sur la base (insertions ou modifications) ne peuvent pas fournir de réponse (seulement des promesses). Il faut utiliser du push pour envoyer les informations une fois qu'elles sont disponibles.

Ça altère donc beaucoup la façon d'écrire l'application. Et ça peut poser problème lorsqu'il s'agit de scale.

Néanmoins, je pense que c'est le moyen le plus simple, fiable et sûr, le meilleur en terme d'optimisation de la machine et le meilleur pour préserver la santé mentale des développeurs.

[Argorate]

Vous êtes partie sur le comportement de la bdd, ce qui n'est pas ma question de base.
Pour ma config, j'ai un mutualisé chez ovh, je ne sais pas vraiment ce qu'il y a derrière?

Mais du coup, de manière concrète, cela dépend de quoi?
Qu'es ce qui gère la concurrence et comment?
Vous dites que les deux cas sont possible, hors comme cela a été dit, si deux requête touche au même objet en même temps et le save en bd, l'un va écraser l'autre et ça peut tout pourrir, ou même sans parler de la bd, il se peux que les valeurs dans les objets qui seront utilisé dans des calcules ne soit pas les bons.

Du coup, comment gérer tout cela? qu'es ce qui nous permet d'avoir le contrôle?

[niahoo]

et ben lis tout ce qu'on a dit. les transactions te permettent d'avoir ce contrôle.