Ещё лучше взять xUnit, он более правильно спроектирован и создаёт отдельный экземпляр класса на каждый тест.

А оно под *nix-системами уже работать научилось?

В ntdll обе версии приводят к вызову в ядре Zw-версии. Nt напрямую можно импортировать только из драйвера, т. к. там валидация может быть не нужна.

Эцсамое. Int — не «простое число». Int — знаковое целое.

Что только русские не придумают, лишь бы дороги не строить ©.

Гоняю бенчмарки через их фреймворк. Прирост моего 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. когда я запустил 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 ещё удваивает.

По-хорошему надо соорудить тест для прогона с их фреймворком, пушто у меня в плане бенчмарков может быть что-то не так с окружением/настройками/версиями ПО.

Какие те? JSON Serialization? Где именно тут работа с БД?

    public class JsonModule : NancyModule
    {
        public JsonModule() : base("/json")
        {
            Get["/"] = x =>
            {
                return Response.AsJson(new { message = "Hello, World!" });
            };
        }
    }

Для интереса запустил у себя на ноуте (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 даёт о себе знать). Возможно, я этим займусь в свободное время.

Эцсамое. Вы вообще в курсе что Skype Desktop API до конца года отключат?

А Xen DomU всё ещё не планируется, да? Уж очень хочется соорудить гибридную систему с единым Display Server-ом для всего.

Стало быть надо искать ботлнек. Ибо в аспнете нечему так тормозить, особенно если это ServiceStack, работающий напрямую через IHttpHandler.

Ну у меня связка BLToolkit + NancyFX + самописный SCGI-хост для NancyFX + nginx перемалывает запросы со свистом, очень странно видеть такие показатели на таком железе. Возможно, стоило подкрутить размер пула потоков, подозреваю что упирается именно в то, что поток синхронно ждёт завершения запроса к БД, а поскольку весь стек обработки HTTP-запроса в managed-коде, банально некому заниматься обработкой новых.

У меня почему-то подозрение, что Mono там древний и/или неправильно настроенный.

Если не забыть дописать -O=all и включить SGen (в 3.2+ задействован по умолчанию) и использовать FastCGI/SCGI, то разница несущественна.

В моём PPA есть 3.2.0 с установкой в /opt/mono-3. Правда, без xsp, целью было всё же завести свежие билды MonoDevelop. В принципе, мне на днях надо будет конфигурировать новую инсталляцию, могу заодно обновить это дело.

Тогда уж -i. -s не выставляет переменные окружения как надо.

Карта очень простая — банальный граф с кривыми линиями между комнатами и возможностью таскать эти самые комнаты по карте для более удобного просмотра происходящего.
Т. е. выглядит примерно так (картинка нагуглена), но вместо кругов квадраты и точки соприкосновения на них фиксированы:

Значит, окружение одной комнаты описывается структурой из четырех байт, причем первый из них — это номер комнаты слева. Исходя из карты уровня, видно, что оставшиеся три байта описывают комнаты справа, сверху и снизу. Причем, если комната отсутствует, то на соответствующем месте будет стоять 0.

Исходя из этого я делаю вывод, что набор переходов из одной комнаты не связан с наборами переходов её соседей. То есть, можно сделать так, что, например, справа от первой комнаты вторая, слева от второй первая, но справа от второй вторая же. Таким образом сколько бы принц ни бежал направо, он будет оставаться во второй комнате. Но стоит из неё уйти налево — он снова окажется в первой. И это только простейший пример, можно строить безумные невозможные пространства с сжигающей мозг картой переходов.

А зачем надо было делать жёсткую сетку уровней? Намного занятнее было бы сделать возможность построения произвольных графов комнат. Например, как я понял из структуры, описывающей соседей, игра позволяет сделать туннель, который бесконечен в одном из направлений.