Пул соединений - Сколько накладных расходов?

Question

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

Answer 5

Я думаю, что это плохой дизайн. Похоже, что движок правил Rete запускается amok.

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

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

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

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

Answer 6

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

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

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

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