Здравствуйте, m2l, Вы писали:
m2l>>>А WSA — "windows socket api", всё имеющее этот префикс в Unix отсутствует. Хотя сами функции во делались на основе сокетов Unix-а, и во многих местах схожи.
M>>В винде вполне себе совместимое бсд сокет апи. А WSA* — это уже про асинхронщину, и про то, чтобы кинуть окошку сообщение, если что-то на сокет пришло, и тд, и тп. На голых сокетах асинхронщина делается также, как и в *никсах. Хотя poll/epoll нет, но оно и в *никсах не всегда бывает. Аналога WSA* в голых *никсах нету никакого.
m2l>А с чём ты не согласен в моём утверждении?
Здравствуйте, m2l, Вы писали:
m2l>>>А WSA — "windows socket api", всё имеющее этот префикс в Unix отсутствует. C>>Ибо это гуано нафиг не нужно. m2l>Аргументов не будет?
Аргумент простой — на Винде нет высокопроизводительных серверов.
m2l>Они пока ещё не до конца уверенны в себе и по дефолту не используют его, только если сам добавишь в конфиг, на свой страх и риск (не малый риск, если почитать release changes насчёт bugfix).
Так это пока что очень новый API, пока с ним аккуратно экспериментируют.
C>>В Windows 11 добавили практически аналогичный API: https://windows-internals.com/ioring-vs-io_uring-a-comparison-of-windows-and-linux-implementations/ m2l>Справедливости ради, io_uring привнёс наконец то асинхронную работу через один интерфейс и с файлами и с сетью, чего раньше в linux не было.
Не совсем так. Был aio, который можно было использовать по образу и подобию IOCP, но он не давал преимуществ на практике.
m2l>Но было в Windows как часть IOCP с Windows NT 3.5 ещё ~25 лет назад. Добавим возможность zero-copy буферов за счет усложнённой сигнатуры WSASend/WSARecv (хотя этим объективно практически никто не пользовался).
И тоже не совсем так. В IOCP доступны только с десяток системных вызовов. Причём тот же CreateFile/CloseHandle не поддерживаются. Потому на практике файловый IO в Windows для неблокирующихся серверов тоже приходилось выпихивать в отдельный пул потоков.
Сам по себе IOCP сделан неплохо, и даже лучше epoll'а в Линуксе. Но эти оба API — предыдущее поколение.
m2l>Ещё можно вспомнить ядерную реализацию HTTPS в Windows — TLS в ядре не ново, и много споров вызывает. То по итогу ключевое нововведение io_uring — общая область памяти между сетевой картой, ядром и прикладным приложением. И такой подход при всех своих огромных плюсах на нагрузках вроде Netflix или Youtube имеют большой минус связанный с тем как всё это будет работать в моменты, когда эта общая область памяти фиксированного размера будут заканчивается (прикладной уровень, например не будет успевать обработать всё что к нему прилетело). Ядру и сетевой карте нужно будет гонять данные между временными буферами и т.д. — в граничных условиях этот интерфейс ещё несколько лет лучше не эксплуатировать.
Буферы данных в io_uring управляются пользователем, они не закончатся.
m2l>PS. io_uring с ядерной поддержкой TLS ярко контрастирует с тем же QUIC, где всё пытаются наоборот засунуть всё в user-mode. Прямо такие противоположности и отличная тема для священных войн.
Ну всё правильно, эксперименты лучше проводить в userspace. Недавно допилили до принятого RFC — так что сейчас можно добавлять в ядро.
Здравствуйте, Cyberax, Вы писали:
m2l>>Аргументов не будет? C>Аргумент простой — на Винде нет высокопроизводительных серверов.
Всегда можно вспомнить работающий на Windows Stackoverflow, или то что серверные платформы дешевле держать и оптимизировать под бесплатный Linux, или то, что API должен не только давать возможность выжать максимум производительности, но и быть удобен в том числе для новичков. Я сам сталкивался с такими серверами под Windows и наблюдал их миграцию под Linux из-за бесплатности последнего. Поэтому это так себе аргумент.
C>Так это пока что очень новый API, пока с ним аккуратно экспериментируют.
Ну да. Но автор топика то спрашивает на чем ему делать сейчас. Подсовывать ему очень новое API — не лучшая затея, я в этом плане.
C>>>В Windows 11 добавили практически аналогичный API: https://windows-internals.com/ioring-vs-io_uring-a-comparison-of-windows-and-linux-implementations/ m2l>>Справедливости ради, io_uring привнёс наконец то асинхронную работу через один интерфейс и с файлами и с сетью, чего раньше в linux не было. C>Не совсем так. Был aio, который можно было использовать по образу и подобию IOCP, но он не давал преимуществ на практике.
Я в курсе насчет aio. И его проблем. И имею в виду, что это общая очередь событий и для сети и для файлов, с общими воркерами — и это то чего раньше не было, и это явный прогресс, хотя в винде давно уже было.
m2l>>Но было в Windows как часть IOCP с Windows NT 3.5 ещё ~25 лет назад. Добавим возможность zero-copy буферов за счет усложнённой сигнатуры WSASend/WSARecv (хотя этим объективно практически никто не пользовался). C>И тоже не совсем так. В IOCP доступны только с десяток системных вызовов. Причём тот же CreateFile/CloseHandle не поддерживаются. Потому на практике файловый IO в Windows для неблокирующихся серверов тоже приходилось выпихивать в отдельный пул потоков.
В IOCP не десяток системных вызов доступен, а асинхронный ввод-вывод. Насчет отдельного пула — туда можно было выносить операции открытия файлов, кидая в основной события об их завершении. Но в большинстве случаев это не совсем оправдано из-за специфики открытия файлов. Выносить за пределы рабочих тредов iocp операцию закрытия хендлов — совсем не оправдано. И заводить, как io_uring, рабочие потоки в пространстве ядра ради эмуляции асинхронности открытия файлы — это плохая затея.
C>Сам по себе IOCP сделан неплохо, и даже лучше epoll'а в Линуксе. Но эти оба API — предыдущее поколение.
Ну да, у обоих есть плюсы и минусы.
m2l>>Ещё можно вспомнить ядерную реализацию HTTPS в Windows — TLS в ядре не ново, и много споров вызывает. То по итогу ключевое нововведение io_uring — общая область памяти между сетевой картой, ядром и прикладным приложением. И такой подход при всех своих огромных плюсах на нагрузках вроде Netflix или Youtube имеют большой минус связанный с тем как всё это будет работать в моменты, когда эта общая область памяти фиксированного размера будут заканчивается (прикладной уровень, например не будет успевать обработать всё что к нему прилетело). Ядру и сетевой карте нужно будет гонять данные между временными буферами и т.д. — в граничных условиях этот интерфейс ещё несколько лет лучше не эксплуатировать. C>Буферы данных в io_uring управляются пользователем, они не закончатся.
Это, в общем случае как раз минус. То, чем раньше занималось ядро за тебя — реализуй сам и это минус, и закончится скорей всего какой-нибудь библиотекой делающей то, что раньше делало ядро. И это странно, поскольку выходит насквозь прикладной TLS пихаем в ядро, а управление системными ресурсами связанными с сетевой картой — выпихиваем на прикладной уровень. Плюс io_uring в фиксированной области памяти для сетевого ввода-вывода, которую можно зафиксировать и для сетевой карты, без обновления SDL-ей. Причем, если оглядывается на dpdk/netmap это не совсем нововведение.
m2l>>PS. io_uring с ядерной поддержкой TLS ярко контрастирует с тем же QUIC, где всё пытаются наоборот засунуть всё в user-mode. Прямо такие противоположности и отличная тема для священных войн. C>Ну всё правильно, эксперименты лучше проводить в userspace. Недавно допилили до принятого RFC — так что сейчас можно добавлять в ядро.
Вроде не планируют, наоборот относятся как к фиче, что реализацию можно обновлять не трогая ОС.
Здравствуйте, Shmj, Вы писали:
S>Нужно слушать порт, залогировать HTTP-запрос и отдать статический HTTP-ответ не зависимо от параметров запроса. Тащить nginx как бы оверхед.
S>Вопрос такой: как сделать настолько быстрое и незатратное (по ресурсам) решение, насколько это возможно?
Здравствуйте, Shmj, Вы писали:
S>Нужно слушать порт, залогировать HTTP-запрос и отдать статический HTTP-ответ не зависимо от параметров запроса. Тащить nginx как бы оверхед.
S>Вопрос такой: как сделать настолько быстрое и незатратное (по ресурсам) решение, насколько это возможно?
Здравствуйте, Shmj, Вы писали:
S>>>Нужно слушать порт, залогировать HTTP-запрос и отдать статический HTTP-ответ не зависимо от параметров запроса. Тащить nginx как бы оверхед. С>>Возьмите tinyhttpd
S>Все равно оверхед. И не ясно действительно ли он выжимает все.
То, что ты своими ручонками накорябаешь, точно будет менее эффективным
