Сообщение Re[5]: Про HTTP-сервер для Unix на основе сокетов от 26.01.2022 6:32
Изменено 26.01.2022 6:46 m2l
Re[5]: Про HTTP-сервер для Unix на основе сокетов
Здравствуйте, 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 операцию закрытия хендлов — совсем не оправдано.
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 — так что сейчас можно добавлять в ядро.
Вроде не планируют, наоборот относятся как к фиче, что реализацию можно обновлять не трогая ОС.
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 операцию закрытия хендлов — совсем не оправдано.
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 — так что сейчас можно добавлять в ядро.
Вроде не планируют, наоборот относятся как к фиче, что реализацию можно обновлять не трогая ОС.
Re[5]: Про HTTP-сервер для Unix на основе сокетов
Здравствуйте, 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 — так что сейчас можно добавлять в ядро.
Вроде не планируют, наоборот относятся как к фиче, что реализацию можно обновлять не трогая ОС.
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 — так что сейчас можно добавлять в ядро.
Вроде не планируют, наоборот относятся как к фиче, что реализацию можно обновлять не трогая ОС.