Производительность ASP.NET в Mono (Linux) и IIS (Windows)

Question

Есть ли разница в производительности между размещением вашего asp.net в моно на linux и iis на оконном сервере?

Answer 1

Конечно, есть разница, как и разница в производительности между Java и .Net. Тем не менее, он будет широко варьироваться в зависимости от того, что делает приложение.

Есть вещи, где .Net намного быстрее, чем Mono. Есть вещи, где Mono намного быстрее, чем .Net. Есть вещи, где они работают примерно одинаково. То же самое верно при сравнении приложений, работающих в Windows или Linux. То же самое верно при сравнении приложений, работающих на IIS и Apache.

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

Answer 2

Что касается предложения lextm о том, что публикация результатов сравнений perf "невозможна", то Лицензионное соглашение с конечным пользователем (EULA) для Windows Vista Ultimate допускает это при определенных условиях.

MICROSOFT .NET BENCHMARK TESTING. программное обеспечение включает в себя один или несколько компоненты .NET Framework 3.0 («Компоненты .NET»). Вы можете провести внутреннее тестирование тех компоненты. Вы можете раскрыть результаты любого теста тех компоненты, при условии, что вы соответствуете с условиями, изложенными в http://go.microsoft.com/fwlink/?LinkID=66406. Несмотря на любое другое соглашение вы можете иметь с Microsoft, если вы раскрыть результаты такого теста, Microsoft имеет право на раскрыть результаты теста тесты проводит ваши продукты которые конкурируют с применимым .NET Компонент, при условии, что он соответствует те же условия, изложенные в http://go.microsoft.com/fwlink/?LinkID=66406.

Условия, как я их понимаю, являются разумными требованиями к раскрытию информации: исходный код, который вы использовали для тестирования, версии программного обеспечения, которое вы тестировали, дата, когда вы проводили тесты, конфигурация и выполненные вами оптимизации и т. Д.

Лицензионное соглашение для Windows Server 2003 включает те же положения. Я не смог найти лицензионное соглашение для Windows Server 2008 (последнее воплощение), но я предполагаю, что условия для тестирования остаются.

Приложение : Если вы загляните в лицензионное соглашение для Windows7, вы, вероятно, найдете предложение, не содержащее бенчмаркинга, или, точнее, предложение об отсутствии публикации; это потому, что Win7 все еще находится в предварительной версии. Когда он будет официально выпущен, ожидайте, что будут присутствовать стандартные условия публикации эталонных тестов.

В прошлом у Microsoft была более строгая политика в этой области. В основном: вам необходимо разрешение от нас (Microsoft) для раскрытия сравнений производительности. Эта политика была смягчена, даже задним числом для .NET v1.0 и v1.1, согласно ссылке в приведенном выше EULA .

Answer 3

Вот хороший тест , в котором кто-то тестировал разницу между Windows / IIS и Linux / Apache / Mono (mod_mono). Достаточно сумасшедший mod_mono (плагин apache's mono) был значительно более производительным. Конечно, я уверен, что в определенных обстоятельствах все будет по-другому, но, учитывая, что низкопрофильные Linux и Apache плюс отличная работа, которую проделали моно парни, само собой разумеется, что Linux / Apache / Mono - лучший путь. Теперь, как уже было сказано, мы надеемся, что с новым открытым исходным кодом ASP, мы скоро увидим несколько высокопроизводительных серверов Linux .Net (подготовленных и готовых к работе в облаке).

график сравнения производительности

Answer 4

Моно отстой!

• http://art -blog.no-ip.info / CppCMS / блог / запись / 27
• http://www.phpvs.net/2008/02/08/benchmarking-mono-aspnet-vs-php-a-slight-problem/

Или более политически правильно: Mono еще не готов к прайм-тайму, по крайней мере, для веб-приложений Asp.Net:

• Нет поддержки кеширования
• Производительность ужасно нестабильна и падает после запуска приложения.

РЕДАКТИРОВАТЬ: Добавлены цитаты для моего поста, ответ на последний комментарий.

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

<%@ OutputCache Duration="20" VaryByParam="None" %>

Я бы это сделал - безрезультатно! Производительность такая же.

Примечание: после более глубокой проверки реализация кэша в modo очень ограничена и плоха, после недавних проверок она сохраняется в более новых версиях mono.

Хорошо, в любом случае я сделал несколько тестов (...), простые часы дают мне около 750 страниц в секунду для кэшированного варианта и 650 для не кэшированного. Тесты проводились под IIS 5.0 на двухъядерном Pentium D 3G

Тот же код ... с mod_mono (под Signle Core AMD Athlon 3000) дал мне:

• 350 страниц в секунду.
• Следующий прогон дал 300.
• следующие 200
• и следующие 150

Итак, бенчмаркинг невозможен.

Ссылка на пост все еще не является аугментативной?

Нет моно определенно не готов к прайм-тайм.

Answer 5

Я запускаю моно-приложения под mod_mono. С точки зрения удобства использования он работает нормально, хотя я не делал никаких тестов. Тем не менее IIS действительно является невероятно удобной средой для работы. Учитывая выбор, я по-прежнему размещаю свой веб-сервер в IIS и использую моно-клиенты linux для подключения к нему.

Answer 6

Во-первых, было сказано, что публикация статистики производительности для сравнения реализаций CLR (.NET против Mono) невозможна. Я не уверен, что является источником, но команда Mono опубликовала сравнение только среди версий Mono (1.x, 2.0 , 2.2 и 2.4), поэтому я предполагаю, что высказывание реально. Таким образом, вы можете проверить производительность только в своей среде.

Во-вторых, в последнее время Mono развивается гораздо быстрее, что дает вам шанс повысить производительность, просто улучшив время выполнения Mono.

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

Как уже упоминалось в jpobst, даже если вы не можете решить проблемы самостоятельно, вы можете связаться с парнями из Mono.