Я обновил Ubuntu. Запилите про меня новость.

Интересно было бы сравнить с Java, причём разброс времени ответа тоже интересен (примерно покажет, как работает GC там и там).

.NET Core нынче из пакетов ставится на RHEL, скоро ждите его также в лучших дистрибутивах недалеко около вас.

Во-первых, это про opensource, во-вторых - ставишь ASP.NET Core на свою любимую $distr_name и будет тебе счастье.

Talk is cheap, show me the code

Повышение производительности - 2300%

Тут явно простым удалением sleep(100500) не обошлось.

Мне больше всего на графике понравилось «смотрите какой nodejs негибкий - он не прогрессирует! а наш .net прогрессирует!» :D

Олени, блин, реально хоть бы показали, чем тестировали. Достигли они.

Или может они nodejs в один поток гоняли, а ASP.NET в 32? :)))

https://habrahabr.ru/company/eset/blog/278339/

Судя по всему,они собираются поддержку LXC (контейнеров) запилить в следующем обновлении.

Там же на графике есть сравнение с нодой и текущей версией asp.net.

Там может и есть, но тут никто туда не ходит.

У них уже и официальный бенчмарк висит.

https://github.com/aspnet/benchmarks

Ну в общем все соснули у Netty

Повышение производительности - 2300%

круто, теперь все будет чотче

Переписали на си. Ваш КО.

мы гордимся тобой

Переписали критичные для теста участки на си?

Да ну, на пайфон... У пайфона ввод/вывод такой же по скорости, как у си. ( tailgunner). Лол.

И таки что они сделали?

видимо отдают кешик из памяти

А я пытаюсь заняться портом штук от Rosetta@HOME на Rustlang. Потом подниму RISC-V на ПЛИС и буду дрочить. Производительность будет намного выше.

Там еще из-за iis могли быть накладные расходы на старых версиях.

Читал что в новых версиях iis просто управляет запуском приложения и выступает как прокси. Что, конечно, быстрее стандартного pipeline iis'а.

Если они действительно self hosted с iis'ом сравнивали, то эти 2300% ни о чем. Надо измерять сравнимые вещи, иначе непонятно, откуда такой результат.

ввод/вывод, что закономерно после введения поголовного DMA на платформе x86, упирается или в скорость работы диска (с учётом обработки фрагментации планировщиком в ядре ОС), или в пропускную способность шины IDE или USB2.0. Каким местом «пайфона» относится к этому?

Я не знаком с программированием .NET и конкретно ASP.NET Core.

Можете мне в общих чертах объяснить, милион каких запросов в секунду они обработали? Милион чтений памяти? Милион сетевых пакетов? Милион кадров в секунду? Милион отгруженых конечному пользователю веб-страниц?

DMA

а оно вообще есть в linux?

DMA

а оно вообще есть в linux?

Помню в игрушку играл на Intel286 под DOS - гоночки, медленоватые, как мне показалось. А потом как то запустил на своем более новом (по тем временам) AMD K-6-III - так очень быстро гонки пошли, после старта до аварии проходило меньше секунды ;-)

В MK на 486-ом еще неплохо игралось против ботов, а на Целероне образца 2004-го года вообще нереально было продержаться, так быстро они накидывали по щам.

https://github.com/aspnet/benchmarks

https://github.com/aspnet/benchmarks

Смущает это: These are server experiments that are intended to measure the non-HTTP overload of different technology stacks and approaches. These generally aren't real HTTP servers but rather TCP servers that special case replying to any HTTP-looking request with a fixed HTTP response.

Тоесть как я понял указанные результаты без учета TCP, а просто время генерации респонса стеком на 32 потоках. Это же огромная разница по сравнению с полноценным сетевым тестированием. Например если респонс генерируется внутри модуля nginx, то время его генерации стремится к нулю по сравнению с работой TCP стека и сети. Вот я замерю время это функции в которой только memcpy(buf, HEADERS, size); и получу 100+ лямов\в сек, отличное тестирование? Не думаю.

умеет к тому же жить внутри docker'a

Ты уверен, что понимаешь, что такое докер?

Уж фибоначи бы посчитали, что ли.

Ага, методом Балансера

https://github.com/Balancer/benchmarks-fib-obj

Ага, методом Балансера

Естественно!

Какая-то адовая синтетика, а не тест. Уж фибоначи бы посчитали, что ли.

Зачем? А вам слабо хотя бы на простейшем хелловорде выдать такой результат или выше? Что у вас там сейчас в моде, питон, нода...

При этом я исользовал Nt* функции и обращался напрямую к ядру

Ну и какие гарантии, что ты переизобрёл completion ports лучше, чем это сделало M$?

итого чуть меньше миллисекунды на запрос. учитывая прямо сейчас перед глазами 3мс максимума и 1.5 среднее на жабе в продакшне, должен признаться, достижения у них так себе

Ну и какие гарантии, что ты переизобрёл completion ports лучше, чем это сделало M$?

Никаких, я просто пробовал выжать все что можно из платформы, и фичу отдачи статики из ядра пробовал (не под вин сервером оно кстати лимитировалось в 1 ядро и работало плохо). Загадка уже разгадана, читай выше, это тест без учета сети, так что результат говорит только о том что они убрали дикий оверхед инициализации\упаковки итд запроса.

Кстати обнаружил что в этом https://github.com/zellux/linux-scalability-benchmark/blob/master/libowfat/io... бенчмарке есть поддержка винды и отсылки через ядро. Попробуйте если хотите, думаю результат вас удивит.

итого чуть меньше миллисекунды

Калькулятор себе купи.

Затем, чтобы по этим цифрам можно было хоть что-то сказать. А так это конь сферический, в вакууме. Ни сравнить, ни повторить.

Загадка уже разгадана, читай выше, это тест без учета сети

Осталось разгадать загадку, каким местом читают анонимусы лора, что

These generally aren't real HTTP servers but rather TCP servers that special case replying to any HTTP-looking request with a fixed HTTP response.

Превращается в «тест без учета сети» и «Тоесть как я понял указанные результаты без учета TCP».

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

2kk на эрланге

Ну, хз, какой-то сферический конь в вакууме.

На эрланге на одной тачке держали 2 миллиона вебсокет коннекшенов и то, ограничились только по ulimit

http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections

На эрланге на одной тачке держали 2 миллиона вебсокет коннекшенов

Лохи :) Некоторые умудряются 12 лямов держать

https://mrotaru.wordpress.com/2013/10/10/scaling-to-12-million-concurrent-con...

http://docs.asp.net/en/latest/performance/measuring.html

We are currently working on this topic.

Да-да-да, я тоже когда-то учился пользоваться тулзами для нагрузочного тестирования и получал кривые результаты :-). В статье же нет ничего ни о результатах, ни о объекте исследования, только абстрактная цифра и фотография торта, буллщит. Просто вброс какой-то, пшик. Но маркетинговый ход конечно удачный.

Не понял какова суть ваших претензий? Веб серверы обычно исрпользуют TCP сокеты, не UDP, так что в данном контексте без TCP=без сети. Кроме этого вторую фразу можно понять как: эти серверные эксперементы призваны измерить не http загрузку конкретного стека и подхода. То есть измеряется стек выше хттп или проще говоря время создания респонса, что не так?

Никаких, я просто пробовал выжать все что можно из платформы,

Хорошо, и что это дало в сравнении с портами?

это тест без учета сети

Они как раз померяли сеть, просто захардкодили http-заголовки.

Кстати обнаружил что в этом https://github.com/zellux/linux-scalability-benchmark/blob/master/libowfat/io... бенчмарке есть поддержка винды и отсылки через ядро.

Там известный еще c NT 3.51 TransmitFile, который послужил прообразом линуксового sendfile'а.

Хорошо, и что это дало в сравнении с портами?

Вы про Nt* и прямое обращение к ядру вместо оберток? Единицы процентов. Порты так же ничего не дают по сравнению с прямой записью в сокет или TransmitFile. Дают настройки сокета вроде TCP_NODELAY.

Они как раз померяли сеть, просто захардкодили http-заголовки.

Да возможно, хотя я не уверен. Первая фраза на английском это опровергает, вторая подтверждяет, нужно смотреть самому. Должно быть какое-то объяснение. В исходниках бенчмарка вот оно по идее самое быстрое с ответом hello world https://github.com/aspnet/benchmarks/blob/dev/experimental/NativeHttpServer/P... Однако это фактически простой нативный сокет тест вроде того что я кидал и никаких таких заоблачных цифр я в нем не наблюдаю.

Там известный еще c NT 3.51 TransmitFile, который послужил прообразом линуксового sendfile'а.

Истории не знаю, но API хороший и удобный. Жаль только на винде он работает гораздо медленее. Если вы найдете любой виндовый способ лучше и который покажет хотябы близкую к линуксу скорость, не то что из топика - буду признателен.

А ты отличаешь «держать 2 миллиона коннектов» и «обрабатывать 2 миллиона пакетов в секунду»? Твой ерланг скорее всего загнётся тысячах на десяти.

Единицы процентов.

Довольно предсказуемо, и очень хорошо, если в плюс.

Порты так же ничего не дают по сравнению с прямой записью в сокет

В каком смысле? Что вы меряли?

Бенч примерно следующий: на стороне сервера пул потоков слушает TCP сокет с длинной очередью. Далее бэкэнды порты\overlapped\write\TransmitFile + обычный или WSAEnumNetworkEvents (аналог epoll) режим для винды и write\sendfile\signal + обычный или epoll режим для линуха. Назрузку создает ab2 на линуксе. На винде еще можно включить Nt* для всего WinAPI примерно так:

    InitializeObjectAttributes(&ObjectAttributes, &Name,
        OBJ_CASE_INSENSITIVE, NULL, NULL);

    NTSTATUS ret = NtOpenFile(&hFile,
        FILE_READ_ATTRIBUTES | FILE_READ_EA | FILE_WRITE_ATTRIBUTES | FILE_WRITE_EA, &ObjectAttributes,
        &IoStatusBlock, FILE_SHARE_READ | FILE_SHARE_WRITE, FILE_NON_DIRECTORY_FILE);
    if (ret)
        return -1;
    ret = NtQueryInformationFile(hFile, &IoStatusBlock,
        &IntInformation, sizeof(IntInformation), FileInternalInformation);

Да, еще забыл упомянуть, это все в режиме keep-alive. Т.е. 16 потоков приконнектились по одному разу, и дальше строчат запросы в keep-alive без реконнекта. Иначе скорось падает сильно. Судя по

        static readonly string responseStr = "HTTP/1.1 200 OK\r\n" +
            "Content-Type: text/plain;charset=UTF-8\r\n" +
            "Content-Length: 10\r\n" +
            "Connection: keep-alive\r\n" +
            "Server: Dummy\r\n" +
            "\r\n" +
            "HelloWorld";

By the early 2010s millions of connections on a single commodity 1U server became possible: over 2 million connections (WhatsApp, 24 cores, using Erlang on FreeBSD), 10–12 million connections (MigratoryData, 12 cores, using Java on Linux)

ref: https://en.wikipedia.org/wiki/C10k_problem