Многопоточность и соединение (соединения) с базой данных
Таким образом, я пытаюсь выяснить лучшие практики на своем соединении с базой данных. У меня есть большой GUI.NET, который служит фронтэндом для дб MySQL. В настоящее время я открываю соединение на загрузке приложения и использую ее для любых взаимодействий, в которых я нуждаюсь. Однако весь GUI является однопоточным.
Поскольку я начинаю добавлять BackgroundWorkers для выполнения больших запросов, и выполняется, я обеспокоен своим открытым соединением. Я знаю, например, что у меня может только быть один dataReader, за один раз открываются на том соединении. С несколькими потоками пользователь мог попытаться инстанцировать больше, чем это.
Каковы преимущества / недостатки хранения одного открытого соединения для приложения по сравнению с открытием нового соединения для каждого взаимодействия?
Каковы некоторые шаблоны общего умысла для этого?
Спасибо -
Jonathan
5 ответов
Используйте пул соединений, безопасный для потоков, и храните соединения в зависимости от потока (не делите соединения между потоками).
Я полагаю, что фреймворк соединений MySQL .NET поставляется со встроенным пулом. Если вы используете одну и ту же строку подключения для всех соединений, просто добавьте "pooling=true" в строку подключения. (Источник -- здесь нет фрагмента гиперссылки, поэтому ищите "pooling" в таблице)
Недостатком этого подхода является то, что некоторые потоки будут блокироваться, пока не появится соединение. Вам нужно будет учесть это в структуре вашей программы.
Есть 2 способа:
Одно соединение - в этом случае соединение создается 1 раз и делится между всеми запросами, что, если большое количество одновременных запросов приводит к потере производительности, и вы должны контролировать сохранение потока. самостоятельно.
Соединение по запросу - в этом случае вы должны открыть соединение и закрыть его сразу после выполнения запроса. Но количество одновременно открытых соединений может быть ограничено сервером. Здесь всегда присутствуют накладные расходы на создание подключений, но они решаются с помощью поточно-безопасного пула подключений, что было хорошей практикой.
Вам необходимо проанализировать и спрогнозировать поведение вашего приложения и выбрать подходящий путь. Если у вас простое приложение, вам, вероятно, не нужно будет использовать пулы. Если приложению требуется серьезная нагрузка и масштабируемость в будущем, правильным будет использование пулов.
При одном открытом соединении у вас должна быть максимальная пропускная способность с базой данных. Однако вы в конечном итоге пишете сложный код в своем приложении для совместного использования соединения.
Здесь - статья о шаблонах совместного использования ресурсов. Примеры есть на Аде, но я уверен, что вы все равно сможете это прочитать.
Подключение к источнику данных может занимать много времени. Чтобы минимизировать затраты на открытие соединений, ADO.NET использует технику оптимизации, называемую объединением соединений, которая минимизирует затраты на многократное открытие и закрытие соединений. Пул соединений по-разному обрабатывается для поставщиков данных .NET Framework.
из MSDN.
см. здесь Connection Pooling (ADO.NET)
Мы провели несколько тестов, прежде чем решить, куда идти. Я имею в виду между ConnectionAlwaysOpen или ConnectAndDisconnectEachTime.
Очевидно, из .NET с SQL Server (никогда не пробовал с MySQL) не было видимого снижения производительности ни в одном из подходов (ничего удивительного, поскольку нижние уровни на самом деле не отключаются немедленно в сценарии ConnectAndDisconnectEachTime). Но была небольшая разница, которая заставила нас выбрать ConnectionAlwaysOpen. Причина - поддержка транзакции. Если вы собираетесь использовать транзакции, подключение / отключение НЕ будет работать, я думаю, это очевидно почему.
ConnectionAlwaysOpen, конечно, можно улучшить, используя существующие пулы соединений или некоторый ручной отложенный кэш пулов соединений, но основная идея остается той же. С другой стороны, в веб-приложении этот подход немного сложнее реализовать и обеспечить потокобезопасность, но затраченные усилия могут стоить.