LINUX.ORG.RU

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


0

0


есть WEB сервер A который принимает HTTP/POST запросы на исполнение неких заданий. есть рабочий сервер B, которые эти задания исполняет. общение между WEB и рабочим серверами организовано через протокол FastCGI (http://www.fastcgi.com).

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

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

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

кто-нибудь знает открытый сервер, который бы это умел?

// wbr


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

// wbr

klalafuda ★☆☆
() автор топика

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

aptitude install libapache2-mod-fcgid

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

Pi ★★★★★
()

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

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

Pi ★★★★★
()

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от Pi

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

в трёх словах, как работает исполнение 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

klalafuda ★☆☆
() автор топика
Ответ на: комментарий от klalafuda

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

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

tailgunner ★★★★★
()


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

// wbr

klalafuda ★☆☆
() автор топика
Ответ на: комментарий от tailgunner

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

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

// wbr

klalafuda ★☆☆
() автор топика
Ответ на: комментарий от klalafuda

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

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

Pi ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.