05-10-2012, 03:00 PM
(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).
