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

Question

Дискуссия о синглетонах в PHP заставляет меня все больше и больше задумываться над этим вопросом.Большинство людей говорят, что вы не должны создавать кучу подключений к БД в одном запросе, и мне просто любопытно, каковы ваши доводы.Моя первая мысль - это затраты вашего скрипта на выполнение такого количества запросов к базе данных, но затем я задаю себе вопрос:разве несколько подключений не сделали бы одновременный запрос более эффективным?

Как насчет нескольких ответов (с доказательствами, ребята) от некоторых знающих людей?

Answer 1

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

Кроме того, использование тонны дополнительных подключений к базе данных ничему не помогает, если только на сервере базы данных нет простаивающих ресурсов.Если у вас 8 ядер и только одно используется для удовлетворения запроса, то, конечно, может помочь создание другого соединения.Однако более вероятно, что вы уже используете все доступные ядра.Вы также, вероятно, используете один и тот же жесткий диск для каждого запроса к базе данных и добавляете дополнительную блокировку.

Если в вашей базе данных есть что-то, напоминающее высокую загрузку, добавление дополнительных подключений не поможет.Это было бы похоже на создание дополнительных потоков в приложении в слепой надежде, что дополнительный параллелизм ускорит обработку.IT мог бы при некоторых определенных обстоятельствах, но в других случаях это просто замедлит вашу работу, поскольку вы будете перегружать жесткий диск, тратить время на переключение задач и создавать накладные расходы на синхронизацию.

Answer 2

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

Найти доказательства сложнее, но учтите следующее...

Допустим, для установления соединения требуется x микросекунд.

Теперь вы хотите сделать несколько запросов и получать данные взад и вперед.Допустим, что разница во времени передачи незначительна между одним соединением и многими другими (просто ради аргументации).

Теперь предположим, что для закрытия соединения требуется y микросекунд.

Открытие одного соединения займет x + y микросекунд накладных расходов.Открытие многих займет n * (x + y).Это отсрочит вашу казнь.

Answer 3

Настройка подключения к базе данных обычно довольно сложна.За кулисами происходит много чего интересного (Разрешение DNS / TCP-соединение / Рукопожатие / Аутентификация / Фактический запрос).

Однажды у меня была проблема с какой-то странной конфигурацией DNS, из-за которой каждое TCP-соединение занимало несколько секунд перед запуском.Для завершения моей процедуры входа в систему (из-за сложной архитектуры) потребовалось 3 разных подключения к базе данных.Из-за этой проблемы вход в систему занял целую вечность.Затем мы реорганизовали код, чтобы он проходил только через одно соединение.

Answer 4

Мы получаем доступ к Informix из .NET и используем несколько подключений.Если мы не запускаем транзакцию для каждого соединения, она часто обрабатывается в пуле соединений.Я знаю, что это очень специфично для бренда, но cilent access большинства (?) систем баз данных будет объединять соединения в меру своих возможностей.

Кроме того, у нас действительно была проблема с количеством подключений из-за межбазных подключений.Informix поддерживает синонимы, поэтому мы назвали синонимами распространенных нарушителей, а множественные подключения обрабатывались на стороне сервера, что значительно экономило время передачи, накладные расходы на создание соединения и (что действительно важно для нашей ситуации) лицензионные сборы.

Answer 5

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

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

Асинхронные запросы снижают стоимость подключения за счет ускорения времени запроса / ответа ... потому что вы не можете легко добейтесь этого в PHP без каких-либо потоков, тогда снижение производительности будет больше, чем при простом повторном использовании того же соединения.

это мои 2 цента...