Исходное сообщение
"Выпуск сервера приложений NGINX Unit 1.6" Отправлено Valentin V. Bartenev, 20-Ноя-18 13:24
> Парсинг HTTP вынужден сканить весь байтовый поток на предмет парсинга параметров заголовков > и их значений, то есть это парсинг вслепую. В то же > самое время можно задавать длины полей, и парсинг будет происходить четко > пошагаво по "меткам"(смещение) , а не сканя каждый байт. Т.е. это > типичная (де)сериализация с минимальными накладными расходами, а строки там внутри или > нет, не имеет значения. 1. Поскольку длины полей в uwsgi не выровнены, то их все равно приходится читать по байтам. 2. От строк, которые вы решили просто перепрыгивать по меткам, толку таким образом никакого. Их много и к ним нужно затем как-то обращаться, находиться значения соответствующие ключам. И именно поэтому далее в виртуальную машину пайтона они передаются в виде хэша. И чтобы этот хэш построить - их нужно все равно побайтово просканировать. Итальянец, Роберто Де Йорис, которого вы процитировали просто заблуждается на счет скорости. Он HTTP парсинга не писал и ничего не тестировал, а теоретизирует. В любом случае, вся это дискуссия бессмысленна, т.к. клиенты ходят на сервер по HTTP, а не по uwsgi. Поэтому парсить HTTP в любом случае нобходимо. В тестовой кофигурации, никакого второго парсинга не было, как Unit, так и uWSGI общались с клиентом напрямую. Так что у вас вариант парсить HTTP, а затем парсить uwsgi, или просто один раз парсить HTTP - как было в тесте.