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

[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