Ограничьте пропускную способность отдельных HTTP-запросов, не ограничивая общую пропускную способность

Рассматривая такие инструменты, как tc , wondershaper , htb и comcast , все эти инструменты, похоже, работают на уровне сетевого интерфейса или, по крайней мере, «группы соединений» для ограничения пропускной способности. Я бы не хотел дросселировать полосу пропускания для группы соединений, но вместо этого уменьшал максимальную скорость отдельных соединений.

В частности: есть ли доступный инструмент, который я могу использовать для формирования максимальной скорости загрузки отдельных HTTP-запросов?

Детали

То, что я хочу сделать, это эмулировать медленные запросы на выборку из ведер на S3. Я вижу, что для запросов, которые находятся далеко от центра обработки данных, загрузка отдельного элемента обычно медленная (<500 кбит / с), но при загрузке параллельно скорость загрузки составляет> 5 мб / с.

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

  • Уменьшение потери пакетов при ограничении скорости tc
  • контролировать пропускную способность интерфейса с помощью tc или iptables
  • Можно ли разрешить загрузку полосы пропускания на «IP» с использованием `tc`,` htb` и `iptables`? (Ограничение загрузки не требуется)
  • Как применить параметр к пакету, чтобы TC мог расставить приоритеты \ классифицировать его
  • установить ограничение скорости передачи пакетов через iptables
  • точка захвата пакетов для передачи данных
  • Совместное использование нагрузки через несколько интерфейсов с использованием tc
  • Как настроить распределение пропускной способности между группами?
  • 2 Solutions collect form web for “Ограничьте пропускную способность отдельных HTTP-запросов, не ограничивая общую пропускную способность”

    Согласно вашему требованию, я хотел бы предложить Varnish, и это высокоприоритетный сервер кеширования HTTP. Он находится перед уровнем вашего веб-сервера и кэширует содержимое в ОЗУ, поэтому последующие запросы подаются как можно быстрее.

    Следующая справочная статья была хорошо продемонстрирована, как установить и настроить лак на веб-сервере в CentOs.

    Для редактирования есть два файла конфигурации, / etc / sysconfig / ln и /etc/varnish/default.vcl .

    Редактируя default.vcl, вы можете оптимизировать свои проблемы с полосой пропускания. Я уже установлен на своих серверах.

    В качестве примера конфигурации выглядят следующим образом.

     backend web1 { .host = "PUBLIC_IP_ADDRESS"; .port = "80"; .probe = { .url = "/"; .interval = 5s; .timeout = 1s; .window = 5; .threshold = 3; } } 

    Дальнейшее обращение: установка Varnish 4 на CentOS 6 в качестве сервера кэширования и балансировки нагрузки

    Установка limit_rate nginx, по- видимому, устраняет некоторые проблемы в кальмарах и лаках, как рекомендовано другими респондентами. Из документов:

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

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

    Кальмар

    Squid's delay пускает группы клиентов группы (обычно по IP) и использует ограничение скорости в квадратных скобках. Однако даже документы говорят :

    Вы не можете ограничить скорость соединения одного HTTP-запроса.

    лакировка

    Vmod_vsthrottle Varnis (и аналогично libvmod-throttle ) работает с алгоритмом маркера токена и принимает произвольные ключи. Реализация кажется очень классной, но похоже, что нет хорошего способа замедлить трафик. Вместо запросов выше предела (в req / s) ответят на что-то вроде 429 .

    Linux и Unix - лучшая ОС в мире.