[PHP] gestion requetes concurrentes

[Argorate]

Bonjour,

je voudrais savoir si quelqu'un pourrait me dire comment est géré le fait que deux requêtes arrivent en même temps, où que l'une commence avant qu'une autre est fini tout en touchant au même objet par exemple?

Es-ce que chaque requête au serveur est placé dans une file d'attente interdisant donc les accès concurrent en exécutant dans l'ordre des demandes ou bien comment cela marche?

merci.

[niahoo]

c'est quoi ta config ?

[Sephi-Chan]

Ça dépend en partie de ton serveur Web et de sa configuration.
Par exemple si tu utilises Nginx + PHP FPM, Apache + mod_php, etc.

Dans l'ensemble c'est plutôt chaotique.

[php_addict]

Salut les gars

si vous avez des tutos ou des docs (LAMP) à ce sujet moi et Argorate sommes preneurs je penses

[Sephi-Chan]

Je ne connais pas de document de ce genre.

Par contre je sais vaguement comment fonctionnent les workers FastCGI (type PHP FPM).
Tu as la garantie que le worker traite une seule requête à la fois. Après, deux workers peuvent chacun traiter une requête dans le mêmes intervalle de temps, et donc potentiellement produite des accès concurrents à certaines données.

Je ne crois pas qu'un script puisse avoir conscience des autres requêtes et de leur ordre.

[niahoo]

Oui et tu peux avoir un script A qui commence avant un script B et qui finit après le script B.

Si tes deux scripts touchent au même objet en base de données et que tes updates ne sont pas des incréments tu flingues tes données facilement.

[Xenos]

Pas obligatoirement. Il me semble que MySQL (entre autres, ca doit surement être le cas des autres SGBD) possède une fonctionnalité permettant de verrouiller une table (ou une ligne d'un table?). Le principe est alors que si le script A verrouille la ligne, et que B essaie d'y accéder pendant ce temps, alors B récupère soit une exception, soit B est mis en attente jusqu'à ce que A déverrouille la ligne. Sur MyISAM, cela serait le principe à appliquer il me semble. Sur InnoDB, il est possible de créer des COMMIT, autrement dit, créer des "groupes" de commandes SQL. La propriété de ces groupes est que si une commande du groupe n'aboutit pas, alors tout le groupe est annulé (ca, c'est ce que j'ai compris), et on retrouve l'état que la BDD avait avant l'exécution de la première requète du groupe (donc, admetton que le commit ait un UPDATE et 3 INSERT, si le COMMIT plante au 2e INSERT, alors le UPDATE et le 1er INSERT seront annulés, comme s'ils n'avaient jamais été faits).
Il doit donc être possible de s'en servir dans ton cas de scripts conflictuels.

Il existe une dernière solution, un peu barbare, qui consisterait à créer une table à part, dans laquelle chaque script inscrit les verrouillages qu'il demande. Par exemple, le script A veut modifier l'objet d'Id N dans la table T, alors il vérifie d'abord que, dans la table de verrouillage, il n'y a pas l'objet N de la table T; et s'il n'y est pas, le script enregistre, dans la table de verrouillage, que l'objet N de la table T est verrouillé par le script. Une fois le script terminé, il supprime l'enregistrement de cet objet dans la table de verrouillage.
C'est lourd, mais c'est une solution.

Pour ma part, je pense que si tu as le risque d'un conflit entre deux scripts, alors tu dois probablement pouvoir repenser légèrement ton concept pour éviter ce problème. Ne connaissant pas le concept que tu as en tête, je me trompes peut-etre (ce n'est peut être pas possible de modifier ce concept, tout comme cela peut être possible).

(Arf, je devrais essayer d'être plus synthétique dans mes réponses >w>)

[niahoo]

Non non le sémaphore maison c'est pas une bonne idée. Mais tu as raison au début, il faut utiliser les transactions pour résoudre ce problème, ce que les ORM font (généralement)

[Xenos]

Ouais, donc "un peu barbare"... Disons plutôt "carrément dégueulasse", ca sera plus approprié.
Ah, m'étant demandé justement quelle différence il y avait entre InnoDB et MyISAM, j'ai voulu faire un test in-situ... InnoDB gère les transactions donc il sera utile pour les scripts "concurrents", mais attention: il est neeeettement plus lourd que MyISAM.

La différence est assez nette quand même, surtout niveau INSERT/UPDATE (normal, à cause des transactions entre autres): <100 µs (microsecondes) pour les MyISAM, et plutôt de l'ordre de 30ms (millisecondes) pour InnoDB, on est sur du x300 niveau temps d'exécution des requêtes (idem pour DELETE; SELECT s'en sort un peu mieux).

Donc je pense qu'il serait intéressant, si ton site vise pas mal de trafic, de revoir le concept, ca t'économisera beaucoup en terme de temps de calcul SQL.

[niahoo]

Oui surtout que ta table qui sert de sémaphore, elle peut aussi avoir des accès concurrents non gérés :p

Les transactions c'est plus simple.

Sinon pour innoDB franchement oui c'est « beaucoup » plus lourd mais 30 ms c'est que dalle. il ne faut pas sur-optimiser. Je préfère un code clair et concis qui prends 30 ms secondes de plus.