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

Question

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

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

Answer 1

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

Пул соединений - это то, что вы не заметите при небольшой нагрузке. 1 или 2 или 10 пользователей, вы, вероятно, увидите 0 или почти 0 разницы. Вам нужно будет создать какой-то тест на нагрузочное тестирование, чтобы моделировать сотни пользователей одновременно, а затем сравнить производительность с пулами и без них.

Answer 2

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

Answer 3

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

См. Также этот другой вопрос SO о принудительном прекращении соединения в пуле.

(Предупреждение: я использую ADO и ADO.NET; JDBC может вести себя по-разному.)