Сокращение количества обращений между клиентом и сервером

Question

Мы разрабатываем настольное приложение в vs2008 с winforms и sql server 2008. В настоящее время мы делаем много вызовов dbase (linq to sql) при загрузке формы, поэтому это делает приложение очень медленным. Один из вариантов - загрузить все Данные, необходимые в начале загрузки приложения, сохраняются в кеше (только статические коллекции). Какие еще варианты мы должны рассмотреть? Есть ли какие-либо доступные руководящие принципы, доступные онлайн?

спасибо

Answer 1

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

• Прежде чем вы сможете с пользой что-то оптимизировать, вам нужно выяснить что замедляет его .

Используйте профилировщик. Хороший бесплатный - EQATEC . Или, если это действительно, действительно медленно, просто пошагово пройдитесь по программе. Также используйте SQL Server Profiler, чтобы узнать, что происходит с самими запросами.

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

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

• Кэшировать данные при первом использовании;

• Переключитесь на использование хранимых процедур, которые возвращают несколько наборов результатов (используя IMultipleResult - пример здесь ). Для этого требуется всего одна поездка в оба конца для нескольких наборов данных. Или, если можете, объедините результаты в один запрос / результат, если все данные, которые вы запрашиваете в данный момент отдельно, могут быть JOIN отредактированы вместе.

• Выполните ваши операции доступа к данным в фоновом потоке (то есть используя BackgroundWorker). Часто проблема заключается не в реальной скорости, а в том, что вы блокируете пользовательский интерфейс, пока он происходит.

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

• Используйте уровень абстракции, такой как WebService, который «живет» очень близко к серверу базы данных и не пострадает от большого количества циклов. Затем он может предоставить все данные, относящиеся к одному экрану / форме пользовательского интерфейса.

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

Answer 2

Джанки,

Я вижу это все время, когда впервые захожу на сайты клиентов. Большинство домашних приложений следуют подходу «Загрузить все, а затем отфильтровать» к данным. Это действительно легко и помогает вам быстро начать работу, но это неизбежно приведет к тому, что вы только что упомянули.

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

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

Кроме того, присмотритесь к своему LINQ и убедитесь, что ваша базовая модель данных оптимизирована. LINQ будет медленным, если у вас 3 огромных стола, попробуйте нормализоваться, LINQ справится лучше.

Кроме того, само LINQ должно иметь как можно больше фильтров в разделе «где».

И тогда, конечно, всегда просто ограничивается количество возвращаемых строк. Спросите себя, может ли пользователь реально посмотреть на 100 000 вещей? Удачи.

Answer 3

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

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

Будьте кропотливы с вашими методами DAL - передавайте простые типы, как будто они сами являются хранимыми процедурами. Создайте новый тип для возвращаемого типа данных строки каждого метода (возврат массива, если имеется более одной «строки»). Не используйте автоматически сгенерированные типы LINQ вне вашего DAL, вместо этого скопируйте значения в новый тип во время выбора.

Кроме того, следите за LINQ и его использованием соединений для нескольких вызовов SQL в рамках одной транзакции - вы, вероятно, используете координатор распределенных транзакций, не осознавая этого.

Answer 4

Вариант 1. Удалить LINQ to SQL. Шутки в сторону. Если вы на самом деле не знаете, что делаете, то очень легко столкнуться с кучей проблем с производительностью ... Как та, которую вы описываете.

Вариант 2. Не делайте все в загрузке формы. Вместо этого, что до ПОСЛЕ загрузки формы, затем начните выполнять эти запросы. Вам действительно нужно все, прежде чем пользователь увидит форму? Скорее всего нет.

Вариант 3. Разбейте свои формы на несколько форм. Другими словами, уменьшите сложность каждой отдельной формы до такой степени, чтобы объем данных, с которыми она имеет дело, был меньше.

Вариант 4. У вас есть много статических списков (например, штатов США), которые вы извлекаете из базы данных? Подумайте о том, чтобы поместить их в перечисления. Посмотрите на все, что имеет очень малую вероятность измениться.