Вопрос

Я нашел несколько диких замечаний о том, что ASP.NET MVC в 30 раз быстрее, чем ASP.NET WebForms.В чем реальная разница в производительности, было ли это измерено и каковы преимущества в производительности.

Это должно помочь мне рассмотреть возможность перехода с ASP.NET WebForms на ASP.NET MVC.

Это было полезно?

Решение

Мы не проводили тестов масштабируемости и производительности, необходимых для того, чтобы прийти к каким-либо выводам.Я думаю, что Скоттгу, возможно, обсуждал потенциальные цели perf.По мере продвижения к бета-тестированию и RTM мы будем проводить больше внутреннего тестирования производительности.Однако я не уверен, какова наша политика в отношении публикации результатов тестов perf.

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

Другие советы

Я думаю, что на этот вопрос будет трудно дать окончательный ответ, поскольку очень многое будет зависеть от А) как вы реализуете приложение WebForms и Б) как вы реализуете приложение MVC.В своих "необработанных" формах MVC, вероятно, быстрее WebForms, но годы инструментов и опыта позволили разработать ряд методов для создания быстрых приложений WebForms.Я был бы готов поспорить, что старший разработчик ASP.NET мог бы создать приложение WebForms, которое конкурирует по скорости с любым приложением MVC - или, по крайней мере, добиться незначительной разницы.

Реальная разница- как предложил @tvanfosson- находится в тестируемом состоянии и чистом SoC.Если повышение производительности является вашей главной заботой, я не думаю, что это отличная причина переходить на WebForms и начинать перестройку в MVC.По крайней мере, до тех пор, пока вы не опробуете доступные методы оптимизации веб-форм.

Это уменьшило полезную нагрузку одной из моих страниц с 2 МБ до 200 Кб, просто устранив viewstate и сделав программно приемлемой работу с представленными результатами.

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

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

Эта статья оказала неоценимую помощь в понимании многих из этих злоупотреблений. https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate

Чтобы провести корректное сравнение между MVC и WebForms, мы должны быть уверены, что оба приложения правильно используют архитектуры.

Мое тестирование показывает что-то между 2 и 7 раз больше производительности в секунду на MVC, но это зависит от того, как вы создаете свое приложение webforms.С простым текстом "hello world", без какого-либо управления на стороне сервера, mvc работает примерно на 30-50% быстрее.

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

Я думаю, проблема здесь в том, что независимо от того, насколько быстрее ASP.Net MVC, чем старые веб-формы, это не будет иметь значения, потому что большую часть времени занимает работа с базой данных.Большую часть времени ваши веб-серверы будут работать с загрузкой процессора 0-10%, просто ожидая вашего сервера базы данных.Если вы не получаете чрезвычайно большое количество просмотров на своем веб-сайте, а ваша база данных работает чрезвычайно быстро, вы, вероятно, не заметите большой разницы.

Единственные конкретные цифры, которые я могу найти, относятся к ранней версии ASP.NET MVC-разработка находится в этой теме форума:

http://forums.asp.net/p/1231621/2224136.aspx

Сам Роб Коннери отчасти подтверждает заявление Скотта Гю о том, что ASP.NET MVC может обслуживать 8000 запросов в секунду.

Возможно, Джефф и его команда смогут дать какой-то намек на разработку этого сайта.

Вопреки общепринятому мнению, оптимизированное использование webforms полностью убивает MVC с точки зрения исходной производительности.Webforms был гипероптимизирован для выполнения задачи обслуживания html гораздо дольше, чем MVC.

Показатели доступны на http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=db

Каждое отдельное сравнение mvc находится в нижне-среднем / нижне-верхнем рейтинге списка, в то время как оптимизированное использование webforms находится в верхне-среднем / верхне-нижнем рейтинге.

Анекдотическая, но очень серьезная проверка этих показателей, www.microsoft.com обслуживается webforms, а не MVC.Кто-нибудь здесь верит, что они бы не выбрали MVC, если бы это было эмпирически быстрее?

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

Я начал работать в MVC около года назад, я был вдохновлен, но не впечатлен.

Я ненавижу состояние просмотра и рассматриваю его как корень всего зла с точки зрения ASP.NET.Вот почему я просто не использую его, и, если быть предельно честным, зачем это вам?

Я взял в основном концепцию фреймворка ASP.NET MVC и построил ее по-своему.Однако я изменил пару вещей.Я создал свой код переноса контроллера или код маршрутизации URL-адресов для динамической перекомпиляции.

Теперь я бы зашел так далеко, что сказал, что ASP.NET Приложения MVC будут работать быстрее в зависимости от того, как вы их используете.Если вы полностью откажетесь от WebForms, вы будете работать быстрее, потому что ASP.NET жизненный цикл и объектная модель огромны.

Когда вы пишете, вы создаете экземпляр армии...нет, подождите, легион объектов, которые будут участвовать в рендеринге вашего представления.Это будет медленнее, чем если бы вы хотели выразить минимальное количество поведения на самой странице ASPX.(Меня не волнует абстракция view engine, потому что поддержка ASPX-страниц в Visual Studio приличная, но я полностью отказался от WebForms как концепции и в принципе от любых ASP.NET фреймворк из-за раздувания кода или невозможности изменить то, что подключает мое приложение).

Я нашел способы полагаться на динамическую перекомпиляцию (System.Reflection.Emit) для создания объектов специального назначения и кода всякий раз, когда это необходимо.Выполнение этого кода происходит быстрее, чем reflection, но изначально он создается с помощью службы reflection.Это придало моему фреймворку со вкусом MVC отличную производительность, но также и очень статичную типизацию.Я не использую строки и коллекции пар имя / значение.Вместо этого мои пользовательские службы компилятора перезаписывают сообщение формы в действие контроллера, которому передается ссылочный тип.За сценой происходит много чего, но этот код быстр, намного быстрее, чем WebForms или MVC Framework.

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

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

Проекты, созданные с помощью Visual Studio.Один из них - шаблон mvc4, другой - WebForm (стандартный).И когда выполняете нагрузочный тест с помощью WCAT, это результат,

MVC4 работает довольно медленно, чем WebForms, есть идеи?

enter image description here

MVC4

  • может получить около 11 rps
  • rps довольно низок как на 2-процессорном, так и на 4-процессорном сервере

enter image description here

Веб-формы (aspx)

  • может превысить 2500 оборотов в секунду

  • было обнаружено, что причиной снижения производительности является ошибка MVC Bata или RC.И производительность будет улучшена, как только я удалю эти вещи.Теперь в последней версии это исправлено.

Производительность зависит от того, что вы делаете...Обычно MVC работает быстрее, чем asp.net в основном потому, что Viewstate отсутствует и потому, что MVC по умолчанию больше работает с обратным вызовом, чем с обратной отправкой.

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

Кроме того, существует множество nugets для MVC (а также для Webform), которые помогут вам повысить производительность веб-сайта, например, объединить и минимизировать ваши css и javascripts, сгруппировать ваши изображения и использовать их в качестве спрайта и так далее.

Производительность веб-сайта во многом зависит от вашей архитектуры.Чистый код с хорошим разделением проблем даст вам более чистый код и лучшее представление о том, как повысить производительность.

Вы можете взглянуть на этот шаблон "Шаблон Neos-SDI MVC" который создаст для вас чистую архитектуру с большим количеством улучшений производительности по умолчанию (проверьте Шаблон MvcTemplate веб-сайт).

enter image description here

Я провел небольшой эксперимент с нагрузочным тестированием VSTS с некоторым базовым кодом и обнаружил, что ASP.NET Время отклика MVC в два раза быстрее по сравнению с ASP.NET Webforms.Выше приведен прилагаемый график с графиком.

Вы можете подробно ознакомиться с этим экспериментом нагрузочного тестирования в этой статье CP https://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari

Тестирование проводилось с использованием приведенных ниже спецификаций с использованием программного обеспечения для нагрузочного тестирования VSTS и telerik:-

Пользователь загружает 25 пользователей.

Продолжительность выполнения теста составила 10 минут.

Конфигурация компьютера DELL 8 ГБ оперативной памяти, Core i3

Проект был размещен в IIS 8.

Проект был создан с использованием MVC 5.

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

Браузер в тесте выбрал Chrome и Internet Explorer.

Многократное считывание данных, выполняемое во время теста для усреднения неизвестных событий.7 показаний, где они были взяты, и все показания опубликованы в этой статье как показания 1, 2 и так далее.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top