Прокси-сервер умеющий ставить заросы в очередь?

Question

[nexus0]

Нужен прокси сервер который умеет ограничивать количество одновременных http запросов, ставив в их очередь.

Comments

[Иван Шумов]

Можно поинтересоваться зачем? Я просто сейчас представил как это могло бы работать на сетевом уровне и меня немного перекосило

[nexus0]

Иван Шумов, я написал приложение-парсер, иногда оно привышает лимит соеденений к серверу, хочу избавиться от этого вот таким прокси для него.

[nexus0]

Иван Шумов, а почему перекосило?

[Иван Шумов]

nexus0, это решается инструментом под названием MessageBroker и таймаутом в приложении. + Прокси

[nexus0]

Иван Шумов, а почему бы просто не решить вот таким прокси? какие камни?

[Иван Шумов]

nexus0, по тому что сеть не резиновая, и на сетевом уровни есть свои таймауты. Прокси работает на 4 уровне OSI (чаще 6-7) и выше и там каждый слой отлуп дает

[Иван Шумов]

nexus0, не надёжно и нет контроля. Никакого. Прокси занимается другими задачами

[nexus0]

Иван Шумов, просто выставлю больше таймаут на своем приложении, вот

[nexus0]

Иван Шумов, да велосипед может, главное чтоб работала) пока что так

[Иван Шумов]

nexus0, это так не работает) по тому что отлуп может быть не по таймауту, а сразу - на 4-ом же уровне блок и до свидания

[nexus0]

Иван Шумов, ох я пока не знаю что такое отлуп и про какой блок вы говорите, эти слова не так легко гуглятся. можно чуть простыми словами?

[Иван Шумов]

nexus0, упощу для понимания: причин не получить контент миллион и превышение времени ожидания - меньшая из проблем. При создании парсера всегда встаёт вопрос необходимости повторять запросы, а ещё - делать работу быстро (параллельные обращения). И тому и другому способствуют очереди: RabbitMQ, Kafka и и.п.

[nexus0]

Иван Шумов, простите, я все равно попробую так :) осталось выяснить какой прокси умеет ставить запросы в очередь

[nexus0]

Иван Шумов, сейчас нет времени разбираться с очередями

[Иван Шумов]

nexus0, сочувствую. Retry и timeout есть даже в nginx с upstream и proxy_pass, но описанную проблему решит не надолго

[Developer]

nexus0, это называется "костыли".
Добро пожаловать в быдлокодинг.
Хотя нет. Надо гнать ссаными тряпками

[mamontm]

nexus0,

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

Проще, намного проще, это именно в приложении лимитировать.

[mamontm]

Иван Шумов,

Kafka и и.п.

Серьезно?
Инсталляция Kafka'и должна, по вашему, заниматься такой вот ерундой?

[Иван Шумов]

mamontm, это инструмент) просто труба для данных. Да, там много интересного в настройках, но для этой задачи пойдет. Хотя тут кролик получше. Смотря как организовать

[mamontm]

Иван Шумов,

это инструмент) просто труба для данных

Жрущая дофига ресурсов и требующая квалификации.

но для этой задачи пойдет.

Для этой задачи - перебор.

[Иван Шумов]

mamontm, ну, согласен, немного перегнул, есть брокеры попроще) но иметь хотябы один под рукой и уметь его готовить - очень выручает

Answer 1

[mamontm]

SQUID

Comments

[nexus0]

А конкретно какой параметр за это отвечает?

[mamontm]

nexus0,

А конкретно какой параметр за это отвечает?

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

[nexus0]

mamontm, так я и искал и не нашел ничего конкретного. Только параметр maxconn, который просто ограничивает кол-во соединений на прокси, это не то что мне нужно.

[mamontm]

nexus0,

так я и искал и не нашел ничего конкретного. Только параметр maxconn, который просто ограничивает кол-во соединений на прокси, это не то что мне нужно.
Написано час назад

Лично выставлял лимиты еще в 2006 году.
SQUID умеет это уже очень и очень давно.
У него возможны весьма и весьма тонкие настройки.

[nexus0]

mamontm, да никак не могу найти это в документации, только ограничение на подключение к прокси.

[nexus0]

mamontm, каким словом искать это в документации?

[mamontm]

nexus0,
delay pool classes

Когда клиент делает запрос на получение какого-либо объекта - прокси-серверу (будь то картинка, html страница или любой другой объект), squid:

отдает объект клиенту с максимальной скоростью (точнее со скоростью, с которой позволяет железо между клиентом и squid'ом) - если объект имеет статус *_HIT (то есть находится в кэше),
либо с ограниченной скоростью (то есть со скоростью шланга) - если объект *_MISS (то есть не содержится в кэше/запрашивается у удаленного сервера).

Ну и естественно, объект со статусом *_MISS помещается в кэш (если это не запрещено правилами конфигурации), и следующий запрос к этому объекту будет как к кэшированному. Если клиент захлебывается и не успевает опустошить ведро, пока squid в него заливает, то squid ставит в очередь поступающие данные и не отправляет новые запросы удаленному серверу запрашиваемому сайту. По мере опустошения ведра клиентом, остаток объекта дозаливается. Т.о. объем ведра определяет сколько данных клиент может получить на максимальной скорости при условии, что эти данные кэшированы. При этом, данные вЁдер можно "каскадировать". Количество уровней каскадирования определяет класс пула.

Итого существуют следующие классы delay pools:

Класс 1 содержит ограничения для всех запросов, попадающих в пул. Единое ведро для всех сетей.
Класс имеет 2 ограничения: общие (аналогично первому классу), плюс индивидуальные ограничения для отдельных хостов (биты 25 – 32 сетевого адреса IPv4). Единое ведро для всех сетей, которое "орошает" находящееся "под ним" 255 ведер для хостов.
Класс имеет 3 ограничения: общие, индивидуальные ограничения для отдельных хостов (биты 25 – 32 сетевого адреса IPv4) (аналогично первому классу). Плюс между ними вклиниваются ограничения для сетей подсетей (биты 17 – 32 сетевого адреса IPv4). Единое ведро для всех сетей, которое "орошает" находящееся "под ним" 255 ведер для подсетей, которые, в свою очередь, каждое из 255 подсетей "орошает" находящееся "под ним" 255 ведер для хостов.
Класс имеет 4 ограничения: все, что определено в классе 3, плюс добавлены ограничения для конкретного авторизованного пользователя. Единое ведро для всех сетей, которое "орошает" находящееся "под ним" 255 ведер для подсетей, которые, в свою очередь, каждое из 255 подсетей "орошает" находящееся "под ним" 255 ведер для хостов, которые, в свою очередь, каждое из 255 хостов "орашает" n-ведер для каждого авторизованного пользователя.
Класс имеет единственное ограничение: запросы обрабатываются в соответствии с заданным тегом, который присвоен при помощи external_acl. Единое ведро для всех запросов, отмеченных заданным тегом в списке доступа external_acl.

[nexus0]

mamontm, аааа мне было бы достаточно трех строчек. Как же сложно разобраться в документации squid. Так как ограничить кол-во соедениений с помощью delay pools? Я нахожу только примеры где просто ограничивают скорость.

[mamontm]

nexus0,
Повторяю

Если клиент захлебывается и не успевает опустошить ведро, пока squid в него заливает, то squid ставит в очередь поступающие данные и не отправляет новые запросы удаленному серверу запрашиваемому сайту.

[nexus0]

mamontm, так это про скорость речь, а не про количество соединений. Мне нужны именно соединения.

[mamontm]

nexus0,

так это про скорость речь, а не про количество соединений. Мне нужны именно соединения.

Цитирую последний раз

то squid ставит в очередь поступающие данные и не отправляет новые запросы удаленному серверу запрашиваемому сайту

Дальше давай сам.

Answer 2

[xmoonlight]

Fiddler

if (m_SimulateModem) {
                // Delay sends by 300ms per KB uploaded.
                oSession["request-trickle-delay"] = "300"; 
                // Delay receives by 150ms per KB downloaded.
                oSession["response-trickle-delay"] = "150"; 
            }

Документация

Comments

[nexus0]

Не подойдет, приложение крутится на линуксе.