+- 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 : [PHP] gestion requetes concurrentes (/showthread.php?tid=6426)
RE: [PHP] gestion requetes concurrentes - Sephi-Chan - 05-10-2012
(05-10-2012, 02:11 PM)Argorate a écrit : 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?
C'est bien le problème du mutualisé : on ne sait pas trop de quoi est composée la stack Web.
De manière concrète, l'ordre de traitement des requêtes ne peut pas être garanti : c'est le chaos.
Apache peut être réglé selon deux modes : forking ou threading.
- Avec le forking, chaque connexion HTTP est gérée dans un processus séparé. C'est assez lent et coûteux en RAM.
- Avec le threading, chaque connexion est géré par un thread crée au sein d'un processus. C'est un peu plus efficace.
L'autre façon de faire repose sur FastCGI. On a un serveur Web (Apache, Nginx, etc.) qui route les requêtes entrantes vers des processus (les workers) prêts à l'emploi et qui traitent la partie dynamique des requêtes (les scripts PHP, dans le cas de workers PHP FPM). Ce modèle est le plus efficace (en terme de performance et de consommation mémoire) mais semble moins adapté pour un hébergement mutalisé. Il a en plus des déclinaisons assez à la mode en ce moment, comme modèle evented.
(05-10-2012, 02:11 PM)Argorate a écrit : 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?
Tu ne peux pas contrôler l'ordre d'arrivée des requêtes, ni l'ordre de traitement des requêtes arrivées.
Dans le cas où tu utilises une base de données, deux processus différents peuvent effectuer des opérations contradictoires (pour ton application, pas pour la base de données). En revanche, il n'y aura pas d'effet de bord au niveau de tes objets (sauf ceux qui réflètent la base de données, bien sûr).
La clé, c'est justement d'utiliser un composant qui garantiera l'exécution d'opérations dans l'ordre : une queue. Là aussi, il pourrait toujours y avoir des effets de bords sur ta base de données (mais pas les objets ) si les différents workers qui dépilent la queue interviennent simultannément sur une même ligne de la base. Mais ce risque peut être anticipé et mitigé en évitant que deux opérations potentiellement concurrentes soient traitées par des workers qui travaillent en parallèle (c'est là qu'un goulot d'étrangelement peut se former).
RE: [PHP] gestion requetes concurrentes - Ter Rowan - 06-10-2012
Je vais peut être dire des conneries, mais en passant par un mem cache like, on réduit pas le nombre de cas d acces concurrent ( dans le sens ou les traitements sont plus rapides donc moins de chance de se croiser)
On aurait alors
Memcache like pour les acces ultra fréquent et écriture
Myisam pour les acces lecture ultra frequent et peu d update
Innodb (et transaction) pour les acces écritures fréquents ou sensibles
RE: [PHP] gestion requetes concurrentes - Sephi-Chan - 06-10-2012
Je pense que ce sera encore pire car au delà de la vitesse des accès, certaines systèmes de stockage sont conçus pour ça (via les transactions, les locks, etc.). Memcache n'a rien de tout ça.
Le problème des données corrompues n'est pas un problème de la base de données, seulement de l'application.
Les bases de données gèrent très bien les accès concurrents, ce qui pose problème, c'est quand votre application dit 2 choses contradictoire dans un intervalle de temps court.
