Pull to refresh

Comments 51

Кстати не хватает работы с базой — а это самое интересное.
Например я так и не смог подружить Entity Framework с Mono. Но используя стандартный ADO.net Driver смог все таки подключиться к MySQL.
В ветке моно 3.* в комплекте идет Entity Framework 5.0. К нему в придачу идет Npgsql (.Net Data Provider for Postgresql). Последние сборки уже начинают поддержку Entity Framework 6. Подробнее — офф сайт Npgsql

Его как раз и буду дружить с PostgreSQL :). MySQL не рассматриваю на данный момент.
У меня кстати появлялись очень странные ошибки (при портировании на mono). Может Вы подскажите, что за мистика?

Первый вопрос — Если в 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 все нормально работает.
Удивительно то, что остальные комментарии нормально отрабатываются. Проблема или в " > " или в " < "

По первому вопросу — динамическая компиляция предполагает, что только успешно скомпилированные файлы попадут во временную папку, где и происходит выполнение кода. Вьюха с ошибкой -> не скомпилилась -> не попадет на выполнение.

По второму вопросу:
А если вот так?
<!-- <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.
Поддержка кучи движков баз данных из коробки, гораздо более гибкая конфигурация (сделайте мне в EF ссылки не на ключевое поле), гораздо более адекватные запросы (эт скорее к Linq2Nibernate)
сделайте мне в EF ссылки не на ключевое поле

Я бы пересмотрел такой дизайн БД. Такого быть не должно, чтобы ссылки на сущности были не по ключевому полю.
Только вот одна проблема — система уже 15 лет в продакшне. И эти хвосты и кривизна тянется с незапамятных времен.
В той версии, в которой решено использовать ORM, дожна быть совместимость со старой базой. Ибо при переходе старая и новая версия должны работать параллельно.

Как сказал архитектор (бывший, увы) — когда ORM накладывает ограничения на структуру базы — это нехорошо.
NHibernate на накладывает, используем его.

Не говоря уже о том, что все коды под рукой, и если что — подправить не проблема.
Не говоря уже о том, что все коды под рукой, и если что — подправить не проблема.

Если вы об исходных кодах, то EF также опенсорсен.

А можно вкратце, зачем делаете ссылки не по ключевому полю? Мне действительно интересно, не придумал сходу такой ситуации просто.
>>А можно вкратце, зачем делаете ссылки не по ключевому полю?

Я делаю ссылки по не-ключевому полю только потому, что так было до меня.
А до меня — так уж исторически сложилось :(

>>Если вы об исходных кодах, то EF также опенсорсен.

Майкрософт открывает свои коды не под GPL или LGPL, а под своей лицензией. Вкратце — чисто для ознакомления, править ни-ни.
Так что опенсорсом, в его привычном смысле, и не пахнет.

Предваряя вопросы из серии «а доводилось(была ли нужда) ли тебе править код опенсорсных проектов, сложнее, чем Hello World» — да, доводилось.
Я делаю ссылки по не-ключевому полю только потому, что так было до меня.
А до меня — так уж исторически сложилось :(

Я имел ввиду не мотивацию, а логику, которая реализована таким путем. Наш отдел застыл в размышлениях, зачем может быть нужен такой ключ. Он хоть по уникальному полю создан?

Майкрософт открывает свои коды не под GPL или LGPL, а под своей лицензией. Вкратце — чисто для ознакомления, править ни-ни.
Так что опенсорсом, в его привычном смысле, и не пахнет.

Вы заблуждаетесь, лицензия Apache 2.0 не майкрософтовская: entityframework.codeplex.com/license
У меня тоже подобное было, при чём тоже наследие, скорее всего копипасты. Существует естественный (уникальный) ключ, интовый — отлично подходит на роль. И суррогатный. И таблицы которые референсят то так, то так. При чём естественный используется наверное чаще, чем суррогатный. Но развалить базу — практически невозможно. :)
Увы, не тут копипаста.

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

А вот в чем меня NHibernate разочаровала, так это слабости своего linq провайдера.
Причем баги тянутся с версии 3.2.
Под копипастой я имел ввиду создание таблиц по шаблону, а там всегда суррогатный ключ. С другой стороны, зная как создавался продукт (временные рамки и общая боевая обстановка) — это неудивительно.
А по поводу ORM — я вообще сторонник легковесных решений, на подобии BLToolkit/linq2db. Ну dapper — это перебор легковесности. В любом случае — разумеется ORM не должна выдвигать свои ограничения, тут я люто согласен. С EF я знаком не много, но так получалось — куда не доводилось плюнуть, везде — надо городить костыли, вместо прямых и понятных решений. Вообще паттерн UoW в моей практике бесполезен, хотя может не встречалось подходящих задач.
>>С другой стороны, зная как создавался продукт (временные рамки и общая боевая обстановка) — это неудивительно.

[жмет руку]
Слышны слова синьора, не 23-летнего :)

У нас немного другая ситуация (в плане временных рамок), а вот обстановка была схожая.
>>Вы заблуждаетесь, лицензия Apache 2.0 не майкрософтовская:
таки попутал c лицензией на FW

>>Я имел ввиду не мотивацию, а логику, которая реализована таким путем

Нет никакой логики. Обычная связь один-ко-многим.

>>Наш отдел застыл в размышлениях, зачем может быть нужен такой ключ

Я же сказал, смысла нет. Просто сочетание велодрома и «так исторически сложилось».
Кстати, довольно распространенная ситуация для проектов, которые тянутся десятилетиями.

Если жаждете подробностей — welcome в личку. Хоть содержания своего NDA и не помню, но рассказывать много о проекте в паблик считаю не очень этичным.
Майкрософт открывает свои коды не под GPL или LGPL, а под своей лицензией. Вкратце — чисто для ознакомления, править ни-ни.
Так что опенсорсом, в его привычном смысле, и не пахнет.


Вы немного путаете. Это исходники стандартных дотнетовских библиотек открыты только для ознакомления и использования их в отладке. Entity Framework распространяется под лицензией Apache: entityframework.codeplex.com/license
Я понимаю если бы вы например L2S с Dapper посоветовали, но NHibernate же вообще фу-фу-фу.
Были бы также интересны тесты — сравнение производительности сайта под IIS и под nginx+mono на одной и той же машине.
Да, мне и самому интересно взглянуть на такие тесты. Спасибо.
Необходимо правильно настроить серверы, и если с 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.
У меня почему-то подозрение, что Mono там древний и/или неправильно настроенный.
В этом одно из отличий между идеологиями — продукты майкрософт по дефолту имееют неплохие настройки (но и не лучшие), а в случае с тем же nginx — нужно правильно все настроить (кеширование, статический контент, балансировку между несколькими инстансами fastcgi).

Еще не нашел, как же nginx общается с mono? Если xsp, то я не удивлен…
Какая версия mono? Вроде как ответ должен быть тут, но его нет www.techempower.com/benchmarks/#section=environment
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).
Ну у меня связка 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.
Стало быть надо искать ботлнек. Ибо в аспнете нечему так тормозить, особенно если это ServiceStack, работающий напрямую через IHttpHandler.
Это снаружи — это IHttpHandler, всего лишь один метод на интерфейсе. А так еще куча всего зависит от того, как работает этот mono runtime machine. Даже неправильное обращение с памятью может вызывать безумные тормоза.

Эти тесты — это 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 даёт о себе знать). Возможно, я этим займусь в свободное время.
Подписался, жду статью. Интересно также услышать чуть более подробную конфигурацию, которую используете для своих проектов
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, мне просто самому интересно.
В общем, по итогам могу сообщить следующее:
  1. когда я запустил NancyFx поверх xsp из их примера оно на первой паре тысяч запросов выдало 1200/в секунду, а потом сдулось до 300-400.
  2. я дятел и неправильно тестировал вариант с NancyFx+HttpListener, он по факту выдаёт не 7500, а 3500, мой ab в комментарии выше замерял время ответа Bad Request
  3. бакэнд с использованием 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, посмотрим, включат ли в сентябрьские тесты.
У меня у одного показывает (Round 6):

aspnet-mvc — 291 (Results from Windows on m1.large EC2 instances)
aspnet-mvc-mono — 851 (Results from Linux on physical hardware)

?
Там несколько Rounds, разные тесты и т.п. Так что, предполагаю, что вы, наверное, нашли эти цифры, но с какого теста?
Хрен его знает. Вроде оно. Round 6, Multiple queries.
aspnet-mvc ~ 265 — Ful C# Net IIS Mo Raw Rea
aspnet-mvc-mono ~ 851 — Ful C# Mon ngx Mo Raw Rea
А что под этими загадками кроестя — незнаю. Но вроде одни и те же ж тесты.
UFO just landed and posted this here
Комментарий краткий, но емкий. Из статьи хабра habrahabr.ru/post/130868/
Пишите checkinstall вместо make install

Этого действительно будет достаточно? Обязательно сделаю, протестирую и поделюсь. Спасибо, что напоумили.
В моём PPA есть 3.2.0 с установкой в /opt/mono-3. Правда, без xsp, целью было всё же завести свежие билды MonoDevelop. В принципе, мне на днях надо будет конфигурировать новую инсталляцию, могу заодно обновить это дело.
JFYI:
sudo add-apt-repository ppa:nginx/stable
nginx.org (а равно и nginx.com) никакого отношения к этому репозиторию не имеет.
Официальные репозитории находятся тут: nginx.org/ru/linux_packages.html
Спасибо, интересно.
PS. Мне было бы очень интересно посмотреть на работу более сложного функционала, например User(Role)MemberShip, который у меня в приложении активно используется
Если я не ошибаюсь, EntityFramework данными скриптами не устанавливается? Как можно его установить (https://github.com/mono/entityframework)? Спасибо
Sign up to leave a comment.

Articles