Производительность ASP.NET MVC


102

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

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


20
Поработав с WebForms с момента их появления, я никогда не вернусь назад! MVC украл мой <3 - и этот сайт отлично работает на Beta 5!
Джаррод Диксон

2
Что за откаты всех ревизий по этому вопросу ..?
Ник,

@Nick: OP откатывает все правки и удаляет все поясняющие их комментарии.
ГЕОЧЕТ,

@Rich B: Верно, он удалил около 5 моих комментариев.
Джордж Стокер,

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

Ответы:


69

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

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


13
Теперь, когда выпущен MVC, есть ли какие-нибудь обновления по выпуску результатов perf?
Крис

6
Просто проголосовал за это, потому что предыдущий результат в 5999 повторений был для меня болезненным :(
Дэмиен

2
К этому времени у вас обязательно должны быть цифры. Хотите обновить свой ответ? Или вы обнаружили, что надоедливая политика запрещает это?
tvanfosson

7
Число 42. :) В общем, наши числа, вероятно, будут бесполезны для реальных приложений, поэтому мы, как правило, их не сообщаем. Однако я знаю другие команды Microsoft, создающие крупномасштабные веб-сайты, показывающие благоприятные цифры. Другими словами, любые проблемы с производительностью с большей вероятностью будут связаны с ошибками программиста, чем с проблемами наследования в структуре. Обычно виноваты взаимодействия с базой данных и внешними службами. :)
Haacked

Правда! Пожалуйста, обновите это! Может быть, не тесты, а краткое представление, они на одном уровне или mvc немного лучше по производительности?
gideon

48

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

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


Отличный ответ Тодд (как удивительно для проповедника-разработчика прагматичный ответ). Единственное, что вы ошиблись, это то, что веб-форма необработанных реализаций действительно значительно быстрее.
Крис Марисич

42

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

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


31
Вы могли бы исправить это надоедливое большое состояние просмотра и без MVC
Андрей Ринеа

1
Просто для уточнения ViewState можно отключить на уровне страницы или в web.config
bbqchickenrobot

8
да, но в mvc это разумное значение по умолчанию, а не дизайнерское решение, которое вынуждает вас оставить все элементы управления и поставщиков, которые утверждают, что они просто работают с веб-формами, заставляя веб-формы «вести себя неправильно», удаляя их основу. Я не возражаю, что вы можете просто перекодировать эту страницу, но все приложение было лучше без viewstate.
DevelopingChris

Тогда не думаете ли вы, что это худшее из ваших решений - портировать все приложение в MVC, а не отключать состояние просмотра в web.config? и нет, viewstate не является основой. только если вы исследовали, состояние просмотра может храниться в кеше, а также в сеансах.
Simple Fellow

29

Я думаю, что многие люди, которые думают, что WebForms по своей сути медленные или ресурсоемкие, возлагают вину не на то место. В 9 случаях из 10, когда меня приглашают оптимизировать приложение веб-форм, существует слишком много мест, где авторы приложений неправильно понимают цель состояния просмотра. Я не говорю, что состояние просмотра идеальное или что-то в этом роде, но злоупотреблять им ПУТЬ слишком легко, и именно это злоупотребление вызывает раздутое поле состояния просмотра.

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

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


14

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


12

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


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

Я считаю, что за него могут проголосовать против, потому что хорошо спроектированное приложение веб-форм ASP.NET так же тестируемо, как и приложение MVC. Мой опыт разработки обоих заключается в том, что MVC заставляет вас использовать чистую модель программирования (что является одной из ее самых сильных сторон, IMO). Веб-формы позволяют делать более ленивые вещи, но все же вполне возможно иметь ту же тестируемую поверхность в веб-формах. Во всяком случае, это мое предположение.
dudemonkey

Представления Razor буквально поощряют встраивание кода в представление. Это не поддается проверке и не сулит ничего хорошего для разделения проблем. То, что MVC заставляет вас писать контроллеры, не означает, что вы не можете все это проглотить, если не знаете, что делаете. Опытный разработчик получит от WebForms такую ​​же (или более высокую) производительность, что и MVC, и будет иметь практически идентичную «тестируемую поверхность».
Ричард Хауэр

@RichardHauer, это было буквально неправдой, когда я писал это, но они улучшили это. Поскольку у WebForms, похоже, нет будущего в .NET Core, это кажется спорным вопросом.
tvanfosson 01

@tvanfosson Согласен - сейчас это спорный вопрос. Не уверен, что, по вашему мнению, не соответствует действительности, возможно, вы возражаете против моего использования слова «буквально»? В любом случае, более новые версии MVC с TagHelpers действительно помогают избавиться от привычки помещать код в макеты, что, наконец, может заставить все это работать для меня. Цените этот пост, конечно, довольно старый, но даже в то время хорошо сконструированная форма WebForms работает очень быстро, без «волшебной связи» MVC и вообще без кода, встроенного в представление.
Ричард Хауэр

7

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


Ваши пользователи могут - нет состояния просмотра.
UpTheCreek

6

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

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

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

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


3

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

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

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

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


2

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


2

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

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

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

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

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

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

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

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


2
Так это не прямой ответ на вопрос? Однако это связано, и в нем есть несколько хороших моментов. Но послушайте, это то, что я построил для своих нужд, и он мне идеально подходит. Мне также нравится делиться своими идеями, даже если мало кто понимает почему.
Джон Лейдегрен,

1
Что ж, вам не нужно менять свой голос, но вы не должны голосовать против, потому что это не «ответ». Если вы посмотрите на текст, то увидите несколько вещей, которые указывают на то, что ASP.NET MVC работает быстрее, чем WebForms, и почему это так. И это сводится к таким вещам, как отражение, объектная модель и накладные расходы ViewState для WebForms.
Джон Лейдегрен,

@John - теперь, когда MVC2 отсутствует с улучшенным связыванием модели, проверкой, строго типизированными помощниками и т. Д., Как бы вы оценили его по сравнению с вашим методом?
tvanfosson

MVC2 намного лучше, я считаю, что он в значительной степени заменил то, что я создавал в то время (с MVC1 в бета-версии). Я столкнулся с множеством проблем, связанных с тем, что я пытался построить поверх ASP.NET, не отказываясь от существующих инструментов. Достаточно сказать, что я многому научился и в конце концов запустил это в производство. Теперь я понимаю, что текущий инструментарий / фреймворк (VS / ASP.NET / C #) на самом деле не подходит для этого, и в конечном итоге, если вы хотите пойти по этому пути, вам нужно будет инвестировать в свои собственные компиляторы / проверку модели. вещи, которые работают в вашу пользу.
John Leidegren

В то время я не особо думал об ASP.NET MVC. В нем не хватало того, чего я хотел. Но мне пришлось потратить много времени на разработку, тестирование и выяснение этих вещей. Я по-прежнему считаю, что статический аспект создаваемой мной веб-инфраструктуры превосходит MVC в этом отношении, но компилятор C # неэффективен для решения этой проблемы. Вам нужен какой-то язык / компилятор, который обеспечивает большую гибкость, когда дело доходит до метапрограммирования. Мне приходилось делать много этого во время выполнения, и часто было невозможно кэшировать скомпилированные экземпляры, поэтому мне приходилось много динамически перекомпилировать.
John Leidegren

2

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

MVC4 довольно медленный, чем WebForms, есть идеи?

введите описание изображения здесь

MVC4

  • мог получить около 11 оборотов в секунду
  • rps довольно низкий для серверов с 2 или 4 процессорами

введите описание изображения здесь

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

  • может получить более 2500 об / с

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


1

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

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

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

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

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


-1

введите описание изображения здесь

Я провел небольшой нагрузочный тест 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.

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

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

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


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

Правильно и тщательно созданное приложение даже в худших технологиях творит чудеса. Жизненный цикл страницы ASP.NET определенно имеет больше полезной нагрузки по сравнению с выполнением маршрутизации и просмотра, поскольку он имеет дело с генерацией пользовательского интерфейса HTML. Маршрутизация является частью платформы ASP.NET, поэтому они существуют даже в обычных веб-формах. Я согласен с одной вещью, если вы не пишете код, стоящий за вашей производительностью, будет эквивалентен MVC. Но панель инструментов Webform настолько заманчива, что код позади становится его неотъемлемой частью. Хотя MVC вообще не позволяет мне этого делать. Мне нравится, как в бритве они отключили представление дизайна и код.
Шивпрасад Коирала 02
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.