Как узнать, когда существует слишком много SQL-соединений? - PullRequest
Новая
       10

Как узнать, когда существует слишком много SQL-соединений?

4 голосов
/ 28 марта 2009

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

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

Ответы [ 3 ]

2 голосов
/ 28 марта 2009

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

1 голос
/ 28 марта 2009

нагрузочный тест.

Напишите небольшое многопоточное консольное приложение, которое открывает множество соединений, которые вы хотели бы установить, и проверьте сами. Попробуйте определить, сколько запросов будет выполнять каждое соединение, и убедитесь, что вы включили его в свой тест. Когда вы запускаете тест, откройте монитор производительности на сервере БД и наблюдайте за циклами ЦП. Выясните, каков ваш эталон для циклов ЦП, и когда вы прошли через это, у вас есть ответ. Убедитесь, что сервер БД, который вы тестируете, настроен точно так же, как сервер, который вы собираетесь запустить в работе.

Не ждите, пока у вас возникнут проблемы. Ваши клиенты не будут довольны этим.

1 голос
/ 28 марта 2009

Вы используете ASP.NET? .NET повторно использует соединения SQL с пулом соединений . Реальный вопрос, сколько подключений открыто напрямую: 

select COUNT(*) 
from master.dbo.sysprocesses p
join master.dbo.sysdatabases d on p.dbID = d.dbID
where d.name = '<database>'

Вы можете назвать это утверждение из своего DAL, но я думаю, что это не обязательно. Зачем? У меня есть опыт работы с MSSQL 2000. Он стабилен с гончими открытых соединений.

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

С statefull (я имею в виду, что есть постоянное открытое соединение), услуги трудно планировать, и я думаю, что вы должны пересмотреть свой дизайн.

...