HTTP/FastCGI сервер с поддержкой параллельного исполнения запросов

в качестве более общего вопроса: интересуют системы с открытым кодом, которые бы позволяли обрабатывать достаточно плотный трафик CGI запросов при этом с хорошей масштабируемостью всей системы. порядок трафика - от сотни до тысячи запросов в секунду. причём что каждый запрос сам по себе может исполняться достаточно долго, допустим, десять секунд.

// wbr

>рассмотрены были Apache 1.3.x + mod_fastcgi и последний NGINX и оба обрабатывают FastCGI запросы строго последовательно. причём для mod_fastcgi было явно сказано, что он не умеет сериализовать запросы в пределах одного соединения :(

aptitude install libapache2-mod-fcgid

классический mod_fastcgi устарел морально

>соединения с рабочим сервером (сериализовать CGI запросы).

нет, всё же я ничего не понял... что такое "рабочий сервер" и "сериализация"?

java захавала чей-то мозг и теперь он использует всякие термины типа сериализации?

cgi скрипт открывает сокеты и много потоков и шлёт дофига запросов куда угодно

> java захавала чей-то мозг и теперь он использует всякие термины типа сериализации?

Термин "сериализация" был придуман задолго до Java. К тому он же используется здесь в другом значении :)

> нет, всё же я ничего не понял... что такое "рабочий сервер" и "сериализация"?

в трёх словах, как работает исполнение CGI запроса через FastCGI:

участники сцены - это WEB сервер [допустим Apache] и рабочий сервер aka сервер обработки запросов. это два различных процесса, которые взаимодействуют друг с другом через какой-то коммуникационный канал. в качестве оного обычно выступает TCP или UDS соединение.

сервер обработки при запуске регистрирует канал и переходит в режим ожидания соединения.

WEB сервер принимает POST/GET HTTP запрос, понимает, что это CGI запрос и на основании своей конфигурации находит, какой из внешних рабочих серверов отвечает за обработку этого запроса. он подключается к указанному каналу - устанавливает TCP/UDS соединение - и передаёт стандартные переменные среды окружения CGI скрипта и данные POST запроса [если есть] в виде серии пакетов, формат которых определяется протоколом FastCGI.

после эдакой вот маршализации параметров CGI запроса удалённому серверу WEB сервер ожидает от него ответа на свой запрос. ответ от сервера обработки аналогично передаётся в виде серии FastCGI пакетов, в которых указано как исполнился запрос - успешно/ошибка - и данные, которые бы обычный CGI скрипт выдал на stdout/stderr. получив ответные пакеты, WEB сервер формирует HTTP ответ и отправляет его в свою очередь клиенту. на этом обработка единичного CGI запроса завершается.

дальше уже идут тонкости. WEB сервер может устанавливать соединение с сервером обработки лишь на время обработки каждого CGI запроса aka обрывать его после единичной обработки, а может и поддерживать соединение постоянно для уменьшения время реакции.

если WEB сервер поддерживает постоянное соединение с сервером обработки запросов, то протоколом FastCGI предусмотрена возможность параллельного исполнения нескольких CGI запросов. каждый FastCGI пакет содержит в себе числовой идентификатор запроса, который как-то назначается WEB сервером. этот идентификатор должен быть уникален в данный момент времени в пределах соединения.

ответы, формируемые сервером обработки должны содержать в себе тот-же идентификатор, который был получен в запросе чтобы WEB сервер мог соотнести пары запрос/ответ.

схема простая: WEB сервер получает десять одновременных CGI запросов. он формирует внутри себя десять внутренних CGI сессий, назначая каждой из них свой идентификатор. дальше он сразу посылает весь десяток CGI запросов на исполнение удалённому серверу, указывая в пакетах каждого его собственный идентификатор. после WEB сервер ожидает десяток ответов и по полученным в ответах идентификаторам соотносит их с той или иной внутренней сессией.

этот механизм я и называю сериализацией FastCGI запросов WEB-сервером. в противовес схеме, когда WEB сервер получив очередной CGI запрос посылает его серверу обработки и явным образом дожидается от него ответа на посланный запрос, не обрабатывая при этом другие CGI запросы. в этом случае хотя всё и идёт через одну трубу, но обрабатывается строго последовательно. что по понятным причинам не может не сказаться на пропускной способности такой системы :-/

// wbr

> этот механизм я и называю сериализацией FastCGI запросов WEB-сервером

Сериализация - это сведение параллельного выполнения к последовательному. В твоем примере сериализация - это как раз вторая схема. AFAIK первую обычно называют batching.

ps: впрочем, свою острую актуальность вопрос несколько растерял час назад, бо оказалось, что гораздо проще и эффективнее написать свой целевой HTTP front-end и не связываться с монстрами и мамонтами типа FastCGI. однако, я бы все равно с интересом выслушал мнения 3d party.

// wbr

> Сериализация - это сведение параллельного выполнения к последовательному. В твоем примере сериализация - это как раз вторая схема. AFAIK первую обычно называют batching.

да, кстати, batching в моём случае будет звучать гораздо уместнее, спасибо.

// wbr

достаточно трезво.

хотя существует достаточно много ресурсоёмких (по времени) публичных хттп-сервисов (скажем поиск повторяющихся последовательностей в белках), где получив запрос, сервер возвращает ид запроса и просит "зайти попозже" за результатом. т.е. в принципе, вместо одного жирного получаем много худых запросов - некий поллинг. схема очень простая - может стоит не постеснятся ею воспользоваться?