Se le eseguo nel backend di amministrazione, l’interfaccia grafica mi mostra un tempo di esecuzione molto rapido per la query del database stessa, ad esempio “Query completata in 7,9 ms”.
Il log di rete del mio browser mostra che, ad esempio, è stato effettuato l’accesso a https://example.com/admin/plugins/explorer/queries/1/run e che ci sono voluti da 1 a 2 ordini di grandezza in più per ottenere il risultato, ad esempio 150 ms.
Quando eseguo una query del genere con curl, ci vuole ancora più tempo, circa il doppio del tempo rispetto all’esecuzione della query nel pannello di amministrazione.
Come posso ottenere query di Data Explorer che possa recuperare velocemente senza così tanto overhead?
Sulla base delle informazioni fornite, direi che si tratta di query semplici (veloci da eseguire nel RDBMS), che restituiscono molte righe (lente da de/serializzare nel backend e trasferire).
Se le prestazioni attuali bloccano il tuo caso d’uso, ci sono molte soluzioni diverse che puoi esplorare:
Ridurre il numero di righe per pagina, in modo che ogni pagina sia più veloce.
Creare un plugin che esponga le stesse informazioni in un nuovo endpoint API ed sia più intelligente nella gestione della cache e del formato dei dati.
È lo stesso se ho solo una singola riga come risultato di una query. Ad esempio, una query che restituisce un singolo intero, eseguita nel pannello Data Explorer nel backend di amministrazione richiede 9 ms, eseguita dall’esterno contro l’API Data Explorer tramite curl richiede 200 ms.
Mi piacerebbe molto evitarlo, uso Data Explorer perché è stato suggerito su questi forum come un buon modo per ottenere informazioni dal DB e un’API ben funzionante per questo.
La mia query li usa per i JOIN ma non nel set dei risultati. Il SELECT ha solo una colonna ed è una colonna appena calcolata con un nome arbitrario.
Supponendo che questi siano i numeri in virgola mobile 3 posti a destra del codice di stato HTTP (ad es. ... 200 642 "-" **0.107 0.108** "system" ..., evidenziati con stelle da me) sono circa 10 volte la durata del tempo di query riportato nel backend e praticamente esattamente la metà del tempo necessario per curl dal mio client.