Я нашел несколько диких замечаний о том, что ASP.NET MVC в 30 раз быстрее, чем ASP.NET WebForms. Какая реальная разница в производительности, была ли она измерена и каковы преимущества производительности.
Это поможет мне рассмотреть вопрос о переходе от ASP.NET WebForms к ASP.NET MVC.
Ответы:
Мы не проводили тесты на масштабируемость и производительность, необходимые для каких-либо выводов. Я думаю, что ScottGu, возможно, обсуждал потенциальные цели производительности. По мере продвижения к бета-версии и окончательной первоначальной версии мы будем проводить больше тестов производительности. Однако я не уверен, какова наша политика в отношении публикации результатов тестов производительности.
В любом случае, любые такие тесты действительно должны учитывать реальные приложения ...
Я думаю, что на этот вопрос будет сложно дать окончательный ответ, так как многое будет зависеть от A) как вы реализуете приложение WebForms и B) от того, как вы реализуете приложение MVC. В «сырых» формах MVC, вероятно, быстрее, чем WebForms, но годы и годы инструментов и опыта позволили создать ряд методов для создания быстрых приложений WebForms. Я готов поспорить, что старший разработчик ASP.NET сможет создать приложение WebForms, которое будет конкурировать по скорости с любым приложением MVC - или, по крайней мере, добиться незначительной разницы.
Настоящая разница, как предположил @tvanfosson, заключается в тестируемости и чистоте SoC. Если повышение производительности является вашей главной заботой, я не думаю, что это отличная причина отказаться от WebForms и начать перестраивать в MVC. По крайней мере, до тех пор, пока вы не опробуете доступные методы оптимизации WebForms.
Он уменьшил одну из моих страниц с 2 МБ до 200 КБ, просто исключив состояние просмотра и сделав программно сносной работу с представленным выводом.
Один только размер, даже несмотря на то, что обработка была такой же, значительно улучшит количество подключений в секунду и скорость запросов.
Я думаю, что многие люди, которые думают, что WebForms по своей сути медленные или ресурсоемкие, возлагают вину не на то место. В 9 случаях из 10, когда меня приглашают оптимизировать приложение веб-форм, существует слишком много мест, где авторы приложений неправильно понимают цель состояния просмотра. Я не говорю, что состояние просмотра идеальное или что-то в этом роде, но злоупотреблять им ПУТЬ слишком легко, и именно это злоупотребление вызывает раздутое поле состояния просмотра.
Эта статья оказалась бесценной, поскольку помогла мне понять многие из этих злоупотреблений. https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate
Чтобы провести корректное сравнение между MVC и WebForms, мы должны быть уверены, что оба приложения правильно используют архитектуры.
Мое тестирование показывает от 2 до 7 раз больше запросов в секунду для MVC, но это зависит от того, как вы создаете приложение веб-форм. С текстом «привет, мир», без каких-либо элементов управления на стороне сервера, mvc работает примерно на 30-50% быстрее.
Для меня реальное улучшение «производительности» в 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 по умолчанию использует механизм просмотра веб-форм и может быть настроен для использования любого количества пользовательских механизмов просмотра, поэтому, если вы хотите сравнить производительность, вам придется быть более конкретным.
Я начал работать в 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-адреса не работают. Это как если бы у вас были статически типизированные ресурсы, а также статически типизированные объекты. Статически типизированное веб-приложение? Это то, что я хочу!
Я бы посоветовал большему количеству людей попробовать это.
Проекты, созданные с помощью visual studio. Один - шаблон mvc4, другой - WebForm (традиционный). И когда делаем нагрузочный тест с WCAT, вот результат,
может получить более 2500 об / с
убийца производительности был обнаружен, что это ошибка MVC Bata или RC. И производительность будет улучшена, когда я удалю вещи Bundles. Теперь последняя версия исправила это.
Производительность зависит от того, что вы делаете ... Обычно MVC быстрее, чем asp.net, в основном потому, что Viewstate отсутствует и потому что MVC по умолчанию больше работает с обратным вызовом, чем с обратной передачей.
Если вы оптимизируете свою страницу веб-формы, вы можете иметь ту же производительность, что и MVC, но это потребует много работы.
Кроме того, у них есть множество nugets для MVC (а также для Webform), которые помогут вам улучшить производительность веб-сайта, например, объединить и минимизировать ваши css и javascripts, сгруппировать ваши изображения и использовать их как спрайты и т. Д.
Производительность веб-сайта во многом зависит от вашей архитектуры. Чистый код с хорошим разделением задач принесет вам более чистый код и лучшее представление о том, как улучшить производительность.
Вы можете взглянуть на этот шаблон « Neos-SDI MVC Template », который по умолчанию создаст для вас чистую архитектуру с множеством улучшений производительности (проверьте веб- сайт MvcTemplate ).
Я провел небольшой нагрузочный тест 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 и так далее.