Si je les exécute dans le backend d’administration, l’interface graphique m’indique un temps d’exécution très court pour la requête de base de données elle-même, par exemple : « Requête terminée en 7,9 ms ».
Le journal réseau de mon navigateur montre que, par exemple, https://example.com/admin/plugins/explorer/queries/1/run a été accédé et qu’il a fallu 1 à 2 ordres de grandeur plus longtemps pour obtenir le résultat, par exemple 150 ms.
Lorsque j’utilise curl pour une telle requête, cela prend encore plus de temps, environ deux fois le temps par rapport à l’exécution de la requête dans le panneau d’administration.
Comment puis-je obtenir des requêtes Data Explorer que je peux récupérer rapidement sans autant de surcharge ?
D’après les informations que vous avez fournies, je dirais qu’il s’agit de requêtes simples (rapides à exécuter dans le SGBDR), qui retournent de nombreuses lignes (lentes à désérialiser/sérialiser dans le backend et à transférer).
Si les performances actuelles bloquent votre cas d’utilisation, vous pouvez explorer de nombreuses solutions différentes :
Réduire le nombre de lignes par page, afin que chaque page soit plus rapide.
Créer un plugin qui expose les mêmes informations dans un nouveau point de terminaison d’API et qui est plus intelligent en matière de mise en cache et de format de données.
Interroger directement la base de données sous-jacente.
Nous avons des recherches magiques pour certains noms de colonnes (user_id, post_id, etc.) qui les aliasent en quelque chose d’autre comme post_id1 etc.
C’est la même chose si j’ai une seule ligne comme résultat d’une requête. Par exemple, une requête qui renvoie un seul entier, exécutée dans le panneau Data Explorer du backend d’administration, prend 9 ms, exécutée de l’extérieur contre l’API Data Explorer via curl, elle prend 200 ms.
J’aimerais beaucoup éviter cela, j’utilise Data Explorer car il a été suggéré sur ces forums comme un bon moyen d’obtenir des informations de la base de données et une API qui fonctionne bien pour cela.
Ma requête les utilise pour des JOIN mais pas dans l’ensemble de résultats. Le SELECT n’a qu’une seule colonne et c’est une colonne nouvellement calculée avec un nom arbitraire.
En supposant qu’il s’agisse des nombres à virgule flottante à 3 décimales à droite du code d’état HTTP (par exemple, ... 200 642 "-" **0.107 0.108** "system" ..., mis en surbrillance par des étoiles de ma part), ils sont environ 10 fois la durée du temps de requête rapporté dans le backend et à peu près exactement la moitié du temps nécessaire à curl depuis mon client.