Задать вопрос
@moem

Быстрее ли несколько параллельных запросов одного последовательного?

Здравствуйте.
Дано: веб-приложение. На клиенте (js, jquery) формируются аякс запросы вида
$.ajax({
  url: "some.php",
  data: { whatyouwants: "smth1,smth2,smth3" }
})

На сервере скрипт some.php обрабатывает запрос и формирует последовательные sql запросы к БД firebird через одно постоянное PDO соединение. Ответ из БД тот же some.php преобразует в json вида {smth1:[...], smth2:[...], smth3:[...]} и возвращает клиенту. Структуру БД менять нельзя.
Проблема: медленное выполнение.
Попытка решения: вместо одного аякс запроса послать три вида:
$.ajax({
  url: "some.php",
  data: { whatyouwants: "smthN" }
})

Результат: фиаско. Для примера: один аякс запрос выполнялся 30 сек (на сервере: smth1 - 5сек, smth2 - 10сек, smth3 - 15сек, время подключения и передачи пренебрежимо мало). Думал, что три запроса вместе выполняться за 15сек (по самому долгому запросу к БД). Не тут то было. При трех параллельных запросах: smth1 - 15сек, smth2 - 25сек, smth3 - те же 30сек.
На каком-то этапе параллельные запросы также выстраиваются в очередь. Если в то же время подать аналогичные запросы с другого клиента, то время ожидания ещё больше растягивается.
Получается, что один последовательный запрос, что несколько параллельных, имеют сопоставимую продолжительность.
Вопросы:
Есть ли в распараллеливании запросов рациональное зерно?
Почему нет прироста скорости?
Есть ли какие-нибудь настройки apache, php, firebird, позволяющие получить выигрыш в скорости при распараллеливании запросов?
Спасибо.
  • Вопрос задан
  • 883 просмотра
Подписаться 2 Оценить 3 комментария
Ответ пользователя Melkij К ответам на вопрос (2)
Melkij
@Melkij
DBA Team для вашего PostgreSQL?
Есть ли в распараллеливании запросов рациональное зерно?

Есть, если треды не дерутся за одно и те же ресурсы. Например, ходят в физически разные кластеры БД.

Получается, что один последовательный запрос, что несколько параллельных, имеют сопоставимую продолжительность.

Или вы неверно описали наблюдаемый результат или же параллельное выполнение медленнее в 2 раза и дальше ухудшается при конкурентной нагрузке.

На каком-то этапе параллельные запросы также выстраиваются в очередь.

Запросто. Но на вашу наблюдаемую картину не похоже, у вас время выполнения работы выросло в несколько раз.
Значит процессы дрались за ресурсы и очень сильно мешали друг другу.

Если в то же время подать аналогичные запросы с другого клиента, то время ожидания ещё больше растягивается.

Что подтверждает диагноз. Ресурсов для параллельного выполнения нет.

Поскольку вопрос затрагивает субд и вы не называете, что там происходит - самое очевидно - вы упёрлись в диски. Возможно даже в механические диски. Добавление новых io задач на диски ожидаемо и очень сильно замедляет весь остальной io.
Ответ написан