Внутреннее устройство веб-сервера. Часть 1: От syscalls до WSGI

[Gariks]

Про select рассказал, думал сейчас пойдем в epoll, kqueue, io_uring. Отличное введение.

[endlessAI]

Системные вызовы для мультиплексирования ввода/вывода оставил на следующую часть)

[thereisnocolor]

Python не самый подходящий язык для написания производительного веб-сервера. Хорошая база для понимания, но как сказал оратор выше - без io_uring будет шляпа. Я в свое время тоже пилил свой веб сервер, но потом бросил это дело, ибо реализация ssl и gzip требует годы(в моем случае). Научился только работать с CGI/FCGI. На тестах wrk получил следующее:
wrk -t8 -c1000 -d10s http://127.0.0.1:8080Running 10s test @ http://127.0.0.1:8080  8 threads and 1000 connections  Thread Stats Avg Stdev Max +/- Stdev    Latency 3.30ms 5.07ms 23.33ms 81.93%    Req/Sec 102.38k 7.81k 114.90k 89.25%  8147678 requests in 10.03s, 4.17GB readRequests/sec: 812518.83Transfer/sec: 426.18MB

Дальше руки опустились)

[endlessAI]

Да, цель статьи именно дать базу для понимания. В целом в экосистеме Python в основном и используются asgi-сервера на Python, правда цикл событий обычно uvloop, а там уже Cython и libuv. Но i/o мультиплексируется за счёт epoll, и насколько я знаю, не он является узким местом. Последнее время есть ещё интересные движения в сторону rsgi-серверов на Rust, но в проде ещё не использовал - хватает и текущей производительности, и узкое место не в сервере. Но для веб-серверов общего назначения вроде nginx Python конечно не подойдёт.

812к rps впечатляет, на каком языке писали?

[thereisnocolor]

nasm syscall only + всяческие оптимизации. Был амбициозный проект, который вынул из меня душу, в итоге отложил его в очень долгий ящик.