Здравствуйте, ·, Вы писали:

НС>>А что с unsafe то не так? То что его на джаве нет?
·>Using unsafe code introduces security and stability risks.

Ну это уж как использовать.

Здравствуйте, ·, Вы писали:

V>>JNI в полный рост.
·>А ты посмотри повнимательней — коннекторы к frontend серверам — apache, isapi, обёртка вокруг win32 sendfile и подобное. Вряд ли что-то из этого используется в бенчмарке.

Сам посмотри повнимательней:
https://github.com/mdaniel/svn-caucho-com-resin/blob/master/modules/c/src/common/stream.c
https://github.com/mdaniel/svn-caucho-com-resin/blob/master/modules/c/src/resin_os/jni_os.c
https://github.com/mdaniel/svn-caucho-com-resin/blob/master/modules/c/src/resin_os/jni_socket.c
https://github.com/mdaniel/svn-caucho-com-resin/blob/master/modules/c/src/resin_os/std.c

— вообще весь IO нейтивный;
— управление буферами памяти нейтивное;
— даже нейтивное управление процессами/демонами и общение с ними.


V>>"Вылизанный kestrel" — полностью managed.
·>libuv.

И ты достоверно знаешь, что используется это:
https://github.com/aspnet/KestrelHttpServer/blob/master/src/Kestrel.Transport.Libuv/Internal/LibuvConnection.cs
а не это:
https://github.com/aspnet/KestrelHttpServer/blob/master/src/Kestrel.Transport.Sockets/Internal/SocketConnection.cs
?

·>тут вообще смешно... число в строчку безопасно сконвертировать не могут...

По ссылкам для Резина такого навалом.

С другой стороны, возможно некий рудимент, бо сегодня можно и без указателей:

    struct Chars13
    {
        public fixed char Data[13];
    }

Пояснять надо?
Как тебе такое?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>А что с unsafe то не так? То что его на джаве нет?
НС>·>Using unsafe code introduces security and stability risks.
НС>Ну это уж как использовать.
Ну а накой тогда вообще заморачиваться с этим всем managed?

Здравствуйте, Ночной Смотрящий, Вы писали:

S>>>Никто не мешает нам иметь кэш в памяти, который держит недавние запросы.
V>>В случае масштабирования врать не будет? ))
НС>Для такого придуманы всякие редисы.

Или можно простой нейтивный HTTP-прокси на входе поставить.

Здравствуйте, Titus, Вы писали:

Здесь нужно смотреть и на перспективы. Сейчас развивается .Net Core а вместе с ним много внимание уделяется и скорости.
В том числе и .Net Native который применяется в UWP и ilcpp https://blogs.unity3d.com/ru/2015/05/06/an-introduction-to-ilcpp-internals/
http://mattwarren.org/2018/06/07/CoreRT-.NET-Runtime-for-AOT/

https://github.com/dotnet/corert

Здравствуйте, ·, Вы писали:

НС>>Ну это уж как использовать.
·>Ну а накой тогда вообще заморачиваться с этим всем managed?

unsafe обычно в коде очень не много. Прям как те 700 строк JNI. Только, в отличие от JNI, оно остается по прежнему типизированным, кроссплатформенным, и не требует танцев с бубном.

Здравствуйте, vdimas, Вы писали:

V>Или можно простой нейтивный HTTP-прокси на входе поставить.

Можно. Такое, правда, сейчас сильно непопулярно.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Ну это уж как использовать.
НС>·>Ну а накой тогда вообще заморачиваться с этим всем managed?
НС>unsafe обычно в коде очень не много. Прям как те 700 строк JNI. Только, в отличие от JNI, оно остается по прежнему типизированным, кроссплатформенным, и не требует танцев с бубном.
Unsafe бы не помог. Тот упомянутый JNI как раз обёртка над платформоспецифичным API epoll, который в jre появился не сразу, в современных имплементациях сетевых приложений и тут JNI уже не нужен.

Ещё насколько я знаю, в java серверах используется нативный SSL/TLS (в бенчмарке вроде оно не участвует). А у .net managed версия есть?

Здравствуйте, ·, Вы писали:

.NET Core we have changed the default transport in Kestrel from libuv to sockets

Здравствуйте, koandrew, Вы писали:

GIV>>Нет такого выбора. Гемор с виндой всегда вынужденная мера, по дефолту ствят линукс, инфа 100%.

K>Так делают только очень неумные системные дизайнеры. Ну или просто профнепригодные
Угу, а потом пляшут с бубном когда надо в кубернейтис все это запихать.

K>У нас например 90% всей инфраструктуры поддержки производства на винсерверах, а в цехах почти 100% процесса производства управляется под разными версиями винды.
У вас вроде не джава или я ошибаюсь? И расскажи чем обусловлен выбор ОС в вашем случае.

Здравствуйте, ·, Вы писали:

·> А у .net managed версия есть?

С рождения.

Здравствуйте, vorona, Вы писали:

V>.NET Core we have changed the default transport in Kestrel from libuv to sockets

Вот как раз благодаря тем самым Span<T> сотоварищи.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·> А у .net managed версия есть?
НС>С рождения.
Эээ... Хкм.

Здравствуйте, ·, Вы писали:

НС>>·> А у .net managed версия есть?
НС>>С рождения.
·>Эээ... Хкм.

И? То что есть обертка для нативных реализаций не означает отсутствия managed.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>·> А у .net managed версия есть?
НС>>>С рождения.
НС>·>Эээ... Хкм.
НС>И? То что есть обертка для нативных реализаций не означает отсутствия managed.
Да я не это имел в виду. То что managed версия есть, не означает, что она юзабельна, тормозит же поди жутко.

Здравствуйте, ·, Вы писали:

·>То что managed версия есть, не означает, что она юзабельна, тормозит же поди жутко.

Попробуй обосновать свое заявление. Насколько я в курсе, CAPI в штатном HttpClient не используется хотя бы потому что пакет с ним как netstandard заявлен.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>То что managed версия есть, не означает, что она юзабельна, тормозит же поди жутко.
НС>Попробуй обосновать свое заявление. Насколько я в курсе, CAPI в штатном HttpClient не используется хотя бы потому что пакет с ним как netstandard заявлен.
Я не знаю что там используется. Нагуглил в моно это, в коре это. А ты почему решил что managed имплементация используется? Может, наверное, и используется как fallback если нативное не смогло завестись на некой платформе. И работает пусть тормозно, но работает.

Здравствуйте, ·, Вы писали:

НС>>·>То что managed версия есть, не означает, что она юзабельна, тормозит же поди жутко.
НС>>Попробуй обосновать свое заявление. Насколько я в курсе, CAPI в штатном HttpClient не используется хотя бы потому что пакет с ним как netstandard заявлен.
·>Я не знаю что там используется.

Кто бы сомневался.

·> А ты почему решил что managed имплементация используется?

Потому что netstandard подразумевает работу под разными платформами.

·> Может, наверное, и используется как fallback если нативное не смогло завестись на некой платформе. И работает пусть тормозно, но работает.

Что еще нафантазируешь? Вот исходники, можешь посмотреть как оно на самом деле.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>·>То что managed версия есть, не означает, что она юзабельна, тормозит же поди жутко.
НС>>>Попробуй обосновать свое заявление. Насколько я в курсе, CAPI в штатном HttpClient не используется хотя бы потому что пакет с ним как netstandard заявлен.
НС>·>Я не знаю что там используется.
НС>Кто бы сомневался.
А почему я должен знать? Ты говорить стесняешься, а то что я нахожу — сомнений не оставляет.

НС>·> А ты почему решил что managed имплементация используется?
НС>Потому что netstandard подразумевает работу под разными платформами.
И что? jdk тоже подразумевает работу под разными платформами. Это не значит, что там всё манагед.

НС>·> Может, наверное, и используется как fallback если нативное не смогло завестись на некой платформе. И работает пусть тормозно, но работает.
НС>Что еще нафантазируешь? Вот исходники, можешь посмотреть как оно на самом деле.
Так я смотрел и увидел CurlHandler. Да и файлы с суффиксами Windows, Unix, OSX. А ты что там видишь?