Discussion :

[sajreborn]

Bonjour,

j'ai recemment demandé comment executer plusieurs requetes en paralleles de maniere instantannées et Grace a Matthieu et Seb j'ai eu pas mal de réponses qui m'ont permis de le faire.
Maintenant j'ai un nouveau soucis et le plus majeur.

Je pose le contexte: j'ai un serveur en local, php mysql, et j'utilise beaucoup de l'Ajax pour accéder à mes service PHP. tout se passe bien.
Probleme: Quand je lance par rexemple trois requetes Ajax en meme temps, grace a la fonction session_write_close, les requetes se lance presque instantannement tous en meme temps. Cela est cool deja. Maintenant la reponse est sequentielle, par exemple la premiere requete accede a une grosse table dans mysql pour renvoyer les données, tandis que la troisieme requete accede a une table de parametre avec juste 3 ou quatre lignes. Hé bien la troisieme requete doit attendre que la premiere et la seconde soient terminée avant de retourner la réponse. Et cela malgré que toute les trois se lancent presque instantannement grace a session_write_close.

J'ajoute que les deux premieres requetes se lancent a des intervale de temps données, grace a la fonction javascript setInterval. Si elles se lancent au moment ou je lance la troisieme requete manuellement (via un bouton, c'est une requete de selection d'ue table qui ne possede que moins de 10 lignes en gros), hé bien elle doit attendre la fin des deux autres requetes.

(NB: En fait les deux premieres requetes doivent consulter des tables regulierement (chaque 20 secondes) pour renvoyer des données, et la troisiement est une requete activée par l'utilisateur)

comment faire en sorte que chaque requete Ajax soit independante de sorte que celui qui finit vite renvoit le resultat sans attendre les autres? est ce un parametrage PHP ou MYSQL ou ...

Ce sujet ne tient a coeur SVP, je rame et mon application rame a cause de cela.

Merci

[Séb.]

Cela ressemble plutôt à un problème de traitement des retours.
Comment sont exécutées tes appels ?
Comment sont traités les retours ?
Normalement avec l'API JS fetch() (et ses promesses) et des frameworks JS progressifs comme Vue ou Alpine ça se fait plutôt bien

Maintenant la reponse est sequentielle

Forcément car JS traite séquentiellement les retours, chacun leur tour. Les facilités telles que les promesses ou les callbacks ne sont pas du vrai parallélisme, mais peuvent en donner l'illusion s'ils sont bien gérés grâce à leur nature asynchrone.

par exemple la premiere requete accede a une grosse table dans mysql pour renvoyer les données, tandis que la troisieme requete accede a une table de parametre avec juste 3 ou quatre lignes

Pourquoi ne pas lancer en premier la 3e requête ?

les deux premieres requetes se lancent a des intervale de temps données, grace a la fonction javascript setInterval. Si elles se lancent au moment ou je lance la troisieme requete manuellement (via un bouton, c'est une requete de selection d'ue table qui ne possede que moins de 10 lignes en gros), hé bien elle doit attendre la fin des deux autres requetes

C'est plus un problème de JS.
Comment gères-tu la réactivité de ton interface à l'arrivée de la data ?
Avec un framework comme Vue cela se fait naturellement.

[sajreborn]

Merci Seb pour la peine de lire et de me repondre. Ok je vais essayé d'apporter des reponses aux questions d'eclairicement que tu m'a posé.

Comment sont exécutées tes appels ?

via une fonction Ajax tout simple dont voici le code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
recvData = function(opt) {
  return new Promise((resolve, reject)=>{
 
    /*CREATION DE L\'OBJET AJAX SELON LE NAVIGATEUR*/
    if (window.XMLHttpRequest || !xhttp) {
      xhttp = new XMLHttpRequest();
    } else {
      /* code for IE6, IE5*/
      xhttp = new ActiveXObject("Microsoft.XMLHTTP");
    }
    xhttp.onreadystatechange = function() {};
 
    xhttp.onloadend = async function(e) {
      let response = null;
      if (xhttp.readyState === XMLHttpRequest.DONE) { // OU XMLHttpRequest.DONE=4
        if (xhttp.status === 200) { // tout est ok
          response = xhttp.responseText;
        } else { // En cas d'erreur !
          throw new Error(http.status);
          //alert('Une erreur est survenue !\n\nCode :' + xhttp.status + '\nTexte : ' + xhttp.statusText);
        }
      }
      //appelle la fonction de traitement
      resolve(response);
    };
    //DEFINTION DE  url , paramStartMarker, data, async ICI
    xhttp.open(method, url + paramStartMarker + data, async);
     //utile pour le serveur d'application
     xhttp.setRequestHeader('X-Requested-With', 'XMLHttpRequest');
     //SEND DATA
     xhttp.send(data);
}

bon c'est un peu factorisé sinon le code est juste un peu plus long, mais ca fonctionne bien. Bon j'ai utilisé ce script rapidement pour commencer a utiliser mes services PHP via Ajax, mais je peux le remplacer apres avec un framework , mais je note qu´il fonctionne bien.

Comment sont traités les retours ?

Du cote PHP je recupere les données POST si il y en a venant du client, puis via PDO je fais une requete preparée qui me renvoie les données de ma BDD sans probleme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
//requete preparer, puis execute 
$rows = $stmt->fetchAll(\PDO::FETCH_ASSOC);

ensuite toujours dans PHP je fais un retour JSON de ces données via echo json_encode($rows) et du cote du client dans le .then de ma promesse, je parse les données via JSON.parse puis si c'est une liste je parcour via un for, ou c'est une seule données je l'extrait et l'affiche via les document,querySelector

Normalement avec l'API JS fetch() (et ses promesses) et des frameworks JS progressifs comme Vue ou Alpine ça se fait plutôt bien

j'utilise les Promesses, mais je comptais utiliser plus tard un framework ou fetch diretement au lieu de ma fonction maison. Mais ca ne devait pas poser probleme vue que la fonction est simple et fonctionne bien.

Forcément car JS traite séquentiellement les retours, chacun leur tour. Les facilités telles que les promesses ou les callbacks ne sont pas du vrai parallélisme, mais peuvent en donner l'illusion s'ils sont bien gérés grâce à leur nature asynchrone.

hé bien moi je croyais. toujours est il que je penssait que en utilisant session_write_close, puisque je vois dans le devtools que toutes les requetes étaient lancées mais etaient en mode "attente", la requete qui se termine vite retournera les resultats independamment des autres.

Pourquoi ne pas lancer en premier la 3e requête

Bon il y a une frame qui doit rafraichir des données periodiquement, par exemple la quantite de stock, donc il y a un appel ajax periodique a interval de temps donné sur le service php qui check la vue qui calcul le nombre en stock et retourne la valeur JSON du stock total. cela marche.
Il y a une TABLE qui, elle, liste par exemple la liste des articles, sur la meme vue (par exemple quantite stock s áffiche en haut dans une frame, et liste des articles dans un simple div en bas), et j'y fais des recherche (dans le liste des articles via un champ input). Maintenant, il peut arrivé que le check automatique (AJAX+setInterval) des quantités (de la frame) soit lancé au moment ou je clique sur le bouton rechercher d'un article par exemple (puisque le check des quantite est a interval de temps), du coup ma requete de filtrage des articles est plus longue car elle attend la requete de check des quantites. (a part le check des quantité il y a une autre requete aussi autotmatique lancé dans une autre frame)
voila pourquoi ce n'est pas que je ne veuille pas lancé la 3e requete en premier, mais les deux sont automatique et le filtrage est manuel, et l'ordre peut etre aleatoire.

Comment gères-tu la réactivité de ton interface à l'arrivée de la data ?
Avec un framework comme Vue cela se fait naturellement.

non non, j'espere que je vais repondre a ta question. Voila quand les data arrivent, pour la quantité je remplace juste la valeur affiche dans la vue via un simple document.querySelector sur le ID de la quantité. Pour la seconde requete automaique dans un autre frame, il renvoi un liste de valeur que je parcours via un for pour afficher les données. Ensuite pour ma requete de filtrage des articles, pareil, j'utilise un for. Je note que les liste alimentent des tables. donc je nettoie le contenu et remet des td tr avec des valeurs.
Je note que je parse les donnees recues d'abord via JSON.parse.

J'espere avoir repondu, sinon n'hesitez pas a me questionner d'avantage ou si besoin de bout de code.

Merci vraiment de prendre le temps pour mon probleme bizarre.

[sajreborn]

J'ajoute que le temps d 'execution de ma requete MYQL (mes vues utilisee dans ce contexte ) aussi prennent un peu de temps dans l'environnement mysql.

Donc si une requete mysql est longue c'est obligé que sa combinaison ajax-php-mysql fasse attendre les autres requete ajax-php-mysql? et cela malgre session_write_close?

[Séb.]

Donc si une requete mysql est longue c'est obligé que sa combinaison ajax-php-mysql fasse attendre les autres requete ajax-php-mysql? et cela malgre session_write_close?

Une promesse permet d'effectuer d'autres traitements le temps qu'elle soit tenue ou rejetée, pour toi c'est le temps que les données soient récupérées.
Donc pas de blocages si tu utilises correctement les promesses.
Il faudrait voir comment tu procèdes avec recvData
C'est cela que j'entendais par "Comment sont traités les retours ?"

Ceci dit je ne vois pas trop l'intérêt de XMLHttpRequest ici (j'ai mal quand je vois new ActiveXObject("Microsoft.XMLHTTP"))
L'API JS fetch est supportée par Chrome/Firefox/Edge depuis 2015.

Bon il y a une frame qui doit rafraichir des données periodiquement

Aujourd'hui on peut faire sans frame.
Tu évolues dans un environnement particulier t'y obligeant ?

quand les data arrivent, pour la quantité je remplace juste la valeur affiche dans la vue via un simple document.querySelector sur le ID de la quantité. Pour la seconde requete automaique dans un autre frame, il renvoi un liste de valeur que je parcours via un for pour afficher les données. Ensuite pour ma requete de filtrage des articles, pareil, j'utilise un for. Je note que les liste alimentent des tables. donc je nettoie le contenu et remet des td tr avec des valeurs.

Ce genre de traitements est ~automatique avec Vue ou Alpine (ou d'autres).
Tu gagnerais *beaucoup* à les utiliser. Je te montre un exemple si tu veux.

[Séb.]

J'ajoute que le temps d 'execution de ma requete MYQL (mes vues utilisee dans ce contexte ) aussi prennent un peu de temps dans l'environnement mysql.

Donc si une requete mysql est longue c'est obligé que sa combinaison ajax-php-mysql fasse attendre les autres requete ajax-php-mysql? et cela malgre session_write_close?

Non, ça ne devrait pas être gênant qu'une requête soit longue.

[binarygirl]

J'ajoute que le temps d 'execution de ma requete MYQL (mes vues utilisee dans ce contexte ) aussi prennent un peu de temps dans l'environnement mysql.

Donc si une requete mysql est longue c'est obligé que sa combinaison ajax-php-mysql fasse attendre les autres requete ajax-php-mysql? et cela malgre session_write_close?

Qu'est-ce que vous appelez un peu de temps ?
Il est tout-à-fait possible, voire probable que les requêtes SQL peuvent être optimisées. Mais pour ça il faut au minimum voir la structure des tables, les index éventuels, tirer un plan d'exécution etc. Même si ça sort légèrement de votre problématique actuelle, réduire les temps de réponse ne peut qu'améliorer l'expérience utilisateur.

Et il y a d'autres techniques qui peuvent être mises en oeuvre: par exemple un cache, éviter de recalculer les mêmes données à répétition, dans certains cas même utiliser des tables in-memory.

Il y a peut-être un phénomène de deadlock qui se produit au niveau de la base de données, par exemple vous faites un update et en même temps tentez de lire sur la même table. Je spécule, car je n'ai aucune idée des requêtes mais il serait probablement intéressant de tuner votre accès à la DB.

[sajreborn]

Bonjour a tous et merci d'avoir pris le temps de me repondre.

Aujourd'hui on peut faire sans frame.
Tu évolues dans un environnement particulier t'y obligeant ?

Non, je les utilise car au debut avant que vous ne me parler de la fameuse fonction session_write_close, j'etais à la recherche d'une maniere de rendre requetes parallele et instantannées, j'ai donc TOUT essayé a un moment de désespoir, toute idée qui me venait en tete, était à tester d'ou les frame. voila un oeu l'histoire, sinon rien ne m'y contraint.

Ce genre de traitements est ~automatique avec Vue ou Alpine (ou d'autres).
Tu gagnerais *beaucoup* à les utiliser. Je te montre un exemple si tu veux.

Pourquoi pas, je connais pas ces framework, je l'avoue.

ce que j'ai déjà fait dans ce genre de cas est de détecter les mouvement de souris. un mouvement signifie que l'utilisateur est en train d'utiliser la page et donc dans ce cas

belle astuce Matthieu, mais dans un environnement mobile, ca risque de ne pas marché je crois.

j'ai aussi pensé à un autre verrou possible au niveau des requêtes sql si jamais elles utilisent des transactions. l'ouverture d'une transaction va mettre en attente les autres requêtes sql.

J'utilise les transaction, je ne travaille pas en general sur la plus part des mes requetes sans transaction. donc begintransaction et commit ou roolback en cas d'exception.

J'ajoute que le temps d 'execution de ma requete MYQL (mes vues utilisee dans ce contexte ) aussi prennent un peu de temps dans l'environnement mysql.

Donc si une requete mysql est longue c'est obligé que sa combinaison ajax-php-mysql fasse attendre les autres requete ajax-php-mysql? et cela malgre session_write_close?

Non, ça ne devrait pas être gênant qu'une requête soit longue.

Si mes requetes SQL ne justifie pas l'attente de mes autres requetes ajax-php-mysql, tant mieu, je vais optimiser cependant mes requetes SQL plus tard comme e souligne aussi binarygirl.

En resume, mon soucis qui est:

comment faire en sorte que chaque requete Ajax soit independante de sorte que celui qui finit vite renvoit le resultat sans attendre les autres?

Ne peut pas avoir de solution car :

Forcément car JS traite séquentiellement les retours, chacun leur tour. Les facilités telles que les promesses ou les callbacks ne sont pas du vrai parallélisme, mais peuvent en donner l'illusion s'ils sont bien gérés grâce à leur nature asynchrone.

SI J'AI COMPRIS, donc quelque soit ce que je vais utiliser si par exemple il y a trois requete:

1. requete 1 doit finir et retourner le resultat;
   requete 2 patiente que requete 1 retourne son resultat JSON avant de RETOURNER SON RESULTAT à lui;
   requete 3 patiente que requete 2 retourne son resultat JSON avant de RETOURNER SON RESULTAT à lui

donc si la premiere requete doit, via PDO,retourner la liste des mutations de cellules depuis la creation de l'univers, les deux autres requetes peuvent faire leur testament et cela jý peux rien.
Je ne veux pas me lancer dans une resolution de probleme alors que c'est pas possible en fait:
DONC:

est ce que les retours (comme l'a dit Seb c'est un soucis de retour), seront toujours sequentiels, du coup je dois juste reduire mes temps d'execution SQL car c'est là que cela prend du temps je me suis rendu compte, car mes scripts php ne font rien que recevoir les requete ajax, executer ma requete SQL via PDO et retourner les resultats, alors que quand je me connecte en `mysql -u root -p...` et que je lance ces meme requetes, cela prend du temps. a moins que les requetes SQL plus ou moins lente, ne peuvent pas justifier l'attente des autres requetes ajax lancées?

Est ce que quelque soit l'ordre dans lequel se lance mes script, les retours se feront TOUJOURS SELON L'ORDRE et NON SELON le plus rapide , et meme executer avec des Promesses, un retour de requete fera attendre les autres requete ajax, meme avec session_write_close??

Si vous me dites que cela ne depend pas de SQL (car je ne sais pas si il y a une methode magique pour faire ca), alors si il y a une solution? je doit revoir ma fonction maison AJAX (je vais la remplacer de toute facon par l'API fetch)

[mathieu]

voila pourquoi ce n'est pas que je ne veuille pas lancé la 3e requete en premier, mais les deux sont automatique et le filtrage est manuel, et l'ordre peut etre aleatoire.

ce que j'ai déjà fait dans ce genre de cas est de détecter les mouvement de souris. un mouvement signifie que l'utilisateur est en train d'utiliser la page et donc dans ce cas, la grosse mise à jour est retardée de quelques secondes ce qui permet à la requete de recherche de passer en premier.
je ne connais pas du tout les frameworks Vue ou Alpine proposés par Séb donc c'est possible que ces framework proposent quelque chose pour gérer cela.

j'ai aussi pensé à un autre verrou possible au niveau des requêtes sql si jamais elles utilisent des transactions. l'ouverture d'une transaction va mettre en attente les autres requêtes sql.
si c'est ça, regardez cet article pour le réglage des niveaux d'isolation des transactions :
https://sqlpro.developpez.com/isolation-transaction/

[sajreborn]

Desole de n'avoir pas repondu plutot, des travaux maisons.

Je lis et je vous reponds.

Merci encore a Matthieu et Seb.

Je vous reponds suite à la lecture de vos messages.