Вторая серия уже вышла: kzfaq.info/get/bejne/Y9Fpe81pp5fYaYE.html

В данном тесте по большей части фактически 4 раза протестировали производительность PHP. По сравнению с работой интерпретатора, все остальное занимает незначительное количество времени. Пытаться же выяснить разницу в сетевой части с помощью утилиты "ab", которая для обработки соединений использует всего один поток с select() и заведомо работает с соединениями медленнее - дело бессмысленное. Для правильного измерения эффективности сетевой части сервера - клиент должен обладать на порядок большей производительностью, дабы не вносить искажений и своих собственных задержек в тест. В противном случае можно наткнуться на смешные аномалии. Я в своей практике видел как включение (!) access_log-ов в nginx увеличивало (!) RPS в тесте. Детальное изучение той аномалии показало, что включение записи в лог на каждый запрос подтормаживает обработку запроса ровно настолько, насколько требуется чтобы медленный "ab" успел прислать следующий запрос и таким образом рабочий процесс nginx не успевал провалиться в ядро ждать на epoll_wait(), что в результате оказывалось эффективнее даже не смотря на дополнительный вызов write(). Все сервера прекрасно работают когда соединений не больше 100 - это не представляет какой-либо сложности, плюс-минус несколько процентов не играют роли и могут быть особенностью конкретного теста и настроек, особенностью комбинации поведений клиента и сервера по работе с соединениями. Но что толку, если когда к вам придет 1000+ пользователей ваш сервер ляжет? Именно в этом фишка Unit-а с точки зрения производительности, что в отличие от остальных ему без разницы 16 соединений или 100000+. Производительность Unit-а не просаживается с ростом числа соединений. Наглядный пример: itnext.io/performance-comparison-between-nginx-unit-and-uwsgi-python3-4511fc172a4c Что касается unix-сокетов, то Unit нет большой необходимости ставить за локальным nginx-ом. Он сам прекрасно умеет работать с сетью, а поэтому ему дополнительный слой локального проксирования и unix-сокеты не нужны (хотя рудиментарная поддержка их есть, см: github.com/nginx/unit/issues/61 ). Поэтому эта задача не в приоритете. Начальная поддержка TLS уже есть, добавится HTTP/2, разные настройки и Unit практически не будет уступать nginx-у по сетевым возможностям.

Шикарный тест. Респект! Спасибо. Мы как раз большую часть проектов на php-fpm перевели с unix-сокетами.

Здорово! Побольше подобного материала!

Спасибо за интересные материалы. До этого мне ничего не было известно про Nginx Unit и стало интересно. Сразу выяснилось, что с недавних пор под ним можно запускать node.js (пишу под ноду). И это мне не до конца понятно. Зачем Nginx будет перенаправлять запрос на Nginx Unit, который запустит node.js, если Nginx может сразу перенаправлять на node.js? Поясните пожалуйста, если Вас не затруднит.

Готова вторая версия теста, с уточнениями и доработками, скоро на канале!

Какие изменения вносились в конфиг Апача?

Никак не могу найти причину. Nginx нагружает процессор на 100% при 25 посетителях на сайте по тесту loadimpact. Конфигурация VPS 1 CPU 2.4 GHZ, 1GB RAM 30GB SSD. На чистую Debian 9 c стандартными репозиториями установлена панель Vestacp с минимальным набором: Nginx+php-fpm+Mysql. Все конфиги по дефолту. Движок сайта DLE тоже из коробки. На что обратить внимание? Так ведь не должно быть? Сайт дико тупит при 10-25 одновременных посетителях. Помогите пожалуйста разобраться, перешел с шаред хостинга. А стало еще хуже чем было.

Я начинающий, не могу понять одну вещь. Если nginx быстрее чем Apache то почему Apache вообще используется? Есть ли у Apache преимущества перед nginx?

Спс за тест. А пробовали патч от cloudflare - blog.cloudflare.com/optimizing-tls-over-tcp-to-reduce-latency/ ? Есть смысл? Если да - то будет преимущество в десятках или сотнях миллисекундах для TTFB ? )

надо сравнивать Nginx c PHP-FPM и Apache с PHP-FPM. тест некорректен.