Asp.net mvc СПА-приложение на стороне сервера для производительности

Question

Мы пытаемся выжать столько же производительности из нашего одностраничного приложения, написанного в asp.net mvc. Текущая раскладка:

• Asp.net стороне сервера, который MVC говорит к базе данных SQL
• SPA клиентской написанной с JS/Html5 + requireJS и KendoUI

Наши основные проблемы производительности, как представляется, что сторона СПА-вещей довольно чата с сервером для получения JS и HTML-файлов, необходимых для текущих страниц, а также для выталкивания данных из SQL DB через mvc WebApi.

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

Просто интересно, есть ли у кого-нибудь советы по методологиям для решения этой проблемы и любых библиотек для проверки?

Answer 1

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

Но в пути. Я хотел бы начать с выделения две совершенно разные вещи:

• ВОССТАНОВЛЕНИЕ, или, вернее, пакетирование статических файлов
• Аякса вызовы на конечные точки сервиса

Статическая задача файлов не является проблемой , Он не должен включать никаких архитектурных изменений, но является кривой обучения. Вы обращаетесь к нему с WebGrease (или альтернативами) и/или используя BundleConfig. Оба они являются частью готовых проектов шаблонов aspnet.

Взволнованность вызовов api очень различна. Решение об этом является рассмотрением вашего проекта &. Я бы, вероятно,

1. начало с чтением фона, например. websearch q=reduce+chattiness+of+service+design.
2. Нарисуйте несколько диаграмм последовательности разговоров, которые клиент имеет с сервером; и эскиз, когда эти разговоры запускаются.
3. Основываясь на этих картинах, начинают думать о том, как вы можете держать меньшее количество разговоров:
   • Может статике/Cacheable данные завестись в один большой хит?
   • Могут ли данные Ajax считываться, чтобы получить больший объем данных за один удар?
4. А можно ли использовать асинхронные шаблоны для обозначения того, что пользователь не видит задержки? Ajax-данные должны быть асинхронными, поэтому не должны вызывать большой удар производительности - , если только приложение не структурировано таким образом, что пользователь ждет, пока пользовательский запрос не завершится, прежде чем они смогут двигаться дальше.
   • Изучите дизайн пользовательских интерфейсов приложений-facebook, trello, которые делают свои данные в фоновом режиме, так что пользователь не ждет.

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