Имеем демона, изображающего из себя fastcgi сервер c предварительым ветвлением.
Используется модуль FCGI.
Через функцию FCGI::Request получаю хэндлер для обработки запросов.
Можно ли как то узнать кол-во запросов в очереди?
Цель: демон диспетчер должен наплодить потомков, обрабатывающих запросы, в необходимом кол-ве в зависимости от "нагрузки".
Считать кол-во запросов в единицу времени мне кажется не самая правильная идея.
Ну или пните в нужном направлении?
спасибо

Кроссплатформенно - скорее всего, никак. 

Но подход сам по себе неправильный. Непринятые соединения - это нормально, backlog сокета для этого и существует. Всё равно какие-то лимиты на кол-во процессов должно быть, иначе вас заDOS'ят простыми пустыми подключениями. Обычно делается так: создаётся фиксированный пул N процессов (10 шт, 2*кол-во процессоров, какая-то ещё константа, определите сами для наилучшей утилизации процессора). При малой нагрузке часть из них может простаивать - но если не жалко памяти, то это не страшно. При большой нагрузке, переполняющий очередь, фронтенд увидит "connection refused" и дальше решает, что отдать клиенту.

Другой вариант - диспетчер может выдёргивать соединения из очереди сразу, сколько бы их ни было, и держать внутреннюю очередь на обработку (по сути, повторения работы ОС). В этом варианте, какую ошибку вернуть при большой нагрузке, решает диспетчер.

Разработка под *nix.
Фронтедом выступает nginx.
Ничего не мешает мне ограничить сверху кол-во потомков. 
Да, иметь при старте 20 потомков и ни о чем не думать тоже хорошо. Но не оптимально. И я пока не до конца понял вашу мысль, какой именно момент в моих описанных условиях некорректен? 

Даже внутри *nix не знаю переносимого способа. Под линукс, вроде бы, можно что-то найти в /proc, но не уверен.

А в чём проблема с 20 потоками? Грузите все библиотеки _до_ форка, и накладыне расходы будут минимальными - только на реально меняющиеся данные.

PS: я не говорил про некорректность, а про то, что ничего плохого в очереди соединений нет. Все ресурсы конечны, больше N одновременно всё равно не обработать.

Сузим ОС до Linux
Давайте переведем разговор от целесообразности иметь динамически изменяемое кол-во потомков, к идеи о том как это сделать?
Размышляя над этим вопросом я пришел к мысли что один из вариантов, это знать насколько велика очередь.
Вариант ручного управления (послать сигнал диспетчеру), после чего тот инкрементирует кол-во потомков это немного другое.

Может стоит сменить подход к решению задачи?

Посмотрите на апач. Классика. 4 параметра:
1. стартовое количество процессов
2. максимальное количество процессов
3. максимальное количество простаивающих процессов - если их больше в момент проверки, убиваем лишние
4. минимальное количество простаивающих процессов - если их меньше в момент проверки, создаём заранее новый

И проверка с какой-либо переодичностью. Не надо знать о длине очереди. Эта схема позволяет не держать лишних обработчиков, и, в то же время, реагировать на возросшую нагрузку. Главное - аккуратно ограничить максимум.

DurRandir, спасибо, но это все не то. Я пока в целях самообразования хочу решить именно поставленную задачу. 
Возможности апача мне известны. По религиозным убеждениям есть желание найти ему альтернативу. Посмотреть разницу в работе в реальном проекте, под нагрузкой которую не дают синтетические тесты.
Вы же мне предлагаете все время другое решение 

kavkaz, поясните, как Вы представляете работу Вашего менеджера? Предложения DurRandirа, выглядят вполне подходящими для Вашей задачи. Он не предлагал использовать Apache, а только обратил внимание на алгоритм обработки запросов.

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

Я знаю как замерить время непосредственной обработки запроса; имею ввиду:

Но ведь это не то время, которое ждет клиент. 
Какие события мне могут указать что сервер "загружен" и работает на пределе?
Мерить load average мне кажется тоже не даст искомого ответа. 

Для меня эта задача вновинку, литература пока дает ответы на общие вопросы "как вообще написать свой сервер", а таких тонкостей там не найдешь. Если есть объективные причины того, что это вприницпе нетривиально и решение больше будет похоже на хак, то может я и успокоюсь на мысли, что посылать вручную сигналы на увеличение/уменьшение потомков. 

Засела мысль, что запускать сервер с большим кол-вом потомков сразу – это неразумно, все таки гибкость не помешает, как никак это, пусть и жалкая, но пародия на работу апача, а он вроде как такие финты умеет
 

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

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

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

Очередь запросов должна обрабатываться на уровне nginx в любом случае, так что её длину Вы не узнаете.



Это сообщение отредактировал(а) mvsgt - 27.1.2010, 02:46

Я и пытаюсь объяснить, что "видит эту ситуацию" = отсутствие свободных воркеров более-менее длительное время. Привёл пример как это сделано и хорошо работает в апаче. А вы всё хотите смотреть на какие-то странные параметры.