Как ограничить число одновременных запросов с помощью nginx?

Question

[Александр]

Подскажите, как с помощью nginx (либо какого-то другого инструмента) сделать так, чтобы запросы, приходящие с одного и того же ip-адреса, ставились в очередь и каждый следующий запрос передавался бы на обработку php-fpm (или любому другому серверу, стоящему за nginx) только после окончания обработки предыдущего? Я смотрел nginx.org/en/docs/http/ngx_http_limit_req_module.html, но мне это не совсем подходит, т.к. он работает по принципу ограничения количества одновременных запросов по времени. А мне нужно, чтобы вне зависимости от времени исполнения, все запросы с одного и того же ip ставились в очередь, и последующий запрос начинал обрабатываться только после того, как закончится обработка предыдущего.
Поэтому прошу или предложить какие-то готовые альтернативы ngx_http_limit_req_module, которые решают мою задачу, или указать, как именно надо настроить ngx_http_limit_req_module, чтобы задача решалась в той формулировке, которую я написал выше.

Comments

[sim3x]

те пользователь создал 100 запросов, ему ngx выдал неполную страницу, пользователь закрыл твой сайт, браузер, а ты все продолжаешь обрабатывать его запросы?

[Александр]

sim3x: Нет, я бы хотел, чтобы при разрыве соединения браузером, такие запросы удалялись из очереди.

[Илья Ерохин]

Вряд ли вы найдете то что ищете. Веб так не работает. К тому же иногда целые города сидят через один IP.

А если не секрет, зачем это нужно?

[Александр]

Илья Ерохин: Как "так" не работает веб? Я же в своем вопросе указал на модуль nginx который _уже ставит в очередь запросы_, но только те, что не умещаются в заданный интервал времени. Мне просто нужно немного изменить условия.
IP это просто пример. Можно ведь сделать условие IP + какой-то заголовок для большей уникальности. Так что это не является проблемой.
Зачем это нужно, честно говоря, долго объяснять. А то тема обсуждения может съехать в ненужную сторону.

[Илья Ерохин]

Александр:

> Как "так" не работает веб? Я же в своем вопросе указал на модуль nginx который _уже ставит в очередь запросы_, но только те, что не умещаются в заданный интервал времени.

Это - просто ограничение на потребление ресурсов бекендом. Вы же описываете абсолютно другой кейс.

> Можно ведь сделать условие IP + какой-то заголовок для большей уникальности.

Можно, например хеш по (ip+UserAgent+etc..)

> Мне просто нужно немного изменить условия.

Можете форкнуть этот модуль nginx, и дописать фичу. Или же можете повесить между nginx и php дополнительную прокладку, написанную например на Ноде, асинхронном Питоне или go.

Могу кстати написать такую штуку на Ноде или асинхронном Питоне за умеренную плату, если интересно.

[Александр]

Илья Ерохин: >> Вы же описываете абсолютно другой кейс
Ну где же другой кейс? Посмотрите, пожалуйста, внимательно описание модуля ngx_http_limit_req_module. Если я поставлю rate=1r/s, то мое условие уже будет выполняться, только нужна одна маленькая поправка - нужно, чтобы если запрос выполнился менее, чем за секунду, сервер не ждал, а начинал выполнять следующий запрос.

>> Можно, например хеш по (ip+UserAgent+etc..)
Спасибо, я знаю

>> Можете форкнуть этот модуль nginx, и дописать фичу.
>> Или же можете повесить между nginx и php дополнительную прокладку
Оу, оу) Сразу форкать nginx - зачем же так жестоко?) Это понятно, что можно написать все что угодно. Я _уже_ накидал вариант такой "прокладки" на стороне моего backend'a. Но очень не хочется городить огород, т.к. я всегда считал, что каждой задаче свой инструмент. И мне кажется, что обратный прокси-сервер (т.е., nginx) это и есть тот инструмент, прямой задачей которого является управление запросами, прежде, чем они попадут на основной backend-сервер. И по моему скромному мнению, делает подобные вещи он гораздо эффективнее любой прокладки, т.к. заточен под это.

>> Могу кстати написать такую штуку на Ноде или асинхронном
>> Питоне за умеренную плату, если интересно.
Я тоже могу написать такую (и не только такую) штуку за умеренную плату, если интересно =)
Но вопрос стоит именно "как стандартными Linux-инструментами из коробки решить задачу".

[Илья Ерохин]

Александр:

> Ну где же другой кейс? Посмотрите, пожалуйста, внимательно описание модуля ngx_http_limit_req_module. Если я поставлю rate=1r/s, то мое условие уже будет выполняться, только нужна одна маленькая поправка

Как я писал выше - это не маленькая поправка, это абсолютно другая логика. Читайте внимательнее.

> Оу, оу) Сразу форкать nginx - зачем же так жестоко?)

Затем, что у вас явно какое-то неудачное решение, и за вас его еще никто не решил.

> И мне кажется, что обратный прокси-сервер (т.е., nginx) это и есть тот инструмент, прямой задачей которого является управление запросами, прежде, чем они попадут на основной backend-сервер. И по моему скромному мнению, делает подобные вещи он гораздо эффективнее любой прокладки, т.к. заточен под это.

Ага, Сысоев конечно же из коробки заложил в nginx все вообще в природе возможные анти-паттерны.

> Я тоже могу написать такую (и не только такую) штуку за умеренную плату, если интересно =)

Ну так чего время терять?

> Но вопрос стоит именно "как стандартными Linux-инструментами из коробки решить задачу".

Я уже ответил выше - никак. Никто такой ерундой до вас не занимался. Хотите решить свою частную задачу - пишите код.

[Александр]

Илья Ерохин: >> Как я писал выше - это не маленькая поправка,
>> это абсолютно другая логика
Ну, если для вас кейс "выполнить запрос -> подождать N миллисекунд -> выполнить следующий запрос из очереди" это абсолютно другая логика в сравнении с "выполнить запрос -> выполнить следующий запрос из очереди", то спорить тут бесполезно.

>> Затем, что у вас явно какое-то неудачное решение
Пожалуйста, позвольте мне самому решать, удачное у меня решение или нет.

>> Никто такой ерундой до вас не занимался
Если вы считаете сабж ерундой, зачем заходить в него и писать очевидные вещи, не имеющие отношения к сути вопроса? Поверьте, если я спрашиваю про решение с помощью существующих средств, то я уж как-нибудь догадался, что можно написать свой велосипед, и теперь меня интересует возможность избежать этого велосипедостроения. Если вы не знаете решения, лучше просто ничего не отвечать.

[Илья Ерохин]

> Ну, если для вас кейс "выполнить запрос -> подождать N миллисекунд -> выполнить следующий запрос из очереди" это абсолютно другая логика в сравнении с "выполнить запрос -> выполнить следующий запрос из очереди", то спорить тут бесполезно.

Вы бы слушали иногда собеседника, может быть бы и поняли чего полезное.

1) установить таймер - выполнить - посмотреть таймер - подождать или нет - переустановить таймер - выполнить ....
2) все то же самое, только без таймера и ДЛЯ КАЖДОГО ЮЗЕРА ОТДЕЛЬНО. Вы хотя бы начальное представление имеете, как такое делается?

Суть в том, что вы пытаетесь нарушить саму асинхронную сущность web, и тем самым увеличиваете свой риск попадания в группу людей "для которых в аду уготовано отдельное место" >:-]

[Александр]

Илья Ерохин: >> 1) установить таймер - выполнить - посмотреть
>> таймер - подождать или нет - переустановить
>> таймер - выполнить ....
>> 2) все то же самое, только без таймера и
>> ДЛЯ КАЖДОГО ЮЗЕРА ОТДЕЛЬНО. Вы хотя бы начальное
>> представление имеете, как такое делается?

Во-первых, мне кажется, что вы действительно невнимательно читаете документацию к модулю. Потому что в первых же строках там сказано, что ограничение идет не по всем запросам, а в разрезе заданного ключа (IP-адреса, как частный случай). То есть, фактически, ограничение и в варианте №1 может происходить "ДЛЯ КАЖДОГО ЮЗЕРА ОТДЕЛЬНО".
Во-вторых, под логикой я не имею в виду низкоуровневую работу внутри модуля. Я имею в виду общую логику. В обоих случаях второй запрос будет поставлен в очередь, пока исполняется первый. Так? Так. В обоих случаях исполнение второго запроса начнется после того как завершится первый (если первый не длится больше секунды, что вряд ли). Так? Так.

>> Суть в том, что вы пытаетесь нарушить саму
>> асинхронную сущность web
Я не нарушаю асинхронную сущность web. У меня намного более сложный кейс, чем просто "выстраивать абсолютно все запросы в очередь". Просто я попытался не вываливать сюда лишнюю информацию, а поставить вопрос максимально просто, с минимумом условий. Для того, чтобы комментаторы не лезли в ненужные дебри. А если бы мне дали ответ, я бы как-нибудь уж привел его к моему кейсу.
Но вы даже в этом случае умудрились уйти в сторону =)

Answer 1

[Виктор Таран]

nginx.org/ru/docs/http/ngx_http_limit_conn_module.html

а это то что должны были сделать вы:
google.gik-team.com/?q=nginx+%D0%BA%D0%BE%D0%BB%D0...

Comments

[Александр]

Я конечно, извиняюсь, но в вашем случае я посоветую внимательнее читать вопросы, на которые вы отвечаете. В данном случае, я писал, что мне нужно ставить запросы в очередь, а не выкидывать клиента с ошибкой 503. Указанный вами модуль я смотрел, и и он не подошел мне именно по этой причине.

[Виктор Таран]

Александр: недостающий функционал дописывается на перле, или на лула, их подключить можно к nginx

[Александр]

Виктор Таран: То, что на Lua можно написать практически все, что угодно, это понятно. Но неужели у такого мощного инструмента как nginx нету решения из коробки для такой простецкой задачки? Или даже не у nginx, а у любого другого стандартного для Linux-сервера инструмента.