ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Да, было бы интересно, еслиб в апстриме можно былобы конфигурировать максимальное количество одновременных запросов. При привышении которого либо busy либо след апстрим - конфигурабельно.

Sergey Shepelev wrote:
Добрый новый год.

Почитал тред про CGI в nginx, утром обсуждали смежную задачку с колегом.
Только у меня идея была написать всю асинхронщину на питоне, а в
реальной жизни мы используем nginx + fastcgi на питоне.

И в общем идея примерно такая.
Есть некий слой "А" асинхронной обработки запросов снаружи (повторюсь,
сейчас его роль офигительно выполняет nginx).
"А" знает, что в его распоряжении имеется, скажем 100 бекендов - 100
процессов. Думаю, оптимальное количество можно определить для
конкретной материнки и проца. (RFC)
Приходит внешний запрос от клиента. "А" здесь быстро принимает запрос
и ищет свободный воркер
если есть свободный воркер, (RFC)
   помечает его как занятый
   асинхронно шлёт запрос ему,
(и продолжает работать дальше)
если нет свободного воркера
    ждем таймаут, если в течение таймаута свободного воркера не
появилось - возвращаем клиенту "таймаут" (RFC, кажется, nginx именно
так и умеет)
когда воркер вернул результат
    отдаём клиенту,
    помечаем воркер как свободный.

К этому счастью нужно прикрутить админку бекендов с графиками и
полуавтоматическим контроллером пула воркеров, то есть чтоб некий
третий процесс контроллировал сколько нужно прибить лишних воркеров,
сколько нужно открыть новых (RFC).

Получится наверно что-то вроде веб-части Google AppEngine.



 




Copyright © Lexa Software, 1996-2009.