Я нашел несколько диких замечаний о том, что 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 по умолчанию больше работает с обратным вызовом, чем с Postback.
Если вы оптимизируете свою страницу веб-формы, вы можете иметь ту же производительность, что и MVC, но это потребует много работы.
Кроме того, у них есть множество nugets для MVC (а также для Webform), которые помогут вам улучшить производительность веб-сайта, например, объединить и минимизировать ваши css и javascripts, сгруппировать ваши изображения и использовать их в качестве спрайтов и т. Д.
Производительность веб-сайта во многом зависит от вашей архитектуры. Чистый код с хорошим разделением проблем принесет вам более чистый код и лучшее представление о том, как улучшить производительность.
Вы можете взглянуть на этот шаблон "Neos-SDI MVC Template ", который по умолчанию создаст для вас чистую архитектуру с множеством улучшений производительности (проверьте веб-сайт MvcTemplate).
Я провел небольшой эксперимент по нагрузочному тесту 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 и так далее.
