> Парсинг HTTP вынужден сканить весь байтовый поток на предмет парсинга параметров заголовков
> и их значений, то есть это парсинг вслепую. В то же
> самое время можно задавать длины полей, и парсинг будет происходить четко
> пошагаво по "меткам"(смещение) , а не сканя каждый байт. Т.е. это
> типичная (де)сериализация с минимальными накладными расходами, а строки там внутри или
> нет, не имеет значения.

1. Поскольку длины полей в uwsgi не выровнены, то их все равно приходится читать по байтам.
2. От строк, которые вы решили просто перепрыгивать по меткам, толку таким образом никакого. Их много и к ним нужно затем как-то обращаться, находиться значения соответствующие ключам. И именно поэтому далее в виртуальную машину пайтона они передаются в виде хэша. И чтобы этот хэш построить - их нужно все равно побайтово просканировать.

Итальянец, Роберто Де Йорис, которого вы процитировали просто заблуждается на счет скорости. Он HTTP парсинга не писал и ничего не тестировал, а теоретизирует.

В любом случае, вся это дискуссия бессмысленна, т.к. клиенты ходят на сервер по HTTP, а не по uwsgi. Поэтому парсить HTTP в любом случае нобходимо. В тестовой кофигурации, никакого второго парсинга не было, как Unit, так и uWSGI общались с клиентом напрямую.

Так что у вас вариант парсить HTTP, а затем парсить uwsgi, или просто один раз парсить HTTP - как было в тесте.