0,0
рейтинг
10 сентября 2013 в 11:33

Разработка → Запускаем приложение ASP.NET MVC 4 на Ubuntu Server 12.04 + nginx из песочницы

ASP*, .NET*
Захотелось мне посмотреть, как работает реализация .NET на Linux. Решено было развернуть Ubuntu Server на нашем гипервизоре, установить свежий пакет mono и через nginx запустить ASP.NET MVC4 сайт.

На официальном сайте mono готовый пакет для Ubuntu только 2-х летней давности. С этого момента начались поиски в сети путей осуществления задуманного. Результатом полученного опыта стал скрипт для автоматического развертывания на голой Ubuntu Server 12.04.3 или 13.04 всего необходимого для запуска сайтов ASP.NET MVC4:
  • Соберем из исходников и установим mono 3.2.1
  • Добавим monoserve скрипт в init.d для автоматического запуска сайтов и управления ими.
  • Установим nginx 1.4.1
  • Создадим и настроим простой сайт, чтобы проверить работоспособность всей связки.

Сразу под катом находится строчка для автоматического выполнения всей процедуры, описанной в статье.

Установка всего одной строчкой в консоли


Одна строчка для закачивания скрипта, установки ему права на запуск и собственно запуска. Вначале попросит жмякнуть [Enter] для добавления репозитория, а позже еще раз попросит пароль на sudo.
	wget https://bitbucket.org/mindbar/install-mono/raw/master/install-nginx-mono.sh && sudo chmod +x install-nginx-mono.sh && ./install-nginx-mono.sh

Выполнение всего скрипта зависит от скорости интернета и мощности железа. В среднем около 40 минут.

Требования


Предполагается установка на чистую Ubuntu Server 12.04.3 x64 либо Ubuntu Server 13.04 x64.
ОС установлена без роли:
image

Рекомендую сразу после установки ОС в виртуальную машину сохранить снапшот чистой системы. Очень удобно для экспериментов.
Тестирование скрипта происходило в домашней директории с непривилегированного юзера, но с правами на sudo.

Установка mono & co


Для установки mono нам нужны некоторые зависимости и утилиты. Установим их:
	sudo apt-get -y install build-essential git autoconf libtool automake gettext libglib2.0-dev libjpeg-dev libpng12-dev libgif-dev libexif-dev libx11-dev libxrender-dev libfreetype6-dev libfontconfig1-dev


После этого клонируем и собираем libgdiplus, mono и xsp именно в такой последовательности. Все файлы будем держать в отдельной директории ~/monobuild, а устанавливать в /usr/local
На момент написания статьи версия libgdiplus была 2.10.8. Последнюю версию можно узнать тут: github.com/mono/libgdiplus/releases
	mkdir monobuild
	cd monobuild

	git clone https://github.com/mono/libgdiplus.git
	cd libgdiplus
	git checkout 2.10.8
	./autogen.sh --prefix=/usr/local
	make && sudo make install
	cd ..


Собственно mono. Новые релизы выпускаются достаточно часто — раз в месяц-два. Текущая версия — mono-3.2.1. Последнюю версию можно узнать тут: github.com/mono/mono/releases
Интересный нюанс: чтобы собрать моно нужно сначала собрать компилятор monolite. Благо, он идет в комплекте, нужно только сначала собрать его и потом передать к нему путь для сборки собственно mono:
	git clone https://github.com/mono/mono.git
	cd mono
	git checkout mono-3.2.1
	./autogen.sh --prefix=/usr/local
	make get-monolite-latest && make EXTERNAL_MCS=${PWD}/mcs/class/lib/monolite/gmcs.exe && sudo make install
	cd ..


Дошла очередь до сервера xsp — веб сервер для отладки сайтов на mono. Написан на C#. Вместе с ним идут компоненты FastCGI. Текущая версия — 3.0.11. Последнюю версию можно узнать тут: github.com/mono/xsp/releases

	git clone https://github.com/mono/xsp.git
	cd xsp
	git checkout 3.0.11
	./autogen.sh --prefix=/usr/local
	make && sudo make install
	cd ..
	cd ..


Сверим версию mono -V?
image

nginx


nginx является одним из рекомендуемых веб серверов для связки с mono. Возможно взаимодействие nginx+mono через FastCGI (предпочтительный метод) либо как reverse proxy для xsp.

xsp — это сервер для тестирования и отладки сайтов на mono. Для пром среды его использование не рекомендуется.

Ничего особенного в устанавке nginx нет. Подключаем репозиторий, обновляем список пакетов и устанавливаем nginx.
	sudo apt-get -y install python-software-properties
	sudo add-apt-repository ppa:nginx/stable
	sudo apt-get update 
	sudo apt-get -y install nginx


monoserve


Сайты должны запускаться вместе с сервером.
Предлагаемая конфигурация сродни тем, что используются в nginx:
  • В директории /usr/local/etc/mono/fcgi/apps-available/ хранятся настройки доступных серверов
  • В директории /usr/local/etc/mono/fcgi/apps-enabled/ создаются симлинки на те из них, которые сейчас должны работать

Написан скрипт monoserve, который берет список сайтов из файлов в директории /usr/local/etc/mono/fcgi/apps-enabled и запускает их как демоны от пользователя www-data.

Пример содержания такого файла (одна строчка):
/:/home/anvol/www


Как видим, это всего лишь "/:" + путь к приложению. К сожалению, текущая версия скрипта правильно запускает только один такой сервер. Планируется доработка monoserve, чтобы в конфигурационных файлах можно было указать также порт приложения либо название unix-socket'а. Тогда станет возможным запустить несколько сайтов на одном сервере.

А пока, загрузим из подготовленного мной репозитория чуть переработанный шаблон ASP.NET MVC4 сайта в папку ~/www и настроим monoserve для его запуска
	git clone https://mindbar@bitbucket.org/mindbar/mono-mvc4-default.git www
	sudo mkdir /usr/local/etc/mono/fcgi
	sudo mkdir /usr/local/etc/mono/fcgi/apps-available
	sudo mkdir /usr/local/etc/mono/fcgi/apps-enabled
	sudo touch /usr/local/etc/mono/fcgi/apps-available/default
	echo "/:`pwd`/www" | sudo tee -a /usr/local/etc/mono/fcgi/apps-available/default
	sudo ln -s /usr/local/etc/mono/fcgi/apps-available/default /usr/local/etc/mono/fcgi/apps-enabled/default
	wget https://bitbucket.org/mindbar/install-mono/raw/master/monoserve
	sudo cp monoserve /etc/init.d/monoserve
	sudo chmod +x /etc/init.d/monoserve
	sudo update-rc.d monoserve defaults
	sudo /etc/init.d/monoserve start
	rm monoserve

После этого мы имеем запущенный fastcgi-mono-server4 на порту 9001, который готов выполнять сайт из папки ~/www

Настройка nginx


Завершающим аккордом будет настройка nginx. Первым делом мы отключим дефолтный сервер убрав симлинк на него из /etc/nginx/sites-enabled/:
	sudo rm /etc/nginx/sites-enabled/default


Теперь добавим в /etc/nginx/fastcgi_params необходимые настройки:
	echo "# mono config" | sudo tee -a /etc/nginx/fastcgi_params
	echo "fastcgi_param  PATH_INFO          \"\";" | sudo tee -a /etc/nginx/fastcgi_params
	echo "fastcgi_param  SCRIPT_FILENAME    \$document_root\$fastcgi_script_name;" | sudo tee -a /etc/nginx/fastcgi_params


Напишем конфигурацию для нашего сервера mono:
echo "server {" | sudo tee -a /etc/nginx/sites-available/mono-default
echo "   listen 80;" | sudo tee -a /etc/nginx/sites-available/mono-default
echo "   server_name localhost;" | sudo tee -a /etc/nginx/sites-available/mono-default
echo "   location / {" | sudo tee -a /etc/nginx/sites-available/mono-default
echo "     root `pwd`/www/;" | sudo tee -a /etc/nginx/sites-available/mono-default
echo "     index index.html index.htm default.aspx Default.aspx;" | sudo tee -a /etc/nginx/sites-available/mono-default
echo "     fastcgi_index Home;" | sudo tee -a /etc/nginx/sites-available/mono-default
echo "     fastcgi_pass 127.0.0.1:9001;" | sudo tee -a /etc/nginx/sites-available/mono-default
echo "     include /etc/nginx/fastcgi_params;" | sudo tee -a /etc/nginx/sites-available/mono-default
echo "   }" | sudo tee -a /etc/nginx/sites-available/mono-default
echo "}" | sudo tee -a /etc/nginx/sites-available/mono-default


Включаем нашу конфигурацию, создавая симлинк в /etc/nginx/sites-enabled, и просим nginx принять изменения в работу
	sudo ln -s /etc/nginx/sites-available/mono-default /etc/nginx/sites-enabled/mono-default
	sudo /etc/init.d/nginx restart


Заходим браузером на ip-вашей-виртуалки либо проверяем работу сайта в консоли:
	wget localhost && cat index.html

image

Пользуйтесь на здоровье.

Планы


  • В первую очередь — доработать monoserve скрипт.
  • Далее, на мой взгляд, стоит добавить в шаблон сайта поддержку БД. В нашем случае будем разворачивать PostgreSQL и дружить их с шаблоном ASP.NET MVC4.
  • Вместо git clone репозитория качать архив необходимого релиза. Это быстрее, но с другой стороны, локальный репозиторий можно быстрее актуализировать, переключить на другую версию.
  • Добавить обработку ошибок с прекращением дальнейшего выполнения скрипта.


Приветствуются замечания к скрипту, пожелания на его будущие доработки. Спасибо.

Ссылки на используемые материалы


FastCGI — Mono
Run ASP.Net MVC4 on Ubuntu 12.10
Mono / FastCGI Startup Script
Андрей Волошин @Anvol
карма
25,0
рейтинг 0,0
CTO

Похожие публикации

Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (51)

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

        Его как раз и буду дружить с PostgreSQL :). MySQL не рассматриваю на данный момент.
        • +1
          У меня кстати появлялись очень странные ошибки (при портировании на 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 все нормально работает.
          Удивительно то, что остальные комментарии нормально отрабатываются. Проблема или в " > " или в " < "

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

            По второму вопросу:
            А если вот так?
            <!-- <div class="jumbotron"></div> -->
            


            Похоже на багрепорт :) С какой версией mono/xsp возникает проблема?
            • 0
              Ваш вариант работает.
              <!-- <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)
      • –3
        >>Например я так и не смог подружить Entity Framework с Mono
        Хватит грызть кактус. Переходите на NHibernate.
        • +1
          Плюсы?
          • 0
            Поддержка кучи движков баз данных из коробки, гораздо более гибкая конфигурация (сделайте мне в EF ссылки не на ключевое поле), гораздо более адекватные запросы (эт скорее к Linq2Nibernate)
            • –1
              сделайте мне в EF ссылки не на ключевое поле

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

        Еще не нашел, как же nginx общается с mono? Если xsp, то я не удивлен…
        Какая версия mono? Вроде как ответ должен быть тут, но его нет www.techempower.com/benchmarks/#section=environment
        • –1
          Информацию о версиях и т.п. нужно смотерть тут github.com/TechEmpower/FrameworkBenchmarks/tree/master/aspnet
          Не спорю про настройки, но все же…
          • +1
            XSP latest (Linux)
            nginx 1.4.1 & XSP FastCGI (Linux)

            Как-то неоднозначно… Это надо понимать, как «FastCGI из последнего XSP»?
            Почему в качестве адаптеров и бд взяты бета версии? Сомневаюсь, что в них производительность в приоритете.

            В общем, без своего лунапарке с блек-джеком... тестирования не обойтись.
            • 0
              Если бы там разнились цифры на несколько процентов, я бы согласился, что без своих тестов не обойтись (кстати, все тесты доступны, как opensource проект). Но тут разница в несколько раз. Притом, что люди контрибутят в эти тесты. Вот, например, народ пытался ушустрить mono перед Round 5 github.com/TechEmpower/FrameworkBenchmarks/pull/272

              А по поводу БД — эта же та же самая БД и на WIndows и на Linux, притом, если бы MySQL, например, тормозил бы на одной платформе так, что показатели фреймворка были бы слабые, то это было бы заметно на других фреймворках (nodejs, php, etc).
          • +2
            Ну у меня связка BLToolkit + NancyFX + самописный SCGI-хост для NancyFX + nginx перемалывает запросы со свистом, очень странно видеть такие показатели на таком железе. Возможно, стоило подкрутить размер пула потоков, подозреваю что упирается именно в то, что поток синхронно ждёт завершения запроса к БД, а поскольку весь стек обработки HTTP-запроса в managed-коде, банально некому заниматься обработкой новых.
            • 0
              «перемалывает запросы со свистом» — сами понимаете, что все относительно :)

              Можно посмотреть на «Single query» test, там треды не должны сильно влиять на производительность. Win (VM) aspnet-mvc (IIS, MySQL): 1,201, i7 (Linux) aspnet-mvc (MySQL тоже) 1,157.
              • +2
                Стало быть надо искать ботлнек. Ибо в аспнете нечему так тормозить, особенно если это ServiceStack, работающий напрямую через IHttpHandler.
                • 0
                  Это снаружи — это IHttpHandler, всего лишь один метод на интерфейсе. А так еще куча всего зависит от того, как работает этот mono runtime machine. Даже неправильное обращение с памятью может вызывать безумные тормоза.

                  Эти тесты — это open source проект, если вы знаете, как сделать mono шустрее — дайте знать автору, и всем, кто интересуется groups.google.com/forum/?fromgroups=#!forum/framework-benchmarks
                  • +1
                    Для интереса запустил у себя на ноуте (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 даёт о себе знать). Возможно, я этим займусь в свободное время.
                    • 0
                      Подписался, жду статью. Интересно также услышать чуть более подробную конфигурацию, которую используете для своих проектов
                      BLToolkit + NancyFX + самописный SCGI-хост для NancyFX + nginx
                    • –1
                      На сколько я понимаю — те тесты всегда работают с БД, так что понятно, что там показатели хуже.
                      • +1
                        Какие те? JSON Serialization? Где именно тут работа с БД?
                            public class JsonModule : NancyModule
                            {
                                public JsonModule() : base("/json")
                                {
                                    Get["/"] = x =>
                                    {
                                        return Response.AsJson(new { message = "Hello, World!" });
                                    };
                                }
                            }
                        
                        • 0
                          Я посмотрел именно на строки тестов, в каждой строке упоминается БД. Да, в их коде нет никаких БД.
                          В любом случае — я понятия не имею, как они делали тестирование, на каком железе (только сравнения процессора — это мало), но у них есть сравнение разных фреймворков. Если вы сделаете свой benchmark тест — мы вам будем только благодарны.
                          Я тут не для того это приводил, чтобы кого-то переубедить в использовании mono, мне просто самому интересно.
                          • +3
                            В общем, по итогам могу сообщить следующее:
                            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 ещё удваивает.

                            По-хорошему надо соорудить тест для прогона с их фреймворком, пушто у меня в плане бенчмарков может быть что-то не так с окружением/настройками/версиями ПО.
                          • +3
                            Гоняю бенчмарки через их фреймворк. Прирост моего 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
                            


                            Не особо понятно, от чего так просело на предпоследнем тесте, вероятно, связано с моими манипуляциями на сервере на тот момент.
                          • +1
                            Отправил им pull request, посмотрим, включат ли в сентябрьские тесты.
      • 0
        У меня у одного показывает (Round 6):

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

        ?
        • 0
          Там несколько Rounds, разные тесты и т.п. Так что, предполагаю, что вы, наверное, нашли эти цифры, но с какого теста?
          • +1
            Хрен его знает. Вроде оно. 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
            А что под этими загадками кроестя — незнаю. Но вроде одни и те же ж тесты.
  • +1
    sudo make install

    Это же отвратительно. Соберите пакет.
    • 0
      Комментарий краткий, но емкий. Из статьи хабра habrahabr.ru/post/130868/
      Пишите checkinstall вместо make install

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

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.