Пул подключений - сколько это накладных расходов?

Question

Я запускаю веб-приложение на сервере приложений Webpshere 6.1. Это веб-приложение имеет механизм правил, где каждое правило получает свое собственное соединение из пула источников данных websphere. Итак, я вижу, что при запуске варианта использования для 100 входных записей из пула получается около 400-800 соединений и возвращается обратно в пул. У меня есть ощущение, что если этот двигатель поступит в производство, то для его завершения может потребоваться слишком много времени.

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

Answer 1

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

На самом деле это хорошая идея, потому что открытие соединения - это не одноразовая вещь. Существует много поездок на сервер (проверка подлинности, поиск, состояние и т. Д.). Поэтому, если на вашем веб-сайте есть пул соединений, вы быстрее обслуживаете своих клиентов.

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

Answer 2

Пул соединений - это все о повторном использовании соединения.

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

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

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

Короче говоря: пулы соединений просто обожают когда вы возвращаете их соединения. Или они должны все равно.

Answer 3

Бассейн, похоже, не ваша проблема. Настоящая проблема заключается в том, что ваш «движок правил» не освобождает соединения обратно в пул до завершения всего вычисления. Кажется, двигатель плохо масштабируется. Если количество подключений к базе данных так или иначе зависит от количества обрабатываемых записей, что-то почти всегда очень неправильно!

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

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

Answer 4

Я думаю, что это плохой дизайн. Похоже, двигатель правил Rete работает безумно.

Если вы предполагаете, что минимум 0,5-1,0 МБ на поток (например, для стека и т. Д.), Вы будете тратить много памяти. Проверка соединений внутри и вне пула будет наименьшей из ваших проблем.

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

Иногда я вижу, что люди предполагают, что они бросают все свои правила в Blaze, ILOG, JRules или Drools просто потому, что это «стандарт» и высокие технологии. Это потрясающее резюме, но сколько из этих решений будет лучше обслуживать более простое дерево решений на основе таблиц? Может быть, ваша проблема одна из тех.

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

Answer 5

Чтобы по-настоящему проверить, является ли ваш бассейн бутылочным горлышком, вы должны профилировать свою программу. Если вы обнаружите, что пул является проблемой, значит, у вас проблема с настройкой. Простой пул должен иметь возможность обрабатывать 100 Кбайт в секунду или более или около 10 микросекунд. Однако как только вы используете соединение, для выполнения чего-либо полезного потребуется от 200 до 2000 микросекунд.

Answer 6

Не могли бы вы предоставить более подробную информацию о том, что именно делает ваш механизм правил? Если каждое правило «срабатывание» выполняет обновления данных, вы можете проверить, правильно ли освобождается соединение (поместите это в блок finally вашего кода, чтобы убедиться, что соединения действительно освобождаются).

Если возможно, вы можете рассмотреть возможность захвата ваших обновлений данных в буфер памяти и записи в базу данных только в конце сеанса / вызова правила.

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

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