Какую производительность я теряю, увеличивая количество обращений к SQL Server?

Question

У меня есть веб-приложение, в котором веб-сервер и база данных SQL Server 2008 находятся в разных блоках в одной ферме серверов.

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

---

Дополнительная справочная информация:

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

Мне нужно вставить часть функциональности в мой клиентский код (в этом смысле клиентский код - это веб-сервер ASP, который вызывает сервер базы данных)это вызывает компонент DLL.Однако хранимая процедура обновляет набор записей и возвращает обновленные данные в том же вызове, и мой код в идеале должен вызываться после , вызывается логика принятия решения и операторы обновления, но до данные возвращаются клиенту.

Чтобы эта функция работала, мне, вероятно, придется разделить существующий хранимый процесс по крайней мере на две части: одну хранимую процедуру, которая обновляет базу данных, и другую.который получает данные из базы данных.Затем я вставил бы свой новый код между этими сохраненными вызовами процедур.

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

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

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

Answer 1

В общем, как правило, вы должны совершать как минимум два обращения к SQL-серверу.

«попадание» на сервер очень дорого, на самом деле дороже разделить одну и ту же операцию на 3 части, чем выполнить 1 попадание и все остальное на сервере.

относительно обслуживания, вы можете вызвать 1 сохраненный процесс от клиента, при этом этот вызов вызовет еще 2 процесса.

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

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

Answer 2

Хорошо настроенный SQL Server на хорошем оборудовании может обрабатывать многие тысячи транзакций в секунду.

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

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

Учитывая, что ландшафт плана запроса изменится, вы также должны быть готовы обновить свои индексы, возможно, создав различные индексы покрытия.

Answer 3

По сути, этот вопрос тесно связан с жесткой или слабой связью.

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

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

В любом случае, я бы проверил его и отрегулировал оттуда.

Answer 4

Это повлияет на это. Мы используем сервер Weblogic, где вся бизнес-логика в AppServer подключена к базе данных DB / 2. В нашем проекте мы в основном используем объектные компоненты, и для большинства вызовов бизнес-сервисов совершаем несколько поездок в БД без видимых побочных эффектов. (При необходимости мы настраиваем некоторые запросы на несколько таблиц).

Это действительно зависит от вашего приложения. Вам нужно будет тестировать.