Re: Re[2]: платформа для REST сервисов
Peter A Leonov
gojpeg at gmail.com
Sat Jan 10 21:38:46 MSK 2009
Согласен с вами, к нжинксу можно приделать цги. И можно замудрить так,
что все будет вполне себе рилтайм. Только, боюсь, это не очень
интересная задача, раз ребята так противятся самой мысли о ней.
С уважением,
Петр Леонов.
+7 (905) 758-12-73
On 10.01.2009, at 7:26, "Sergey Shepelev" <temotor at gmail.com> wrote:
> OMFG уважаемые господа, речь шла о таймаутах событийной машины.
> Конект за 10 секунд - что-то произойдет раньше - либо конект, либо 1
> 0 секунд.
> В nginx есть proxy_connect_timeout. Речь об этом была, йолки.
>
> 2009/1/8 Sergey Bondari <bondari at 1stomni.com>:
>> 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 at softsearch.ru>:
>>>> Здравствуйте, Sergey.
>>>>
>>>> Вы не совсем правильно представляете работу асинхронных приложений.
>>>> Они не ждут таймаут, они получают сообщения от ОС и по ним что
>>>> -то делают.
>>>>
>>>>> Почитал тред про CGI в nginx, утром обсуждали смежную задачк
>>>>> у с колегом.
>>>>> Только у меня идея была написать всю асинхронщину на питоне, а в
>>>>> реальной жизни мы используем nginx + fastcgi на питоне.
>>>>
>>>>> И в общем идея примерно такая.
>>>>> Есть некий слой "А" асинхронной обработки запросов снаружи (
>>>>> повторюсь,
>>>>> сейчас его роль офигительно выполняет nginx).
>>>>> "А" знает, что в его распоряжении имеется, скажем 100 бекенд
>>>>> ов - 100
>>>>> процессов. Думаю, оптимальное количество можно определить для
>>>>> конкретной материнки и проца. (RFC)
>>>>> Приходит внешний запрос от клиента. "А" здесь быстро принима
>>>>> ет запрос
>>>>> и ищет свободный воркер
>>>>> если есть свободный воркер, (RFC)
>>>>> помечает его как занятый
>>>>> асинхронно шлёт запрос ему,
>>>>> (и продолжает работать дальше)
>>>>> если нет свободного воркера
>>>>> ждем таймаут, если в течение таймаута свободного воркера не
>>>>> появилось - возвращаем клиенту "таймаут" (RFC, кажется, ngin
>>>>> x именно
>>>>> так и умеет)
>>>>> когда воркер вернул результат
>>>>> отдаём клиенту,
>>>>> помечаем воркер как свободный.
>>>>
>>>>> К этому счастью нужно прикрутить админку бекендов с графиками и
>>>>> полуавтоматическим контроллером пула воркеров, то есть чтоб некий
>>>>> третий процесс контроллировал сколько нужно прибить лишних в
>>>>> оркеров,
>>>>> сколько нужно открыть новых (RFC).
>>>>
>>>>> Получится наверно что-то вроде веб-части Google AppEngine.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> С уважением,
>>>> postmaster mailto:postmaster at softsearch.ru
>>>>
>>>>
>>>>
>>
>>
>>
>>
>> --
>> Best regards,
>> Sergey
>>
>>
>>
More information about the nginx-ru
mailing list