Один большой вызов против нескольких меньших вызовов TSQL

Question

У меня есть вопрос производительности ADO.NET/TSQL. У нас есть два варианта в нашем приложении:

1) Один большой вызов базы данных с несколькими наборами результатов, затем в коде пошагово просматривайте каждый набор результатов и заполняйте мои объекты. Это приводит к одной поездке в базу данных.

2) Несколько небольших вызовов базы данных.

В Варианте 2 намного больше повторного использования кода, что является преимуществом этой опции. Но я хотел бы получить некоторую информацию о стоимости производительности. Являются ли две небольшие поездки в два раза медленнее, чем одна большая передача в базу данных, или это всего лишь небольшая, скажем, потеря производительности на 10%? Мы используем C # 3.5 и Sql Server 2008 с хранимыми процедурами и ADO.NET.

Answer 1

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

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

Answer 2

Я сам борюсь с этой проблемой. И у меня пока нет ответа, но у меня есть некоторые мысли.

Изучив ответы, данные другими к этому моменту, есть еще третий вариант.

В моем заявлении на сервер поступает около десяти или двенадцати вызовов для получения нужных мне данных. Некоторые из полей данных - это поля varchar max и varbinary max (изображения, большие документы, видео и звуковые файлы). Все мои звонки являются синхронными - то есть, пока запрашиваются данные, у пользователя (и программы на стороне клиента) нет другого выбора, кроме как ждать. Он может захотеть только прочитать или просмотреть данные, которые имеют смысл только тогда, когда они ВСЕ есть, а не только частично. Я полагаю, что процесс медленнее, и я нахожусь в процессе разработки альтернативного подхода, основанного на асинхронных обращениях к серверу из библиотеки DLL, которая вызывает события для клиента, чтобы объявить о ходе работы клиенту. Клиент запрограммирован для обработки событий DLL и установки переменной на стороне клиента, указывающей, что вызовы chich были завершены. Затем клиентская программа может делать то, что должна, для подготовки данных, полученных при вызове # 1, в то время как DLL работает асинхронно, чтобы получить данные вызова # 2. Когда клиент готов обработать данные вызова № 2, он должен проверить состояние и дождаться продолжения, если это необходимо (я надеюсь, что это будет короткое ожидание или его вообще не будет). Таким образом, как серверное, так и клиентское программное обеспечение работают более эффективно.

Answer 3

Звучит немного очевидно, но отправляйте только то, что вам нужно, за один звонок.

Например, у нас есть сохраненный метод getStuff для презентации. Процедура «updateStuff» вызывает метод «getStuff», а клиентский метод-оболочка для «updateStuff» ожидает тип «Thing». Итак, одно путешествие туда и обратно.

Чатти-серверы - это то, что вы предотвращаете с минимальными усилиями. Затем вы можете настроить БД или клиентский код по мере необходимости ... но позже будет сложно выделить обходные пути независимо от того, насколько быстро работает ваш код. В крайнем случае, что если ваш веб-сервер находится в другой стране, чем ваш сервер БД ...?

Редактировать: интересно отметить, что парни из SQL (HLGEM, astander, я) говорят «одна поездка», а парни из клиентов говорят «несколько, повторное использование кода» ...

Answer 4

Как разработчик ADO.Net, ваша задача - сделать код максимально точным, понятным и поддерживаемым. Это означает, что вы должны отделить свои проблемы.

Задача технологии соединения с SQL Server - сделать это быстро.

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

Answer 5

Не оптимизировать для повышения производительности, пока в этом не возникнет необходимость. Это означает, что вы должны проанализировать ваши ожидаемые модели использования и определить, какой будет типичная частота использования для этого процесса и какая задержка пользовательского интерфейса будет обусловлена ​​существующим проектом. Если пользователь получит обратную связь от приложения менее чем за несколько (2-3) секунд, и загрузка приложения из этого процесса не является чрезмерной нагрузкой на серверную емкость, не беспокойтесь об этом. Если пользователь ожидает недопустимое количество времени для ответа (субъективно, но однозначно измеримо) или если сервер перегружен, то пора начинать оптимизацию. И затем, какие методы оптимизации будут наиболее целесообразными или наиболее эффективными с точки зрения затрат, зависит от того, что говорит вам анализ проблемы.

Итак, пока сосредоточимся на ремонтопригодности. Это означает, что в вашем случае повторное использование кода

Answer 6

Мне лично нравится второй вариант по указанной вами причине: повторное использование кода

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

Answer 7

Лично я бы пошел с 1 большей поездкой туда и обратно.

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

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

Answer 8

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

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