Производительность ASP.NET в моно (Linux) по сравнению с IIS (окно)
У меня была похожая проблема, но я не помню, что мне помогло. Конечно, вы можете попробовать перезапустить Eclipse. Убедитесь, что вы указали правильный путь Eclipse при установке lombok. В этой теме вы можете найти другие потенциальные решения: Невозможно заставить Project Lombok работать на Eclipse (Helios)
5 ответов
Конечно, разница есть, как и разница в производительности между Java и .Net. Однако он будет широко варьироваться в зависимости от того, что делает приложение.
Есть вещи, в которых .Net намного быстрее, чем Mono. Есть вещи, в которых Mono намного быстрее, чем .Net. Есть вещи, в которых они работают примерно одинаково. То же самое можно сказать и о сравнении приложений, работающих в Windows или Linux. То же самое верно и при сравнении приложений, работающих на IIS и Apache.
Вероятно, любое из них может запустить ваше приложение достаточно быстро, и вы обнаружите, что ваша производительность будет определяться вашими методами программирования. Разница в несколько запросов в секунду, вероятно, не является большой проблемой, если у вас нет большой фермы серверов.
Моно - отстой!
- http://art-blog.no-ip.info/cppcms/blog/post/27
- http://www.phpvs.net/ 2008/02/08 / benchmarking-mono-aspnet-vs-php-a-small-problem /
Или более политкорректно: Mono еще не готов к использованию в прайм-тайм, по крайней мере, для веб-приложений Asp.Net:
- Нет поддержки кэширования.
- Производительность ужасно нестабильна и падает после запуска приложения.
РЕДАКТИРОВАТЬ: Добавлены цитаты для моего сообщения, ответ на последний комментарий.
Однако, чтобы сделать справедливое сравнение ... Я должен включить кеширование ... добавление следующей строки в заголовок aspx файла должно мне помочь.
<% @ OutputCache Duration = "20" VaryByParam = "None"%>Я сделал это - безрезультатно! Производительность такая же.
Примечание: после более тщательной проверки реализация кеша в modo очень ограничена и неудовлетворительна, после недавних проверок она все еще сохраняется в более новых версиях mono.
Хорошо, в любом случае я провел несколько тестов ( ...) простые часы дают около 750 страниц в секунду для кешированного варианта и 650 для не кешированного. Тесты проводились под IIS 5.0 на Dual Core Pentium D 3G
Тот же код ... с mod_mono (под Signle Core AMD Athlon 3000) дал мне:
- 350 страниц в секунду.
- Следующий запуск дал 300.
- следующие 200
- и следующие 150
Таким образом, сравнительный анализ невозможен.
Ссылка на сообщение все еще не увеличивающий?
Нет моно определенно не готов для прайм-тайма.
Я запускал моно-приложения под mod_mono. С точки зрения удобства он работает нормально, хотя я не проводил никаких тестов. Тем не менее, IIS действительно невероятно удобная среда для работы. Учитывая выбор, я бы по-прежнему размещал свой веб-сервер в IIS и использовал моно-клиенты Linux для подключения к нему.
Во-первых, было сказано, что публикация статистики производительности для сравнения реализаций CLR (.NET и Mono) невозможна. Я не уверен, что является источником, но команда Mono опубликовала сравнение только между Mono версии (1.x, 2.0, 2.2 и 2.4), поэтому я предполагаю, что высказывание правдиво. Следовательно, вы можете тестировать производительность только в своей собственной среде.
Во-вторых, Mono в последнее время развивается намного быстрее, что дает вам шанс повысить производительность, просто обновив среду выполнения Mono.
В-третьих, пожалуйста, используйте другое отношение судить о продукте с открытым исходным кодом. Для продуктов с закрытым исходным кодом вы ничего не можете сделать, кроме как умолять их поставщика повысить производительность или оказывать поддержку по настройке ваших приложений. Для проектов с открытым исходным кодом у вас есть доступ к базе кода, и вы можете адаптировать ее под свои нужды. и устраните проблемы для ваших собственных приложений.
Как упоминалось в jpobst, даже если вы не можете исправить проблемы самостоятельно, вы можете связаться с ребятами из Mono.
Что касается предложения lextm о том, что публикация результатов сравнения производительности «невозможна», лицензионное соглашение с конечным пользователем (также известное как EULA) для Windows Vista Ultimate позволяет это с условиями.
ЭТАЛОННОЕ ТЕСТИРОВАНИЕ MICROSOFT .NET. В программное обеспечение включает один или несколько компоненты .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, согласно ссылке в вышеприведенном лицензионном соглашении .