Производительность ASP.NET MVC
Я нашел несколько диких замечаний о том, что ASP.NET MVC в 30 раз быстрее, чем ASP.NET WebForms. Какая реальная разница в производительности, была ли она измерена и каковы преимущества производительности.
Это поможет мне подумать о переходе от ASP.NET WebForms к ASP.NET MVC.
Что за откаты всех ревизий по этому вопросу ..?
@Nick: OP откатывает все правки и удаляет все поясняющие их комментарии.
@Rich B: Верно, он удалил около 5 моих комментариев.
Требуется обновление сейчас, когда мы приближаемся к выпуску MVC3.
Ответы 14
Единственные конкретные числа, которые я могу найти, которые относятся к ранней разработке ASP.NET MVC, находятся в этой ветке форума:
http://forums.asp.net/p/1231621/2224136.aspx
Сам Роб Коннери отчасти подтверждает утверждение, что ScottGu утверждает, что ASP.NET MVC может обслуживать 8000 запросов в секунду.
Возможно, Джефф и его команда могут дать какой-то намек на их разработку этого сайта.
Мы не проводили тесты масштабируемости и производительности, необходимые для каких-либо выводов. Я думаю, что ScottGu, возможно, обсуждал потенциальные цели производительности. По мере того, как мы приближаемся к бета-версии и окончательной первоначальной версии, мы будем проводить больше тестов производительности. Однако я не уверен, какова наша политика в отношении публикации результатов тестов производительности.
В любом случае, любые такие тесты действительно должны учитывать реальные приложения ...
Теперь, когда выпущен MVC, есть ли какие-нибудь обновления по выпуску результатов перфоманса?
Просто проголосовал за это, потому что предыдущий результат в 5999 повторений болел мне в глаза :(
К этому времени у вас обязательно должны быть числа. Хотите обновить свой ответ? Или вы обнаружили, что надоедливая политика запрещает это?
Число 42. :) В общем, наши числа, вероятно, будут бесполезны для реальных приложений, поэтому мы, как правило, их не сообщаем. Однако я знаю, что другие команды Microsoft создают крупномасштабные веб-сайты, показывающие благоприятные цифры. Другими словами, любые проблемы с производительностью, скорее всего, будут из-за ошибок программиста, чем из-за проблем с наследием во фреймворке. Обычно виноваты взаимодействия с базой данных и внешними службами. :)
Истинный! Пожалуйста, обновите это! Может быть, не тесты, а краткое представление, они на одном уровне или mvc немного лучше по производительности?
Он уменьшил одну из моих страниц с 2 МБ до 200 КБ, просто исключив состояние просмотра и сделав программно сносной работу с представленным выводом.
Один только размер, даже несмотря на то, что обработка была такой же, значительно улучшит количество подключений в секунду и скорость запросов.
вы могли бы исправить это надоедливое большое состояние просмотра и без MVC
Для уточнения ViewState можно отключить на уровне страницы или в web.config.
да, но в mvc это разумное значение по умолчанию, а не дизайнерское решение, которое заставляет вас оставить все элементы управления и поставщиков, которые утверждают, что просто работают с веб-формами, заставляя веб-формы «вести себя неправильно», удаляя их основу. Я не возражаю, что вы можете просто перекодировать эту страницу, но все приложение было лучше без viewstate.
тогда не думаете ли вы, что это худшее ваше решение - переносить все приложение в MVC, а не отключать состояние просмотра в web.config? и нет, viewstate не является основой. только если вы исследовали, состояние просмотра может храниться в кеше, а также в сеансах.
На самом деле нет никакого способа ответить на это. MVC по умолчанию использует механизм представления веб-форм и может быть настроен для использования любого количества настраиваемых механизмов представления, поэтому, если вы хотите сравнить производительность, вам придется быть более конкретным.
Мое тестирование показывает от 2 до 7 раз больше запросов в секунду для MVC, но это зависит от того, как вы создаете приложение веб-форм. С текстом «привет, мир», без каких-либо элементов управления на стороне сервера, mvc работает примерно на 30-50% быстрее.
Для меня реальное улучшение «производительности» в MVC - это увеличение тестируемой поверхности приложения. С WebForms было много приложений, которые было трудно протестировать. С MVC количество кода, который становится тестируемым, в основном удваивается. По сути, все, что нелегко проверить, - это код, который генерирует макет. Вся ваша бизнес-логика и логика доступа к данным, включая логику, которая заполняет фактические данные, используемые в представлении, теперь поддаются тестированию. Хотя я ожидаю, что он также будет более производительным - жизненный цикл страницы значительно упрощен и больше поддается веб-программированию - даже если бы он был таким же или немного медленнее, с точки зрения качества стоило бы переключиться на него.
Мне действительно хотелось бы знать, почему кто-то проголосовал против этого ответа.
Я считаю, что за него могут проголосовать против, потому что хорошо разработанное приложение веб-форм ASP.NET так же тестируемо, как и приложение MVC. Мой опыт разработки обоих заключается в том, что MVC заставляет вас использовать чистую модель программирования (что является одной из ее самых сильных сторон, IMO). Веб-формы позволяют делать более ленивые вещи, но все же вполне возможно иметь ту же тестируемую поверхность в веб-формах. Во всяком случае, это мое предположение.
Представления Razor буквально поощряют встраивание кода в представление. Это не поддается проверке и не сулит ничего хорошего для разделения проблем. То, что MVC заставляет вас писать контроллеры, не означает, что вы не можете избавиться от всего этого, если не знаете, что делаете. Опытный разработчик получит от WebForms такую же (или более высокую) производительность, что и MVC, и будет иметь практически идентичную «тестируемую поверхность».
@RichardHauer, это было буквально неправдой, когда я писал это, но они улучшили это. Поскольку у WebForms нет будущего в .NET Core, это кажется спорным вопросом.
@tvanfosson Согласен - сейчас это спорный вопрос. Не уверен, что, по вашему мнению, не соответствует действительности, возможно, вы возражаете против моего использования слова «буквально»? В любом случае, более новые версии MVC с TagHelpers действительно помогают избавиться от привычки помещать код в макеты, что, наконец, может заставить все это работать для меня. Оцените, что этот пост, конечно, довольно старый, но даже в то время хорошо сконструированная форма WebForms работает очень быстро, без «волшебной связи» MVC и вообще без кода, встроенного в представление.
@RichardHauer, когда я писал это, изменений в WebForms, позволяющих внедрять зависимости и повышать тестируемость, не существовало. Код позади был изначально непроверен. Вы можете переместить значительные суммы в библиотеки для тестирования, но всегда будет какой-то код, который вы не сможете протестировать - например, привязка данных.
Я думаю, что на этот вопрос будет сложно дать окончательный ответ, так как многое будет зависеть от А), как вы реализуете приложение WebForms, и Б), как вы реализуете приложение MVC. В «сырых» формах MVC, вероятно, быстрее, чем WebForms, но годы и годы инструментов и опыта позволили создать ряд методов для создания быстрых приложений WebForms. Я готов поспорить, что старший разработчик ASP.NET сможет создать приложение WebForms, которое будет конкурировать по скорости с любым приложением MVC - или, по крайней мере, добиться незначительной разницы.
Настоящая разница - как предложил @tvanfosson - в тестируемости и чистоте SoC. Если повышение производительности является вашей главной заботой, я не думаю, что это отличная причина отказаться от WebForms и начать перестраивать в MVC. По крайней мере, пока вы не попробуете доступные методы оптимизации WebForms.
Отличный ответ, Тодд (как удивительно для проповедника-разработчика прагматичный ответ). Единственное, что вы ошиблись, это то, что веб-форма необработанных реализаций действительно значительно быстрее.
Я думаю, что многие люди, которые думают, что WebForms по своей сути медленные или ресурсоемкие, возлагают вину не на то место. В 9 случаях из 10, когда меня приглашают оптимизировать приложение веб-форм, существует слишком много мест, где авторы приложений неправильно понимают цель состояния просмотра. Я не говорю, что состояние просмотра идеально или что-то в этом роде, но злоупотреблять им ПУТЬ слишком легко, и именно это злоупотребление вызывает раздутое поле состояния просмотра.
Эта статья оказалась бесценной, поскольку помогла мне разобраться во многих из этих злоупотреблений. https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate
Чтобы провести корректное сравнение между MVC и WebForms, мы должны быть уверены, что оба приложения правильно используют архитектуры.
Я начал работать в 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-адреса не работают. Это как если бы у вас были статически типизированные ресурсы, а также статически типизированные объекты. Статически типизированное веб-приложение? Это то, что я хочу!
Я бы посоветовал большему количеству людей попробовать это.
Так это не прямой ответ на вопрос? Однако это связано, и в нем есть несколько хороших моментов. Но послушайте, это то, что я построил для своих нужд, и он мне идеально подходит. Мне также нравится делиться своими идеями, даже если мало кто понимает почему.
Что ж, вам не нужно менять свой голос, но вы не должны голосовать против, потому что это не «ответ». Если вы посмотрите на текст, то увидите несколько вещей, которые указывают на то, что ASP.NET MVC быстрее, чем WebForms, и почему это так. И это сводится к таким вещам, как отражение, объектная модель и служебные данные ViewState для WebForms.
@John - теперь, когда отсутствует MVC2 с улучшенным связыванием модели, проверкой, строго типизированными помощниками и т. д., Как бы вы оценили его по сравнению с вашим методом?
MVC2 намного лучше, я считаю, что он в значительной степени заменил то, что я создавал в то время (с MVC1 в бета-версии). Я столкнулся с большим количеством проблем, связанных с тем, что я пытался построить поверх ASP.NET, не отказываясь от существующих инструментов. Достаточно сказать, что я многому научился и в конце концов запустил это в производство. Теперь я понимаю, что текущий инструментарий / фреймворк (VS / ASP.NET / C#) на самом деле не подходит для этого, и в конечном итоге, если вы хотите пойти по этому пути, вам нужно будет инвестировать в свои собственные компиляторы / проверку модели. вещи, чтобы некоторые вещи работали в вашу пользу.
В то время я мало думал об ASP.NET MVC. В нем не хватало того, чего я знал, что хочу. Но мне пришлось потратить много времени на разработку, тестирование и выяснение этих вещей. Я по-прежнему считаю, что статический аспект создаваемой мной веб-инфраструктуры превосходит MVC в этом отношении, но компилятор C# неэффективен для решения этой проблемы. Вам нужен какой-то язык / компилятор, который обеспечивает большую гибкость, когда дело доходит до метапрограммирования. Мне приходилось делать много этого во время выполнения, и часто было невозможно кэшировать скомпилированные экземпляры, поэтому мне приходилось много динамически перекомпилировать.
В итоге я создал множество инструментов для генерации кода, чтобы он хорошо работал с базой данных. Я использовал Linq-to-Sql, и инструменты, поставляемые с Linq-to-Sql, были в значительной степени бесполезны. Я использовал простые соглашения об именах для моделирования перечислений типов, сущностей и ассоциаций, а затем сопоставил это с помощью метамодели атрибутов Linq-to-Sql. Хотя в итоге у меня получилась очень элегантная декларативная модель. В котором такие вещи, как привязка данных, проверка и CRUD, в значительной степени выполнялись автоматически.
Я получил огромное удовольствие и прошел через большую боль, чтобы довести это до конца. Хотя в итоге я понял, что эта статически типизированная сеть требует, чтобы вы продвигали работу в генерацию кода и динамическую компиляцию, чтобы вы могли продвигаться вперед декларативно. Я считаю, что эта тенденция проявляется во все большем количестве мест.
похоже, у вас было много времени, чтобы заняться этим делом. мой менеджер просто обсуждает, ставит задачи, которые нужно выполнить в установленный промежуток времени. нет даже времени на то, чтобы много исследовать.
@SimpleFellow Я нашел время. У менеджера должно быть серьезное экономическое обоснование, чтобы иметь возможность уделять время работе над подобными вещами. Если это действительно приведет к преимуществу над конкурентами. Иногда общение - самая сложная часть, но если вы можете сесть вместе и поговорить о том, почему это важно, будьте готовы услышать другую сторону истории. У каждого часто есть очень веские причины, по которым нужно что-то делать. Если все не удается, ищите работу в другом месте, но только в том случае, если вы абсолютно уверены, что все испробовали.
Я думаю, проблема здесь в том, что независимо от того, насколько ASP.Net MVC быстрее, чем старые веб-формы, это не будет иметь значения, потому что большую часть времени занимает база данных. Большую часть времени ваши веб-серверы будут сидеть с 0-10% загрузкой ЦП, просто ожидая своего сервера базы данных. Если вы не получите очень большое количество посещений на своем веб-сайте и ваша база данных не будет чрезвычайно быстрой, вы, вероятно, не заметите большой разницы.
Ваши пользователи могут - нет состояния просмотра.
Проекты, созданные с помощью visual studio. Один - шаблон mvc4, другой - WebForm (традиционный). И когда делаем нагрузочный тест с WCAT, вот результат,
MVC4 довольно медленный, чем WebForms, есть идеи?
MVC4
- мог получить около 11 оборотов в секунду
- rps довольно низкий как для серверов с 2 процессорами, так и с 4 процессорами
Веб-формы (aspx)
может получить более 2500 оборотов в секунду
Убийца производительности был обнаружен, что это ошибка MVC Bata или RC. И производительность будет улучшена, когда я удалю вещи Bundles. Теперь последняя версия исправила это.
Производительность зависит от того, что вы делаете ... Обычно MVC быстрее, чем asp.net, в основном потому, что Viewstate отсутствует и потому что MVC по умолчанию больше работает с обратным вызовом, чем с Postback.
Если вы оптимизируете свою страницу веб-формы, вы можете иметь ту же производительность, что и MVC, но это потребует много работы.
Кроме того, у них есть множество nugets для MVC (а также для Webform), которые помогут вам улучшить производительность веб-сайта, например, объединить и минимизировать ваши css и javascripts, сгруппировать ваши изображения и использовать их в качестве спрайтов и т. д.
Производительность веб-сайта во многом зависит от вашей архитектуры. Чистый код с хорошим разделением задач принесет вам более чистый код и лучшее представление о том, как улучшить производительность.
Вы можете взглянуть на этот шаблон «Шаблон Neos-SDI MVC», который по умолчанию создаст для вас чистую архитектуру с множеством улучшений производительности (проверьте веб-сайт MvcTemplate).
Вопреки общепринятому мнению, использование оптимизированных веб-форм полностью убивает MVC с точки зрения сырой производительности. Webforms был гипероптимизирован для обслуживания html намного дольше, чем это сделал MVC.
Метрики доступны на http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=db
Каждое отдельное сравнение mvc находится в нижнем-среднем / нижнем-верхнем рейтинге списка, в то время как использование оптимизированных веб-форм занимает верхнее-среднее / верхнее-нижнее рейтинги.
Неофициальная, но очень серьезная проверка этих показателей, www.microsoft.com обслуживается веб-формами, а не MVC. Кто-нибудь из присутствующих считает, что они не выбрали бы MVC, если бы он был эмпирически быстрее?
Я провел небольшой тестовый эксперимент VSTS с некоторым базовым кодом и обнаружил, что время отклика ASP.NET MVC в два раза быстрее по сравнению с веб-формами ASP.NET. Вверху прилагается график с графиком.
Подробнее об этом нагрузочном тестовом эксперименте можно прочитать в статье 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 вообще не позволяет мне этого делать. Мне нравится, как в бритве они отключили представление дизайна и код.
Поработав с WebForms с момента их появления, я никогда не вернусь назад! MVC украл мой <3 - и этот сайт отлично работает на Beta 5!