Как pgBouncer помогает ускорить Django

помимо сохранения накладных расходов connect & disconnect, где это в противном случае делается по каждому запросу, пул соединений может перенаправить большое количество клиентских подключений до небольшого количества фактических подключений к базе данных. В PostgreSQL оптимальное количество активных подключений к базе данных обычно находится где-то ((2 * core_count) + effective_spindle_count). Выше этого числа пропускная способность и задержка ухудшаются.

иногда люди говорят: "Я хочу поддержать 2000 пользователи, с быстрым временем отклика."В значительной степени гарантируется, что если вы попытаетесь сделать это с 2000 фактическими подключениями к базе данных, производительность будет ужасной. Если у вас есть машина с четырьмя четырехъядерными процессорами и активный набор данных полностью кэширован, вы увидите гораздо лучшую производительность для этих 2000 пользователей, направляя запросы через 35 подключений к базе данных.

реальный сервер баз данных имеет больше ресурсов, которые можно использовать параллельно, но тот же принцип работает, как только они насыщены, вы только вредите вещам, добавляя более параллельные запросы базы данных. Это на самом деле хуже, чем в Примере, потому что с большим количеством задач у вас больше переключателей задач, повышенная конкуренция за блокировки и кэш, L2 и L3 cache line contention и многие другие проблемы, которые сокращают пропускную способность и задержку. Кроме того, в то время как высокий work_mem настройка может помочь запросу несколькими способами, Эта настройка является пределом на узел плана для каждого связи, поэтому при большом количестве соединений вам нужно оставить этот очень маленький, чтобы избежать промывки кэша или даже привести к замене, что приводит к более медленным планам или таким вещам, как хэш-таблицы, разливающиеся на диск.

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