Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: платформа для REST сервисов
- To: nginx-ru@xxxxxxxxx
- Subject: Re: платформа для REST сервисов
- From: "Sergey Shepelev" <temotor@xxxxxxxxx>
- Date: Wed, 31 Dec 2008 04:01:22 +0300
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=W9i6uZ9urBXjUBxqYQ9TPKZ7O1az1HeZPRLLZeuQ11Y=; b=fRsRvpjkrhWTgfjwkXapsJTjU3LowfzYt0E3SojvVd0CpysByPm0elwRyONQ7QNC+5 kM2GG4Cfv4aMnVsFERlCIEY/CpQ2Afcxe7RzuzOh4ybA9SNz4FDjTTy2S8/KPVzZ+Vf/ 9o8glE6Qygk8lldz6oLhBdxnFsENGBuJbHEvs=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=LYVOkWd6KZvhjnD9dRLMMYKIG4/MDIiQ8gkp5cjkFSNv0aM4UauIN+dS/mfk3D/JhG X/6pvxaCkQtB1mdtsNDQZYFoc1omo8uG02SAXnlZMqPAmFEUcZUuGZuqse9EPLljsjcO WHavtvExa/H4OCDdPEPBBoFrE160I3mPez9WE=
- In-reply-to: <495AA711.9030602@xxxxxxx>
- References: <2d8fb9950812301424t5a8aaa40k975c2cf08d318abd@xxxxxxxxxxxxxx> <495AA711.9030602@xxxxxxx>
Если апстримом называют nginx, то, еще получается нужно как-то
отслеживать на каких апстримах запрос уже был, потому что следущий
может кинуть запрос обратно на первый.
2008/12/31 Kostya Alexandrov <koticka@xxxxxxx>:
> Да, было бы интересно, еслиб в апстриме можно былобы конфигурировать
> максимальное количество
> одновременных запросов. При привышении которого либо busy либо след апстрим
> - конфигурабельно.
>
> Sergey Shepelev wrote:
>>
>> Добрый новый год.
>>
>> Почитал тред про CGI в nginx, утром обсуждали смежную задачку с колегом.
>> Только у меня идея была написать всю асинхронщину на питоне, а в
>> реальной жизни мы используем nginx + fastcgi на питоне.
>>
>> И в общем идея примерно такая.
>> Есть некий слой "А" асинхронной обработки запросов снаружи (повторюсь,
>> сейчас его роль офигительно выполняет nginx).
>> "А" знает, что в его распоряжении имеется, скажем 100 бекендов - 100
>> процессов. Думаю, оптимальное количество можно определить для
>> конкретной материнки и проца. (RFC)
>> Приходит внешний запрос от клиента. "А" здесь быстро принимает запрос
>> и ищет свободный воркер
>> если есть свободный воркер, (RFC)
>> помечает его как занятый
>> асинхронно шлёт запрос ему,
>> (и продолжает работать дальше)
>> если нет свободного воркера
>> ждем таймаут, если в течение таймаута свободного воркера не
>> появилось - возвращаем клиенту "таймаут" (RFC, кажется, nginx именно
>> так и умеет)
>> когда воркер вернул результат
>> отдаём клиенту,
>> помечаем воркер как свободный.
>>
>> К этому счастью нужно прикрутить админку бекендов с графиками и
>> полуавтоматическим контроллером пула воркеров, то есть чтоб некий
>> третий процесс контроллировал сколько нужно прибить лишних воркеров,
>> сколько нужно открыть новых (RFC).
>>
>> Получится наверно что-то вроде веб-части Google AppEngine.
>>
>
>
|
