Comments 51
эх… Где Вы были неделю назад? :)
Только недавно запускал ASP.NET MVC 3 на Ubuntu.
Только недавно запускал ASP.NET MVC 3 на Ubuntu.
Кстати не хватает работы с базой — а это самое интересное.
Например я так и не смог подружить Entity Framework с Mono. Но используя стандартный ADO.net Driver смог все таки подключиться к MySQL.
Например я так и не смог подружить Entity Framework с Mono. Но используя стандартный ADO.net Driver смог все таки подключиться к MySQL.
В ветке моно 3.* в комплекте идет Entity Framework 5.0. К нему в придачу идет Npgsql (.Net Data Provider for Postgresql). Последние сборки уже начинают поддержку Entity Framework 6. Подробнее — офф сайт Npgsql
Его как раз и буду дружить с PostgreSQL :). MySQL не рассматриваю на данный момент.
Его как раз и буду дружить с PostgreSQL :). MySQL не рассматриваю на данный момент.
У меня кстати появлялись очень странные ошибки (при портировании на mono). Может Вы подскажите, что за мистика?
Первый вопрос — Если в View есть ошибка — View просто не находит. (на IIS или в WebDev (дебага от Visual Studio) описывает саму ошибку в коде View, а на Mono не находит View,
)
Самый интересный, второй вопрос — Предположим у нас во вьюхе есть дивка:
Я её захотел закомментировать.
В итоге получаю ошибку — Опять не может найти вьюху.
Хотя на IIS и WebDev все нормально работает.
Удивительно то, что остальные комментарии нормально отрабатываются. Проблема или в " > " или в " < "
Первый вопрос — Если в View есть ошибка — View просто не находит. (на IIS или в WebDev (дебага от Visual Studio) описывает саму ошибку в коде View, а на Mono не находит View,
The view 'temfds' or its master was not found or no view engine supports the searched locations. The following locations were searched:
~/Views/Panel/temfds.aspx
~/Views/Panel/temfds.ascx
~/Views/Shared/temfds.aspx
~/Views/Shared/temfds.ascx
~/Views/Panel/temfds.cshtml
~/Views/Panel/temfds.vbhtml
~/Views/Shared/temfds.cshtml
~/Views/Shared/temfds.vbhtml
)
Самый интересный, второй вопрос — Предположим у нас во вьюхе есть дивка:
<div class="jumbotron"></div>
Я её захотел закомментировать.
<!--div class="jumbotron"></div-->
В итоге получаю ошибку — Опять не может найти вьюху.
Хотя на IIS и WebDev все нормально работает.
Удивительно то, что остальные комментарии нормально отрабатываются. Проблема или в " > " или в " < "
По первому вопросу — динамическая компиляция предполагает, что только успешно скомпилированные файлы попадут во временную папку, где и происходит выполнение кода. Вьюха с ошибкой -> не скомпилилась -> не попадет на выполнение.
По второму вопросу:
А если вот так?
Похоже на багрепорт :) С какой версией mono/xsp возникает проблема?
По второму вопросу:
А если вот так?
<!-- <div class="jumbotron"></div> -->
Похоже на багрепорт :) С какой версией mono/xsp возникает проблема?
Ваш вариант работает.
Интересно, что
<!-- <div class="jumbotron"></div> -->
Стал проверять:<!-- <div class="jumbotron"</div> -->
— нормально<!-- <div class="jumbotron">/div> -->
— нормально<!-- <div class="jumbotron"/div> -->
— нормально<!-- div class="jumbotron"/div> -->
— нормально<!-- div class="jumbotron"</div> -->
— нормально<!-- div class="jumbotron"</div -->
— ошибкаИнтересно, что
<!-- > -->
<!-- <> -->
<!-- < -->
к ошибкам не приводит<!-- </ -->
— ошибкаMono JIT compiler version 2.10.8.1 (Debian 2.10.8.1-5ubuntu1)
Copyright (C) 2002-2011 Novell, Inc, Xamarin, Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none
Misc: softdebug
LLVM: supported, not enabled.
GC: Included Boehm (with typed GC and Parallel Mark)
>>Например я так и не смог подружить Entity Framework с Mono
Хватит грызть кактус. Переходите на NHibernate.
Хватит грызть кактус. Переходите на NHibernate.
Плюсы?
Поддержка кучи движков баз данных из коробки, гораздо более гибкая конфигурация (сделайте мне в EF ссылки не на ключевое поле), гораздо более адекватные запросы (эт скорее к Linq2Nibernate)
сделайте мне в EF ссылки не на ключевое поле
Я бы пересмотрел такой дизайн БД. Такого быть не должно, чтобы ссылки на сущности были не по ключевому полю.
Только вот одна проблема — система уже 15 лет в продакшне. И эти хвосты и кривизна тянется с незапамятных времен.
В той версии, в которой решено использовать ORM, дожна быть совместимость со старой базой. Ибо при переходе старая и новая версия должны работать параллельно.
Как сказал архитектор (бывший, увы) — когда ORM накладывает ограничения на структуру базы — это нехорошо.
NHibernate на накладывает, используем его.
Не говоря уже о том, что все коды под рукой, и если что — подправить не проблема.
В той версии, в которой решено использовать ORM, дожна быть совместимость со старой базой. Ибо при переходе старая и новая версия должны работать параллельно.
Как сказал архитектор (бывший, увы) — когда ORM накладывает ограничения на структуру базы — это нехорошо.
NHibernate на накладывает, используем его.
Не говоря уже о том, что все коды под рукой, и если что — подправить не проблема.
Не говоря уже о том, что все коды под рукой, и если что — подправить не проблема.
Если вы об исходных кодах, то EF также опенсорсен.
А можно вкратце, зачем делаете ссылки не по ключевому полю? Мне действительно интересно, не придумал сходу такой ситуации просто.
>>А можно вкратце, зачем делаете ссылки не по ключевому полю?
Я делаю ссылки по не-ключевому полю только потому, что так было до меня.
А до меня — так уж исторически сложилось :(
>>Если вы об исходных кодах, то EF также опенсорсен.
Майкрософт открывает свои коды не под GPL или LGPL, а под своей лицензией. Вкратце — чисто для ознакомления, править ни-ни.
Так что опенсорсом, в его привычном смысле, и не пахнет.
Предваряя вопросы из серии «а доводилось(была ли нужда) ли тебе править код опенсорсных проектов, сложнее, чем Hello World» — да, доводилось.
Я делаю ссылки по не-ключевому полю только потому, что так было до меня.
А до меня — так уж исторически сложилось :(
>>Если вы об исходных кодах, то EF также опенсорсен.
Майкрософт открывает свои коды не под GPL или LGPL, а под своей лицензией. Вкратце — чисто для ознакомления, править ни-ни.
Так что опенсорсом, в его привычном смысле, и не пахнет.
Предваряя вопросы из серии «а доводилось(была ли нужда) ли тебе править код опенсорсных проектов, сложнее, чем Hello World» — да, доводилось.
Я делаю ссылки по не-ключевому полю только потому, что так было до меня.
А до меня — так уж исторически сложилось :(
Я имел ввиду не мотивацию, а логику, которая реализована таким путем. Наш отдел застыл в размышлениях, зачем может быть нужен такой ключ. Он хоть по уникальному полю создан?
Майкрософт открывает свои коды не под GPL или LGPL, а под своей лицензией. Вкратце — чисто для ознакомления, править ни-ни.
Так что опенсорсом, в его привычном смысле, и не пахнет.
Вы заблуждаетесь, лицензия Apache 2.0 не майкрософтовская: entityframework.codeplex.com/license
UFO just landed and posted this here
Увы, не тут копипаста.
Независимо от того, насколько крива база, ORM не должна выдвигать свои ограничения по отношению к ней. В этом и заключается гибкость.
А вот в чем меня NHibernate разочаровала, так это слабости своего linq провайдера.
Причем баги тянутся с версии 3.2.
Независимо от того, насколько крива база, ORM не должна выдвигать свои ограничения по отношению к ней. В этом и заключается гибкость.
А вот в чем меня NHibernate разочаровала, так это слабости своего linq провайдера.
Причем баги тянутся с версии 3.2.
>>Вы заблуждаетесь, лицензия Apache 2.0 не майкрософтовская:
таки попутал c лицензией на FW
>>Я имел ввиду не мотивацию, а логику, которая реализована таким путем
Нет никакой логики. Обычная связь один-ко-многим.
>>Наш отдел застыл в размышлениях, зачем может быть нужен такой ключ
Я же сказал, смысла нет. Просто сочетание велодрома и «так исторически сложилось».
Кстати, довольно распространенная ситуация для проектов, которые тянутся десятилетиями.
Если жаждете подробностей — welcome в личку. Хоть содержания своего NDA и не помню, но рассказывать много о проекте в паблик считаю не очень этичным.
таки попутал c лицензией на FW
>>Я имел ввиду не мотивацию, а логику, которая реализована таким путем
Нет никакой логики. Обычная связь один-ко-многим.
>>Наш отдел застыл в размышлениях, зачем может быть нужен такой ключ
Я же сказал, смысла нет. Просто сочетание велодрома и «так исторически сложилось».
Кстати, довольно распространенная ситуация для проектов, которые тянутся десятилетиями.
Если жаждете подробностей — welcome в личку. Хоть содержания своего NDA и не помню, но рассказывать много о проекте в паблик считаю не очень этичным.
Майкрософт открывает свои коды не под GPL или LGPL, а под своей лицензией. Вкратце — чисто для ознакомления, править ни-ни.
Так что опенсорсом, в его привычном смысле, и не пахнет.
Вы немного путаете. Это исходники стандартных дотнетовских библиотек открыты только для ознакомления и использования их в отладке. Entity Framework распространяется под лицензией Apache: entityframework.codeplex.com/license
Я понимаю если бы вы например L2S с Dapper посоветовали, но NHibernate же вообще фу-фу-фу.
Были бы также интересны тесты — сравнение производительности сайта под IIS и под nginx+mono на одной и той же машине.
Да, мне и самому интересно взглянуть на такие тесты. Спасибо.
Необходимо правильно настроить серверы, и если с IIS я достаточно плотно работал, то дзен nginx'а лишь начал познавать :)
Необходимо правильно настроить серверы, и если с IIS я достаточно плотно работал, то дзен nginx'а лишь начал познавать :)
Если не забыть дописать -O=all и включить SGen (в 3.2+ задействован по умолчанию) и использовать FastCGI/SCGI, то разница несущественна.
www.techempower.com/benchmarks/ (справа сверху можно переключаться между тестами на разных машинами — i7, EC2, Win)
i7 (linux on physical hardware): aspnet-mvc-mono — 2,187
Win (m1.large — aws.amazon.com/ec2/instance-types/ 2 vCPU) aspnet-mvc — 2,916
То есть mono медленнее на physical hardware с i7, чем MS CLR на виртуальной машине с 2 vCPU.
i7 (linux on physical hardware): aspnet-mvc-mono — 2,187
Win (m1.large — aws.amazon.com/ec2/instance-types/ 2 vCPU) aspnet-mvc — 2,916
То есть mono медленнее на physical hardware с i7, чем MS CLR на виртуальной машине с 2 vCPU.
У меня почему-то подозрение, что Mono там древний и/или неправильно настроенный.
В этом одно из отличий между идеологиями — продукты майкрософт по дефолту имееют неплохие настройки (но и не лучшие), а в случае с тем же nginx — нужно правильно все настроить (кеширование, статический контент, балансировку между несколькими инстансами fastcgi).
Еще не нашел, как же nginx общается с mono? Если xsp, то я не удивлен…
Какая версия mono? Вроде как ответ должен быть тут, но его нет www.techempower.com/benchmarks/#section=environment
Еще не нашел, как же nginx общается с mono? Если xsp, то я не удивлен…
Какая версия mono? Вроде как ответ должен быть тут, но его нет www.techempower.com/benchmarks/#section=environment
Информацию о версиях и т.п. нужно смотерть тут github.com/TechEmpower/FrameworkBenchmarks/tree/master/aspnet
Не спорю про настройки, но все же…
Не спорю про настройки, но все же…
XSP latest (Linux)
nginx 1.4.1 & XSP FastCGI (Linux)
Как-то неоднозначно… Это надо понимать, как «FastCGI из последнего XSP»?
Почему в качестве адаптеров и бд взяты бета версии? Сомневаюсь, что в них производительность в приоритете.
В общем, без своего
Если бы там разнились цифры на несколько процентов, я бы согласился, что без своих тестов не обойтись (кстати, все тесты доступны, как opensource проект). Но тут разница в несколько раз. Притом, что люди контрибутят в эти тесты. Вот, например, народ пытался ушустрить mono перед Round 5 github.com/TechEmpower/FrameworkBenchmarks/pull/272
А по поводу БД — эта же та же самая БД и на WIndows и на Linux, притом, если бы MySQL, например, тормозил бы на одной платформе так, что показатели фреймворка были бы слабые, то это было бы заметно на других фреймворках (nodejs, php, etc).
А по поводу БД — эта же та же самая БД и на WIndows и на Linux, притом, если бы MySQL, например, тормозил бы на одной платформе так, что показатели фреймворка были бы слабые, то это было бы заметно на других фреймворках (nodejs, php, etc).
Ну у меня связка BLToolkit + NancyFX + самописный SCGI-хост для NancyFX + nginx перемалывает запросы со свистом, очень странно видеть такие показатели на таком железе. Возможно, стоило подкрутить размер пула потоков, подозреваю что упирается именно в то, что поток синхронно ждёт завершения запроса к БД, а поскольку весь стек обработки HTTP-запроса в managed-коде, банально некому заниматься обработкой новых.
«перемалывает запросы со свистом» — сами понимаете, что все относительно :)
Можно посмотреть на «Single query» test, там треды не должны сильно влиять на производительность. Win (VM) aspnet-mvc (IIS, MySQL): 1,201, i7 (Linux) aspnet-mvc (MySQL тоже) 1,157.
Можно посмотреть на «Single query» test, там треды не должны сильно влиять на производительность. Win (VM) aspnet-mvc (IIS, MySQL): 1,201, i7 (Linux) aspnet-mvc (MySQL тоже) 1,157.
Стало быть надо искать ботлнек. Ибо в аспнете нечему так тормозить, особенно если это ServiceStack, работающий напрямую через IHttpHandler.
Это снаружи — это IHttpHandler, всего лишь один метод на интерфейсе. А так еще куча всего зависит от того, как работает этот mono runtime machine. Даже неправильное обращение с памятью может вызывать безумные тормоза.
Эти тесты — это open source проект, если вы знаете, как сделать mono шустрее — дайте знать автору, и всем, кто интересуется groups.google.com/forum/?fromgroups=#!forum/framework-benchmarks
Эти тесты — это open source проект, если вы знаете, как сделать mono шустрее — дайте знать автору, и всем, кто интересуется groups.google.com/forum/?fromgroups=#!forum/framework-benchmarks
Для интереса запустил у себя на ноуте (Core i5 второго поколения, 2.4 GHz) NancyFx поверх HttpListener с простым контроллером, возвращающим Json (через сериализацию) и натравил на него ab -c 100 -n 10000 напрямую. Получил показатель 7500 запросов в секунду. После этого верить в пиковые 2,346 на Core i7 в ваших тестах я отказываюсь, они либо nginx криво настроили, либо запускали приложение через xsp, а не напрямую, либо ещё какие-то косяки допустили, разбираться, если честно, лень.
Тем не менее NancyFx можно ещё сильнее разогнать, сделав хост поверх libevent, убрав таким образом оверхед от моновского I/O-стека, который работает не вполне оптимально (необходимость эмулировать виндовую модель заточенную под I/O Completion Ports даёт о себе знать). Возможно, я этим займусь в свободное время.
Тем не менее NancyFx можно ещё сильнее разогнать, сделав хост поверх libevent, убрав таким образом оверхед от моновского I/O-стека, который работает не вполне оптимально (необходимость эмулировать виндовую модель заточенную под I/O Completion Ports даёт о себе знать). Возможно, я этим займусь в свободное время.
Подписался, жду статью. Интересно также услышать чуть более подробную конфигурацию, которую используете для своих проектов
BLToolkit + NancyFX + самописный SCGI-хост для NancyFX + nginx
На сколько я понимаю — те тесты всегда работают с БД, так что понятно, что там показатели хуже.
Какие те? JSON Serialization? Где именно тут работа с БД?
public class JsonModule : NancyModule
{
public JsonModule() : base("/json")
{
Get["/"] = x =>
{
return Response.AsJson(new { message = "Hello, World!" });
};
}
}
Я посмотрел именно на строки тестов, в каждой строке упоминается БД. Да, в их коде нет никаких БД.
В любом случае — я понятия не имею, как они делали тестирование, на каком железе (только сравнения процессора — это мало), но у них есть сравнение разных фреймворков. Если вы сделаете свой benchmark тест — мы вам будем только благодарны.
Я тут не для того это приводил, чтобы кого-то переубедить в использовании mono, мне просто самому интересно.
В любом случае — я понятия не имею, как они делали тестирование, на каком железе (только сравнения процессора — это мало), но у них есть сравнение разных фреймворков. Если вы сделаете свой benchmark тест — мы вам будем только благодарны.
Я тут не для того это приводил, чтобы кого-то переубедить в использовании mono, мне просто самому интересно.
В общем, по итогам могу сообщить следующее:
Итого: Вариант с чистым HttpListener даёт выигрыш почти на порядок, libevent ещё удваивает.
По-хорошему надо соорудить тест для прогона с их фреймворком, пушто у меня в плане бенчмарков может быть что-то не так с окружением/настройками/версиями ПО.
- когда я запустил NancyFx поверх xsp из их примера оно на первой паре тысяч запросов выдало 1200/в секунду, а потом сдулось до 300-400.
- я дятел и неправильно тестировал вариант с NancyFx+HttpListener, он по факту выдаёт не 7500, а 3500, мой ab в комментарии выше замерял время ответа Bad Request
- бакэнд с использованием libevent доведён до рабочего состояния. С ним результаты следующие:
Сам по себе без участия NancyFx сервер спокойно жуёт 17000-18000/сек (HttpListener в состоянии отдать 7000 plaintext за секунду), притом что nginx на той же машине с дефолтными настройками (700 соединений, 4 воркера) уприрается в 20000/сек.
При включении инфраструктуры NancyFx и JsonSerializer-а производительность падает до 6500/сек и остаётся стабильной.
Итого: Вариант с чистым HttpListener даёт выигрыш почти на порядок, libevent ещё удваивает.
По-хорошему надо соорудить тест для прогона с их фреймворком, пушто у меня в плане бенчмарков может быть что-то не так с окружением/настройками/версиями ПО.
Гоняю бенчмарки через их фреймворк. Прирост моего Nancy.Hosting.Event2 по сравнению с Nancy.Hosting.AspNet поверх mono-fastcgi-server в 10 раз при полной неразличимости настройки nginx-а.
На текущем бенчмарке:
На моём хосте:
Не особо понятно, от чего так просело на предпоследнем тесте, вероятно, связано с моими манипуляциями на сервере на тот момент.
На текущем бенчмарке:
Requests/sec: 506.92
Requests/sec: 1032.43
Requests/sec: 345.32
Requests/sec: 318.07
Requests/sec: 345.21
Requests/sec: 397.20
Requests/sec: 114.18
Requests/sec: 4.32
На моём хосте:
Requests/sec: 8106.36
Requests/sec: 10161.19
Requests/sec: 8461.12
Requests/sec: 9588.02
Requests/sec: 9882.49
Requests/sec: 3480.04
Requests/sec: 308.88
Requests/sec: 1494.59
Не особо понятно, от чего так просело на предпоследнем тесте, вероятно, связано с моими манипуляциями на сервере на тот момент.
Отправил им pull request, посмотрим, включат ли в сентябрьские тесты.
UFO just landed and posted this here
UFO just landed and posted this here
Комментарий краткий, но емкий. Из статьи хабра habrahabr.ru/post/130868/
Этого действительно будет достаточно? Обязательно сделаю, протестирую и поделюсь. Спасибо, что напоумили.
Пишите checkinstall вместо make install
Этого действительно будет достаточно? Обязательно сделаю, протестирую и поделюсь. Спасибо, что напоумили.
JFYI:
Официальные репозитории находятся тут: nginx.org/ru/linux_packages.html
sudo add-apt-repository ppa:nginx/stablenginx.org (а равно и nginx.com) никакого отношения к этому репозиторию не имеет.
Официальные репозитории находятся тут: nginx.org/ru/linux_packages.html
Спасибо, интересно.
PS. Мне было бы очень интересно посмотреть на работу более сложного функционала, например User(Role)MemberShip, который у меня в приложении активно используется
PS. Мне было бы очень интересно посмотреть на работу более сложного функционала, например User(Role)MemberShip, который у меня в приложении активно используется
Если я не ошибаюсь, EntityFramework данными скриптами не устанавливается? Как можно его установить (https://github.com/mono/entityframework)? Спасибо
Sign up to leave a comment.
Запускаем приложение ASP.NET MVC 4 на Ubuntu Server 12.04 + nginx