Техника производительности в mvc3 для получения данных с помощью WCF Service

Question

Я использую asp.net mvc 3 <-> веб-сервис WCF <-> Entity Framework 4 с веб-ролью Azure.Вот проблема:

У меня есть страница индекса, где я показываю список пользователей в виде плиток.Каждый пользователь имеет ассоциацию с более чем 20-30 группами, может быть 100-х годов.но я показываю за плитку только 2 группы.Смотрите этот рисунок.

У меня есть сопоставление пользователей и групп в таблице сопоставления групп пользователей с ключом compisit userid и groupid.Теперь проблема в том, что я добавил нумерацию страниц на своей индексной странице.и требование клиента - список должен быть statefull.где, когда я запускаю список и снова для каждого пользователя, выбирающего список, так выглядит псевдо, как это

Get Users 
-> For each user
-> Add Div 
 -> For each User Group
   -> Get 2 Associated Groups to this User.
   -> Add Lable 
   -> Add Group Name

, выполняя это из-за требований, список должен быть statefull.так что для каждого пользователя, сталкивающегося с запросом к серверу, чтобы получить его группы ... это действительно занимает много времени в этой архитектуре.и передача данных между WFC к mvc 3 является медленной из-за использования EF4, я думаю.Я не могу использовать строго Jquery.javascript.Так что должно быть лучшим подходом для выполнения этого.в течение секунды.

Answer 1

(Вы не упоминаете внутреннее хранилище за вашей системой; я предполагаю, что это SQL Azure, но обсуждение ниже будет примерно таким же, несмотря ни на что.)

КогдаПри настройке производительности для такого рода приложений я обнаружил, что важно помнить две вещи:

• Минимизировать количество запросов в каждом запросе и
• Позвольте базе данных выполнить тяжелую работу

В частности, время, необходимое для выполнения одного запроса SELECT к SQL Azure, может составлять несколько сотен миллисекунд .Это говорит о том, что вы хотите делать не более 10–15 запросов на HTTP-запрос для времени отклика менее секунды.

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

Так, например,замените такие вещи, как перебор коллекции на клиенте, groupby, который вместо этого выполняет на сервере один больший запрос.

Очень полезным инструментом для профилирования вашего приложения и выявления повторных запросов является MiniProfiler, http://code.google.com/p/mvc-mini-profiler/.

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

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

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