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

[Peter A Leonov <gojpeg@xxxxxxxxx>]

Согласен с вами, к нжинксу можно приделать цги. И можно замудрить так,  
что все будет вполне себе рилтайм. Только, боюсь, это не очень  
интересная задача, раз ребята так противятся самой мысли о ней.
С уважением,
Петр Леонов.
+7 (905) 758-12-73

On 10.01.2009, at 7:26, "Sergey Shepelev" <temotor@xxxxxxxxx> wrote:

> OMFG уважаемые господа, речь шла о таймаутах событийной машины.
> Конект за 10 секунд - что-то произойдет раньше - либо конект, либо 1 
> 0 секунд.
> В nginx есть proxy_connect_timeout. Речь об этом была, йолки.
>
> 2009/1/8 Sergey Bondari <bondari@xxxxxxxxxxx>:
> > Hello Sergey,
> >
> > Мне тоже кажется что вы не понимаете концепции асинхронных событийных
> > приложений. Таймаут там не нужен по такой простой причине что пока 
> >  не пришло
> > событие, делать-то нечего. А чтобы никого не "теребить" и существуют
> > механизмы которые отслеживают события на N ресурсах одновременно.
> >
> > Когда вы попробуете написать событийную машину в которую вы
> > попытаетесь вставить таймаауты и синхронные вызовы вы поймете что это
> > не тривиально. Событийная машина не имеет права застывать на каких-то
> > синхронных вызовах с таймаутом, иначе она теряет свой смысл. Все
> > должно выполняться асинхронно. Асинхронно помещаете в пул запрос,
> > когда принимающая сторона готова к приему, посылаете запрос, когда
> > ответ готов, получаете событие и принимаете ответ. Обрабатываете
> > ответ, скажем, вашим колбэком, т.е. функцией которая висит в пуле
> > вместе с запросом, который вы отправляли.
> >
> >
> > SS> У меня есть некий асинхронный движок. Допустим я по какому-то  
> > внешнему
> > SS> событию (например запуск) хочу подконектиться к другому серверу и
> > SS> послать ему строчку.
> > SS> Для этого я говорю своему асинхронному движку: конектись(адрес 
> > , порт,
> > SS> за 10 секунд).
> > SS> В это время движок делает соответствующий системный вызов... и 
> >  таки
> > SS> да, никаких таймаутов. Но он либо
> > SS>   а) устанавливает еще один колбек от системы - на время 10 се 
> > кунд и
> > SS> ждет какое событие наступит раньше (реализация таймаута)
> > SS>   б) либо периодически очень-очень часто теребит ОС, мол, а не
> > SS> наступило ли там событие. И в процессе этого теребления инкрем 
> > ентит
> > SS> прошедшее время. И опять-таки получается реализация таймаута.
> >
> > SS> Конечно может быть есть еще куча гораздо более лучших способов. Я
> > SS> просто хотел сказать, что если в сисколе select/epoll/etc нет  
> > понятия
> > SS> таймаута - это не значит, что асихнронные приложения их не ждут.
> > SS> Асинхронщина без реализации таймаутов (в любом виде, мне правд 
> > а пофигу
> > SS> на каком уровне и как именно) - бесполезна.
> >
> > SS> 2008/12/31  <postmaster@xxxxxxxxxxxxx>:
> > > > Здравствуйте, Sergey.
> > > >
> > > > Вы не совсем правильно представляете работу асинхронных приложений.
> > > > Они не ждут таймаут, они получают сообщения от ОС и по ним что 
> > > > -то делают.
> > > > > Почитал тред про CGI в nginx, утром обсуждали смежную задачк 
> > > > > у с колегом.
> > > > > Только у меня идея была написать всю асинхронщину на питоне, а в
> > > > > реальной жизни мы используем nginx + fastcgi на питоне.
> > > > > И в общем идея примерно такая.
> > > > > Есть некий слой "А" асинхронной обработки запросов снаружи ( 
> > > > > повторюсь,
> > > > > сейчас его роль офигительно выполняет nginx).
> > > > > "А" знает, что в его распоряжении имеется, скажем 100 бекенд 
> > > > > ов - 100
> > > > > процессов. Думаю, оптимальное количество можно определить для
> > > > > конкретной материнки и проца. (RFC)
> > > > > Приходит внешний запрос от клиента. "А" здесь быстро принима 
> > > > > ет запрос
> > > > > и ищет свободный воркер
> > > > > если есть свободный воркер, (RFC)
> > > > >   помечает его как занятый
> > > > >   асинхронно шлёт запрос ему,
> > > > > (и продолжает работать дальше)
> > > > > если нет свободного воркера
> > > > >    ждем таймаут, если в течение таймаута свободного воркера не
> > > > > появилось - возвращаем клиенту "таймаут" (RFC, кажется, ngin 
> > > > > x именно
> > > > > так и умеет)
> > > > > когда воркер вернул результат
> > > > >    отдаём клиенту,
> > > > >    помечаем воркер как свободный.
> > > > > К этому счастью нужно прикрутить админку бекендов с графиками и
> > > > > полуавтоматическим контроллером пула воркеров, то есть чтоб некий
> > > > > третий процесс контроллировал сколько нужно прибить лишних в 
> > > > > оркеров,
> > > > > сколько нужно открыть новых (RFC).
> > > > > Получится наверно что-то вроде веб-части Google AppEngine.
> > > >
> > > >
> > > > --
> > > > С уважением,
> > > > postmaster                          mailto:postmaster@xxxxxxxxxxxxx
> >
> >
> > --
> > Best regards,
> > Sergey