> Вот нагуглил:
> https://www.digitalocean.com/community/tutorials/how-to-serv... [..]
> Соответственно, как я писал выше, тесты можно считать недействительными если использовался
> TCP сокет. Более странно, раз уж вы занимаетесь такими вещами, то
> не можете не знать, как взаимодействовать с uWSGI наиболее производительным способом.
> Если вы знаете это, то тогда почему этот способ не использовался?
Отмечу несколько моментов:
1. Ни я, ни кто-либо из моих коллег не имеет к статье и её автору никакого отношения. Насколько я понимаю, человек каждый день в своей практике использует uWSGI, а тут увидел Unit и решил его сравнить.
2. Протокол uwsgi и unix-сокеты между собой не связаны. Взаимодействие с использованием uwsgi протокола nginx умеет как поверх TCP, так и поверх unix-сокетов.
3. Поскольку в данном тесте nginx вообще отсутствовал, то говорить о том, как и по какому протоколу он с ним общался - лишено смысла. Браузеры на сервер приходят не по unix-сокету и не по uwsgi протоколу.
4. Даже если бы nginx использовался, то ни uwsgi, ни unix-сокеты никак не повлияли бы на ситуацию. TCP через loopback интерфейс - это весьма эффективный механизм, мало уступающий unix-сокетам. А бинарного в протоколе uwsgi - только длины имен и значений CGI-переменных (которые сами по себе по прежнему суть текстовые заголовки) и за счет этого он всего пару процентов может выиграть у HTTP. Но вообще на сам парсинг во всей обработке запроса приходится меньше процента - это ничтожная по ресурсам операция на фоне работы виртуальной машины cpython, так что разница была бы практически неизмерима.
5. Именно потому, что мы прекрасно понимаем и знаем досконально как всё это работает, мы видим огромный ещё нераскрытый потенциал сделать масштабируемый сервер, который лучше других держит высокие нагрузки. И если бы это было не так, то мы бы сейчас не писали Unit, а занимались более перспективными задачами. И даже данный бенчмарк не показатель, а лишь отправная точка. Ещё не всё даже реализовано так, как хотелось бы.
