Re: платформа для REST сервисов

[Sergey Shepelev]

Если апстримом называют nginx, то, еще получается нужно как-то
отслеживать на каких апстримах запрос уже был, потому что следущий
может кинуть запрос обратно на первый.

2008/12/31 Kostya Alexandrov <koticka at mail.ru>:
> Да, было бы интересно, еслиб в апстриме можно былобы конфигурировать
> максимальное количество
> одновременных запросов. При привышении которого либо busy либо след апстрим
> - конфигурабельно.
>
> Sergey Shepelev wrote:
>>
>> Добрый новый год.
>>
>> Почитал тред про CGI в nginx, утром обсуждали смежную задачку с колегом.
>> Только у меня идея была написать всю асинхронщину на питоне, а в
>> реальной жизни мы используем nginx + fastcgi на питоне.
>>
>> И в общем идея примерно такая.
>> Есть некий слой "А" асинхронной обработки запросов снаружи (повторюсь,
>> сейчас его роль офигительно выполняет nginx).
>> "А" знает, что в его распоряжении имеется, скажем 100 бекендов - 100
>> процессов. Думаю, оптимальное количество можно определить для
>> конкретной материнки и проца. (RFC)
>> Приходит внешний запрос от клиента. "А" здесь быстро принимает запрос
>> и ищет свободный воркер
>> если есть свободный воркер, (RFC)
>>   помечает его как занятый
>>   асинхронно шлёт запрос ему,
>> (и продолжает работать дальше)
>> если нет свободного воркера
>>    ждем таймаут, если в течение таймаута свободного воркера не
>> появилось - возвращаем клиенту "таймаут" (RFC, кажется, nginx именно
>> так и умеет)
>> когда воркер вернул результат
>>    отдаём клиенту,
>>    помечаем воркер как свободный.
>>
>> К этому счастью нужно прикрутить админку бекендов с графиками и
>> полуавтоматическим контроллером пула воркеров, то есть чтоб некий
>> третий процесс контроллировал сколько нужно прибить лишних воркеров,
>> сколько нужно открыть новых (RFC).
>>
>> Получится наверно что-то вроде веб-части Google AppEngine.
>>
>
>