Я нашел несколько диких замечаний о том, что ASP.NET MVC на 30 раз быстрее, чем ASP.NET WebForms. Какая реальная разница в производительности, это было измерено и каковы преимущества производительности.
Это поможет мне рассмотреть возможность перехода от ASP.NET WebForms к ASP.NET MVC.
Мы не выполнили тип масштабируемости и перфекционные тесты, необходимые для выработки каких-либо выводов. Я думаю, что ScottGu, возможно, обсуждали потенциальные первоочередные цели. По мере продвижения к бета-версии и RTM, мы будем внутренне проводить более перфорированное тестирование. Однако я не уверен, что наша политика заключается в публикации результатов перфекционных тестов.
В любом случае, любые такие тесты действительно должны учитывать приложения реального мира...
Я думаю, что это будет трудный вопрос для окончательного ответа, так как многое будет зависеть от A) того, как вы реализуете приложение WebForms и B), как вы реализуете MVC. В своих "сырых" формах MVC, скорее всего, быстрее WebForms, но многолетние инструменты и опыт позволили создать ряд методов для создания быстрых приложений WebForms. Я был бы готов поспорить, что старший разработчик ASP.NET может создать приложение WebForms, которое будет конкурировать со скоростью любого приложения MVC или, по крайней мере, достигнет незначительной разницы.
Реальная разница - как предлагалось @tvanfosson - находится в тестируемости и чистом SoC. Если вы улучшите производительность, это ваша главная забота, я не думаю, что это отличная причина для перехода на корабль на WebForms и начать реорганизацию в MVC. По крайней мере, пока вы не попробуете доступные методы оптимизации WebForms.
Он уменьшил одну из моих страниц с полезной нагрузки 2 МБ до 200 тыс., просто исключив область просмотра и сделав ее переносимой программно для работы с представленным выходом.
Размер один, хотя обработка была одинаковой, приведет к большим улучшениям в соединениях в секунду и скорости запросов.
Я думаю, что многие люди, которые считают, что WebForms по своей сути медленны или ресурсоемкие, ставят вину в неподходящее место. 9 раз из 10, когда меня привлекают для оптимизации приложения webforms, есть слишком много мест, где авторы приложений неправильно понимают цель viewstate. Я не говорю, что viewstate идеально подходит или что-то еще, но слишком легко злоупотреблять им, и именно это злоупотребление вызывает раздутое поле viewstate.
Эта статья была недействительной, помогая мне понять многие из этих злоупотреблений. http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/truly-understanding-viewstate.aspx
Чтобы сделать достоверное сравнение MVC и WebForms, мы должны быть уверены, что оба приложения правильно используют архитектуры.
Мое тестирование показывает что-то между 2x и 7x больше req/sec на MVC, но зависит от того, как вы создаете приложение для веб-форм. С текстом "hello world" на нем, без какого-либо контроля на стороне сервера, mvc примерно на 30-50% быстрее.
У Rick Strahl есть некоторые мысли о производительности ASP.NET MVC в Что заставляет веб-формы ASP.NET.
Для меня реальное улучшение производительности в MVC - это увеличение проверяемой поверхности приложения. В WebForms было много приложений, которые трудно тестировать. С MVC количество кода, которое становится проверяемым, в основном удваивается. В основном все, что трудно проверить, - это код, который генерирует макет. Вся ваша логика бизнес-логики и доступа к данным, включая логику, которая заполняет фактические данные, используемые в представлении, теперь поддается тестированию. В то время как я ожидаю, что это будет более впечатляющим, - жизненный цикл страницы значительно упрощается и более поддается веб-программированию - даже если бы он был таким же или немного медленнее, стоит переключиться с точки зрения качества.
Я думаю, проблема в том, что независимо от того, насколько быстрее ASP.Net MVC, чем старые веб-формы, это не будет иметь никакого значения, потому что большая часть времени взята в базе данных. В большинстве случаев вы, веб-серверы, будете сидеть при 0-10% использования ЦП, просто ожидая вашего сервера базы данных. Если вы не получаете чрезвычайно большое количество хитов на своем веб-сайте, а ваша база данных очень быстро, вы, вероятно, не заметите большой разницы.
Единственные конкретные числа, которые я могу найти в раннем ASP.NET MVC-разработке, находятся на этом форуме-потоке:
http://forums.asp.net/p/1231621/2224136.aspx
Сам Роб Коннери несколько подтверждает утверждение, что ScottGu утверждает, что ASP.NET MVC может обслуживать 8000 запросов в секунду.
Возможно, Джефф и его команда могут дать какой-то намек на их разработку этого сайта.
Вопреки принятому мнению, оптимизированное использование веб-форм полностью убивает MVC с точки зрения производительности. Webforms был оптимизирован с гипер-оптимизацией для задачи обслуживания html намного дольше, чем MVC.
Показатели доступны на http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=db
Каждое единственное сравнение mvc находится в нижнем среднем/нижнем верхнем ранжировании списка, а оптимизированные места использования веб-форм - в верхнем/верхнем нижнем ранжировании.
Анекдотическая, но очень серьезная проверка этих метрик, www.microsoft.com обслуживается веб-формами, а не MVC. Кто-нибудь здесь считает, что они не выбрали бы MVC, если бы это было эмпирически быстрее?
На самом деле нет способа ответить на этот вопрос. MVC по умолчанию использует механизм просмотра Web Forms и может быть настроен на использование любого количества настраиваемых механизмов просмотра, поэтому, если вы хотите сравнить производительность, вам нужно быть более конкретным.
Я начал работать в 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-адресам. Это похоже на то, что у вас были статически типизированные ресурсы, а также статически типизированные объекты. Статически типизированное веб-приложение? Это то, что я хочу!
Я бы попросил больше людей попробовать это.
Проекты, созданные с помощью визуальной студии. Один из них - шаблон mvc4, другой - WebForm (tranditional). И при выполнении теста нагрузки с помощью WCAT это результат,
может превышать 2500 рпс
был обнаружен убийца производительности, который является ошибкой MVC Bata или RC. И производительность будет улучшена, как только я удалю Bundles вещи. Теперь последняя версия исправила это.
Производительность зависит от того, что вы делаете... Обычно MVC быстрее, чем asp.net, главным образом потому, что ViewState отсутствует и потому что MVC работает больше с Callback, чем Postback по умолчанию.
Если вы оптимизируете свою страницу веб-формы, вы можете иметь такую же производительность, как MVC, но это будет очень много работы.
Кроме того, у них много nugets для MVC (а также для Webform), чтобы помочь вам улучшить производительность сайта, например, объединить и минимизировать ваши css и javascripts, группировать ваши изображения и использовать их как спрайт и т.д.
Производительность веб-сайта сильно зависит от вашей архитектуры. Чистый, с хорошим разделением внимания, принесет вам более чистый код и лучшее представление о том, как повысить производительность.
Вы можете посмотреть этот шаблон " Neos-SDI MVC Template", который создаст для вас чистую архитектуру с большим количеством улучшений производительности по умолчанию (проверьте MvcTemplate сайт.)
Я провел небольшой эксперимент по тестированию нагрузки VSTS с некоторым базовым кодом и нашел время отклика ASP.NET MVC в два раза быстрее по сравнению с ASP.NET Webforms. Выше приведен график с графиком.
Вы можете прочитать этот экспериментальный тест нагрузки подробно из этой статьи CP http://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari
Тест проводился с использованием нижеприведенных спецификаций с использованием программного обеспечения для тестирования нагрузки VSTS и telerik: -
Пользователь загружает 25 пользователей.
Продолжительность теста составила 10 минут.
Конфигурация машины DELL 8 GB Ram, Core i3
Проект был размещен в IIS 8.
Проект был создан с использованием MVC 5.
Предполагается подключение к сети. Таким образом, этот тест пока не учитывает сетевое отставание.
Браузер в тесте выбрал Chrome и Internet Explorer.
Множественное чтение, которое принимается во время теста, для средних неизвестных событий. 7 показаний, в которых они сделаны, и все чтения публикуются в этой статье в виде 1, 2 и т.д.