Медленные запросы в Data Explorer

Я создал несколько запросов в Data Explorer.

Если я выполняю их в административной панели, GUI показывает очень быстрое время выполнения самого запроса к базе данных, например: «Запрос выполнен за 7,9 мс».

В сетевом журнале моего браузера видно, что, например, к https://example.com/admin/plugins/explorer/queries/1/run был выполнен запрос, и получение результата заняло в 1–2 порядка больше времени, например 150 мс.

Когда я выполняю такой запрос через curl, это занимает ещё больше времени — примерно в два раза дольше, чем при запуске запроса в административной панели.

Как мне получить быстрые запросы в Data Explorer без таких больших накладных расходов?

Исходя из предоставленной вами информации, я бы сказал, что это простые запросы (быстро выполняются в СУБД), которые возвращают много строк (медленная сериализация/десериализация в бэкенде и передача).

Если текущая производительность мешает вашему сценарию использования, есть множество различных решений, которые вы можете рассмотреть:

  • Уменьшение количества строк на страницу, чтобы каждая страница обрабатывалась быстрее.

  • Создание плагина, который предоставляет ту же информацию через новую конечную точку API и более эффективно управляет кэшированием и форматом данных.

  • Прямой запрос к базовой базе данных.

У нас есть автоматическое сопоставление для определённых имён столбцов (user_id, post_id и т. д.), которые переименовываются в другие, например, post_id1 и т. д.

Спасибо, ребята!

Это происходит даже если результатом запроса является всего одна строка. Например, запрос, возвращающий одно целое число, выполняется за 9 мс в панели Data Explorer в административной панели, но при выполнении извне через API Data Explorer с помощью curl — за 200 мс.

Я бы очень хотел избежать этого. Я использую Data Explorer, потому что на этих форумах его рекомендовали как удобный способ получения информации из БД и как хорошо работающий API для этих целей.

Мой запрос использует их для JOIN, но не в результирующем наборе. В операторе SELECT только один столбец, и это новый вычисляемый столбец с произвольным именем.

Что говорит NGINX о времени сервера для этого запроса? Не может ли это быть проблемой сети?

Если предположить, что это числа с плавающей точкой, расположенные сразу после кода состояния HTTP (например, ... 200 642 "-" **0.107 0.108** "system" ..., выделенные мной звездочками), то они примерно в 10 раз превышают время выполнения запроса, reported в бэкенде, и практически точно составляют половину времени, необходимого для выполнения curl с моего клиента.