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

Question

[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, позволяющие получить выигрыш в скорости при распараллеливании запросов?
Спасибо.

Comments

[Evgeny Kulakov]

Может проблема в том насколько долго обрабатывается запрос именно firebird? vможет у нее есть ограничение на кол-во запросов в секунду например.

[Stalker_RED]

Профилировать вы не пытались? Замерять какая операция солько времени занимает, где у вас узкое место и во что упор. Может у вас объем данных такой, что hdd не успевает, например (это выстрел в небо наугад, скорее всего причина в другом).

[moem]

Там запрос по временным неиндексированным полям. Несколько миллионов записей. Firebird пока все не просмотрит - результат не отдаст, даже если результат пустой.
Похоже, что проблема действительно в firebird и "драке" за одни и те же данные. Думал, что он сам распараллелит, закеширует, разрулит. Но пока не судьба.

Answer 1

[Melkij]

Есть ли в распараллеливании запросов рациональное зерно?

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

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

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

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

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

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

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

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

Comments

[moem]

Там запрос по временным неиндексированным полям. Несколько миллионов записей. Firebird пока все не просмотрит - результат не отдаст, даже если результат пустой.
Похоже, что проблема действительно в firebird и "драке" за одни и те же данные. Думал, что он сам распараллелит, закеширует, разрулит. Но пока не судьба.
И да, диск механический.

[Melkij]

По firebird'у подсказать не могу.
Может у него настроек по памяти не хватает на размещение таблички inmemory.

Answer 2

[Иван]

В распараллеливании смысл, конечно, есть. Просто это должно делаться на всех уровнях. Апач не использовал уже несколько лет, поэтому тут ничего сказать не могу, но судя по описанным симптомам, затыком у тебя является БД.
Конкретно с firebird не работал, но наверняка её можно распараллелить через репликации.
Т.е. сейчас у тебя получается 3 php-скрипта делают запросы к бд. Бд обрабатывает запросы синхронно, поэтому никакого выйгрыша в скорости не получается. Можно либо в настройках бд поискать асинхронную обработку запросов, но врядли там такое есть, либо реплицировать бд по типу мастер-слейв и запрашивать с разных слев-серверов бд данные, тогда прирост в скорости будет.