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

["Sergey Shepelev" <temotor@xxxxxxxxx>]

Боже мой, неужели я настолько не умею выражать свои мысли...

Речь о CGI в nginx в другом треде. Мне это совсем-совсем не надо. Если
что-то близкое надо - так это спавнить FastCGI. Но и этого мне не
надо, это умеет соответствующий софт.

Здесь я попросил покоментировать схему раздачи синхронным бекендам
работы с асинхронного фронтенда. С удобным управлением бекендами.
Никто никого не пытается заменить. Никаких новых модулей к чему-либо.
Просто схема.

2009/1/10 Peter A Leonov <gojpeg@xxxxxxxxx>:
> Согласен с вами, к нжинксу можно приделать цги. И можно замудрить так, что
> все будет вполне себе рилтайм. Только, боюсь, это не очень интересная
> задача, раз ребята так противятся самой мысли о ней.
>
> С уважением,
> Петр Леонов.
> +7 (905) 758-12-73
>
> On 10.01.2009, at 7:26, "Sergey Shepelev" <temotor@xxxxxxxxx> wrote:
>
>> OMFG уважаемые господа, речь шла о таймаутах событийной машины.
>> Конект за 10 секунд - что-то произойдет раньше - либо конект, либо 10
>> секунд.
>> В 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, кажется, nginx именно
>>>>>> так и умеет)
>>>>>> когда воркер вернул результат
>>>>>>   отдаём клиенту,
>>>>>>   помечаем воркер как свободный.
>>>>>
>>>>>> К этому счастью нужно прикрутить админку бекендов с графиками и
>>>>>> полуавтоматическим контроллером пула воркеров, то есть чтоб некий
>>>>>> третий процесс контроллировал сколько нужно прибить лишних воркеров,
>>>>>> сколько нужно открыть новых (RFC).
>>>>>
>>>>>> Получится наверно что-то вроде веб-части Google AppEngine.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> С уважением,
>>>>> postmaster                          mailto:postmaster@xxxxxxxxxxxxx
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Sergey
>>>
>>>
>>>
>