Вопрос

Я помню, что слышал, что процесс подключения в mysql был разработан так, чтобы быть очень быстрым по сравнению с другими СУБД, и поэтому использование библиотека, которая обеспечивает пул соединений (SQLAlchemy) на самом деле не поможет вам так сильно, если вы включите пул соединений.

Есть ли у кого-нибудь опыт в этом вопросе?

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

Это было полезно?

Решение

Нет необходимости беспокоиться об остаточном состоянии соединения при использовании пула соединений SQLA, если только ваше приложение не меняет параметры всего соединения, такие как уровни изоляции транзакций (что обычно не так).Пул соединений SQLA выдает метод Connection.rollback() для соединения при его повторной проверке, чтобы очистить любое состояние транзакции или блокировки.

Вполне возможно, что время соединения MySQL довольно быстрое, особенно если вы подключаетесь через сокеты unix на одном компьютере.Если вы используете пул соединений, вы также хотите убедиться, что соединения перезапускаются через некоторый период времени, поскольку клиентская библиотека MySQL автоматически закрывает соединения, которые простаивают более 8 часов (в SQLAlchemy это опцияpool_recycle).

Вы можете быстро провести сравнение пула соединений и пула соединений.не с приложением SQLA, изменив реализацию пула со значения по умолчанию QueuePool на NullPool, который представляет собой реализацию пула, которая на самом деле ничего не объединяет - он подключается и отключается по-настоящему, когда прокси-соединение получено, а затем закрыто.

Другие советы

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

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

Короткий ответ:вам нужно сравнить его.

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

Другое беспокойство вызывает то, как приложение обрабатывает поток SQL.Если он не выполняет транзакции SQL и не делает предположений о состоянии потока, то объединение в пул не будет проблемой.OTOH, код, который полагается на закрытие потока для удаления временных таблиц или отката транзакций, будет иметь много проблем с объединением в пул.

Пул соединений ускоряет работу за счет того, что вам не нужно создавать объект java.sql.Connection каждый раз, когда вы выполняете запрос к базе данных.Я использую пул соединений Tomcat с базой данных mysql для веб-приложений, которые выполняют много запросов, при высокой пользовательской нагрузке наблюдается заметное улучшение скорости.

Я создал простой RESTful-сервис с помощью Django и протестировал его с пулом соединений и без него.В моем случае разница была весьма заметна.

В локальной сети без него время ответа составляло от 1 до 5 секунд.С ним менее 20 мс.Результаты могут отличаться, но конфигурация, которую я использую для серверов MySQL и Apache, довольно стандартная и недорогая.

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top