Влияет ли использование большого количества различных строк соединений с пулами соединений на эффективность? - PullRequest
0 голосов
/ 08 июля 2019

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

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

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

1 Ответ

1 голос
/ 09 июля 2019

Прочитайте этот недавний выпуск , который касается именно этого, помимо прочего.

tl; др. Да, любое различие в строке подключения приводит к другому пулу подключений, что может оказать существенное влияние на производительность, поскольку подключения привязаны к определенному арендатору и не могут использоваться совместно - в общем случае это настоятельно рекомендуется иметь только один бассейн.

Одним из способов решения этой проблемы (как и в проблеме) является ручная установка search_path при каждом переключении на нового арендатора.

...