Следует ли сочетать Nginx с моделью асинхронного программирования, поддерживающей язык?

Question

Я нашел много статей, сравнивающих Nginx и Apache в Интернете. Однако все эти сравнения основаны на стресс-тесте с веб-сервером, на котором выполняется код PHP. Я предполагаю, что это в основном из-за того, что Apache обычно разворачивается с PHP как архитектура LAMP.

В моем понимании Nginx создан для решения проблемы C10K с архитектурой, основанной на событиях. То есть Nginx должен обслуживать M одновременных запросов с N потоками / процессами. Предполагается, что N намного меньше M. Это большое отличие от Apache, которому требуется M потоков / процессов для обслуживания M одновременных запросов.

Для кода PHP модель программирования не является асинхронной. Каждый веб-запрос занимал бы один поток / процесс для PHP для его обработки. Поэтому я не понимаю смысла сравнивать Nginx и Apache с PHP-кодом.

Архитектура Nginx, основанная на событиях, должна превосходить Apache, особенно когда запросы включают операции ввода-вывода. Например, запросы должны объединять результаты нескольких других веб-служб. Для Apache + PHP каждый запрос может занять несколько секунд, просто ожидая завершения операции ввода-вывода. Это будет потреблять много потоков / процессов. Для Nginx это не проблема, если используется асинхронное программирование.

Имеет ли смысл развертывать Nginx с языком, поддерживающим модель асинхронного программирования?

Я не уверен, какой язык программирования может извлечь больше всего из Nginx, но это определенно не PHP.

Answer 1

Прежде всего, nginx не поддерживает выполнение приложений напрямую.Он может обслуживать статические файлы, запросы прокси к любому другому веб-серверу и некоторые другие мелочи.Исторически, nginx стремился обрабатывать многие сетевые соединения, правда, но обоснование было таким: пока apache не ответит на запрос кого-либо по медленному соединению, он ничего не сможет сделать.Apache имеет ограничение по рабочим, поэтому, когда много медленных клиентов, любой новичок должен ждать, пока рабочий завершит передачу и возобновит прием нового запроса.Таким образом, классическая установка - это nginx, принимающий внешние запросы, передающий их на локальный apache;apache обрабатывает запросы и возвращает ответы на nginx для передачи клиентам.Таким образом, apache исключен из обращения с клиентами.

Что касается вопроса и nginx на картинке.В наши дни не так сложно использовать рамки системных событий.Это epoll для Linux, kqueue для FreeBSD и другие.На уровне приложений множество вариантов, например, для Python.Таким образом, все, что вам нужно сделать, это написать приложение с этими платформами, которое 1) обычно помещает вас в асинхронный мир и 2) дает вам возможность создать HTTP-сервис, готовый быть бэкендом для nginx.Вероятно, это то, к чему вы стремитесь.

Итак, c10k, похоже, не является проблемой ни для nginx, ни для приложений, построенных на этих платформах.Примером под рукой является сервер торнадо Friendfeed: написан на python, использует epoll и kqueue в зависимости от системы, легко обрабатывает до 8 Кб, насколько я помню.Были некоторые тесты и запоздалая мысль для дальнейшего масштабирования.

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

Php, кстати, остается актуальным для толчков при массовом развертывании веб-сокетов.Ну хорошо.

Answer 2

Дело в том, что потенциал не имеет значения. PHP - это что-то стандартное для веб-разработки, и то, что люди обычно заботятся о серверах, просто потому, что Ngnix или Apache оптимизированы для работы на неясном языке программирования * в 1001 * раз быстрее, чем другой, не имеет значения, если это не PHP.