Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: post_action
- To: nginx-ru@xxxxxxxxx
- Subject: Re: post_action
- From: drmarker <drmarker@xxxxxxxxx>
- Date: Wed, 18 Oct 2006 16:43:45 +0400
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FyfXetOarFkhgnD3wukbKCe9XhND//wIxEfQUonhJkNDNSjI2vbPdWcEoqhdqbkbzMgFqNPgBgNDGbLbbJ7XReWZ06spB/TZQXlxeeMT2icD1EDxHXaoEjEUyqya6fcB6FqCy3zL9LLrWWBJwmEWRW3GyR3Yw96bZ+PlndI3f0o=
- In-reply-to: <20061018141538.80C4.ALEXEY.BELANOV@xxxxxxxxx>
- References: <20061018141538.80C4.ALEXEY.BELANOV@xxxxxxxxx>
Мы в результате всех плясок с бубном вокруг этой проблемы пришли к
выводу, что промежуточных решений нет и надо писать скрипт, который
будет хранить список сессий в memcached/whatever и периодически
верифицировать его по /proc/net/tcp. То есть, например, если
пользователь уперся в лимит, а проверка сессий в /proc/net/tcp была
больше, чем N-секунд назад - проверить еще раз.
Другой вариант - уговорить Игоря таки сделать лимиты (но не просто по
ip, понятное дело). Но это дело бесполезное :)
А любой post_action (хоть и _499) между FE и BE может теряться.
Особенно, если FE и BE разнесены и так далее.
On 10/18/06, Alexey V. Belanov <alexey.belanov@xxxxxxxxx> wrote:
Доброго дня.
Не так давно переключили одну из своих внутренних файлопомоек на работу
с post_action для динамического ограничения скоростей. Ограничивается
скорость на сессию и количество разрешенных сессий на пользователя.
php-шки работают на апаче, сессии хранятся в HEAP mysql таблицах,
memcached пока не получилось внести в существующую идеологию. В общем и
целом все работает как задумывалось за исключением "залипания" сессий. В
рассылке уже писали об этом, но как я понимаю ограничившись банальным
рестартом nginx-а с очисткой активных сессий дело дальше не пошло.
Ситуация же следующая: клиент отправляет запрос на старт очередной
сессии, nginx проксирует запрос на apache, тот какое-то время думает и
отдает ответ (время конечно можно здорово уменьшить использованием
memcached, но это ничего не решит). В это время пользователь по своей
инициативе (проверить просто - забить все место на диске и регетом
стартовать закачку) уже закрыл соединение с nginx, в логах которого
появляется 499 ошибка, но апач сессию стартовал и бекпоста по ней нет.
Сессия залипла.
Вопрос - можно ли предусмотреть бекпост в такой ситуации, для нас это
критично, да наверно и не только для нас. Пусть например будет
дополнительно post_action_499, в любом случае ситуация идет к тому чтобы
сделать это самостоятельно кривым хаком исходников nginx в обработчике
этой ошибки.
--
Alexey V. Belanov <alexey.belanov@xxxxxxxxx>
|
