Как вы настраиваете свой пул подключений?

Question

Каков наилучший способ настройки вашего пула с учетом:-

1. Когда вы создаете связи?
2. Когда вы закрываете соединения и закрыли бы ли бы вы их все?
3. У вас тестовые соединения все еще в порядке?Когда и как?
4. Как вы определяете правильное число для максимального количества подключений?
5. Какой вид мониторинга вы применяете для обеспечения надлежащего поведения пользователей пула?Можете ли вы помешать одному плохому фрагменту кода уничтожить все?
6. Вы написали свой собственный пул или использовали стороннюю библиотеку?

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

Чтобы уточнить, я не собираюсь писать пул с нуля, этот вопрос больше о том, как настроить существующую библиотеку, которая выполняет объединение в пул.

Answer 1

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

Я использовал поток для мониторинга нескольких аспектов пула и нескольких параметров для управления его поведением ...

<Ол>

imumInPool = " 3 " ... Эти первые три создаются при запуске. Пул никогда не должен опускаться ниже трех.

maximumIdleTimeBeforeRemoval = " 60 "... Если соединение не используется в течение часа, затем отбросьте его и создайте новое. Время простоя, вероятно, означает, что в пуле только три.

maximumInUseTimeBeforeRemoval = " 30 " ... Если данное соединение было проверено в течение более 30 минут, возможно, что-то не так. Вспомни это и убей соединение.

maximumTimeBeforeRemoval = " 60 "... Удалите его, если ему более 60 минут.

maximumUsageBeforeRemoval = " 1000 "... Удалите его, если оно было извлечено более 1000 раз.

monitorInterval = " 15 " ... Проверяйте вышеуказанные параметры каждые 15 минут.

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

Я использовал тонкие драйверы JDBC от Oracle и подключился к базе данных Oracle.

Answer 2

Вот обоснование, которое я использовал для недавней реализации.

<Ол>

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

Пул соединений должен поддерживать небольшое количество готовых соединений, минимум N и максимум M. N можно настроить в зависимости от пиковой скорости, с которой ваши клиенты запрашивают соединения. Если количество готовых соединений когда-либо падает до нуля, вам нужно большее значение N. Если число постоянно высокое (скажем, выше 10), вам нужно меньшее значение N.

Когда клиент хочет установить соединение, дайте ему один из готовых (сделав его активным), а затем немедленно откройте новый, если теперь готово меньше N (но не заставляйте клиента ждать этого для завершения, или вы потеряете преимущество объединения). Это гарантирует, что всегда будет хотя бы N готовых соединений. Если ни один из них не готов, когда клиент этого захочет, ему придется подождать, пока вы создадите новый.

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

Периодически перерабатывайте готовые соединения, чтобы предотвратить устаревшие соединения. Если подключений больше N, просто закройте самое старое соединение. В противном случае закройте его и снова откройте другой.

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

Answer 3

Jakarta Commons DBCP уже выполняет все, что вы перечислили:

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

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

Answer 4

Я согласен с Мэттом Б, что мы не должны изобретать велосипед.

Однако об использовании DBCP Commons можно спорить, основываясь на ответах этот и этот вопрос. Там упоминаются лучшие альтернативы, такие как c3po или proxool .

Или вы можете использовать зависимый от rdbms механизм пула соединений.

Answer 5

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

Я использую SQL server в качестве серверной части и использую комбинацию кэширования с ним для повышения производительности.Моя практика заключается в том, чтобы сохранять соединение открытым только в том случае, если мне это действительно нужно, и не объединять соединения в пул, чтобы они сразу же очищались, и я мог видеть в SQL Activity monitor, что именно активно, а что нет.Каждое соединение занимает много памяти, поэтому приятно сводить его к глухому грохоту, когда они не нужны.

Прежде чем я отвечу на вопрос об открытии и закрытии соединения, позвольте мне сказать, что кэширование действительно важно.Извлечение объекта из кэша сэкономит вам массу времени.В некоторых моих asp.net приложения, когда кэширование включено в dev, я обнаружил, что с трудом могу измерить задержку, тогда как при вызове базы данных для завершения вызова может потребоваться от 15 мс до 45 мс, и это даже без учета других факторов задержки или нагрузки.Другой метод, который я использую, - это хорошая структура объекта для моих данных, так что я обновляю базу данных только в том случае, если что-то меняется.Я реализовал несколько методов на своем объекте, чтобы убедиться, что я выполняю как можно меньше операций ввода-вывода.

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

1. Держите двери и окна закрытыми, чтобы экономить энергию.Открытое соединение в одном месте означает, что оно недоступно в другом (или память и другие ресурсы более ограничены).Мы отключили объединение ресурсов, потому что это привело к повышению производительности для нас.

2. Я делаю столько всего пакетно или сразу, сколько могу, когда соединение открыто.Это немного сложнее, поэтому позвольте мне объяснить.

   • один из методов, который я использовал, заключается в передаче моих объектов connection по каналу, чтобы все объекты могли использовать один объект connection.Это приводит к тому, что одно соединение открывается и закрывается вместо, возможно, 10 или более, в зависимости от вашего приложения.Хорошим примером этого является одна из наших моделей закупок, которая использует возможности SQL server для сбора статистики и хэширования сложных шаблонов заказов.Не имеет смысла продолжать открывать и закрывать соединение, когда вы выполняете поиск по базе данных 200K + или для чего еще предназначены приложения.Другая часть этого заключается в том, что когда я использую object, я пытаюсь объединить свои обновления, чтобы сократить время, в течение которого я поддерживаю соединение открытым.Итак, выполнение scope_identity при вызове insert позволяет мне позаботиться как о моей вставке, так и о поиске уникального идентификатора для добавления к моему объекту, прежде чем кэшировать его.Раньше, когда я только разрабатывал asp-приложения, я открывал соединение, как только страница начинала загружаться, а затем закрывал ее после этого.Я больше не рекомендую этого делать.В настоящее время в такого рода абстракциях и слоях есть большое преимущество, на которое я бы порекомендовал любому начинающему программисту обратить пристальное внимание.

Мои два цента:

Кэшируйте свои данные!Кэшируйте свои данные!Кэшируйте свои данные!Делайте как можно меньше обращений к базе данных, когда вы не можете кэшировать, а затем кэшируйте свои данные!

Answer 6

Зачем изобретать велосипед?

Кто-то, возможно, уже решил проблему, и лучше.

Если вы находитесь в мире Java, вы можете использовать Commons DBCP .