Как считать количество скачиваний файлов в секунду на множестве серверов в режиме реального времени?

да, но как узнать на фронте нагрузку на канал? доступа к роутеру нет

Чисто теоретически: сплясать от среднего кол-ва коннектов на текущую ноду (равномерно же запросы распределяются?), средний размер отдаваемой части и кол-ва отдающих nginx-нод.

да, получается как-то так, и даже размер с количеством не нужны

шейпить трафик могут админы, а мне надо динамически подстраивать мое приложение под уровень нагрузки

Григорий Кочанов А вы не заодно?

нет. enterprize. policy

нет, multitenancy, сервера динамические, но могу, теоретически, создать специальные общие редисы, и писать в них о каждом скачивании

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

как вариант, каждый сервер может сам по своей личной статистике за прошлую секунду отдавать свое значение, без учета соседей. спасибо!

очень редко

раз в день, раз в неделю

Григорий Кочанов Тогда возможно поможет, поддержка на клинте и сервер-е ETag-а. Т.е. nginx вместе в каталогом возвращает ETag заголовок . Клиент, при повторном походе за каталогом передает известный ему ETag. Если на сервере каталог не менялся, то не менялся и ETag, и nginx в этом случае должен отдать 304 статус. Т.е. контент отдаем только если он действительно изменился. Думаю, существенно сэкономите трафик и нагрузку на nginx-ы

Не-не-не, Дэвид Блейн, это не highload на 2 сервера. Проверка изменения данных, конечно, есть. Иногда звезды сходятся, и тогда надо все, всем, и одновременно. Появление нового каталога, downtime, обновление формата, изменение 90% данных.

"Кушает пара десятков тысяч приложений" это и есть хайлоад на 2 сервера. Если мы говорим про "пару десятков" тысяч инстансов приложений, т.е. пару десятков тысяч клиентов. Какой у вас канал и размер каталога, что оно не лезет? Не можете зашепить трафик вашим lnux-ом, шейпите сами. Для отдачи файла одновременно 20к клиентам, вам по большому счету и nginx не нужен. Напишите на любимом вами языке программирования асинхронный, однопроцессный демон, который тащит все 20к коннектов, считает их кол-во и пишет в сокеты размером буфера и с задержкой, которые зависят от кол-ва этих коннектов. Если так хочется nginx-ом, посмотрите на https://github.com/yaoweibin/nginx_limit_speed_module. Запишите в отдельную переменную geo всех сетей с которых вы хотите раздавать файл. Создайте зону limit_speed_zone для этой переменной и зашейпите эту зону в вашем location. Признаюсь, сам этот модуль никогда не использовал, но судя по документации - должно работать.

спасибо, почитаю

Ванин блог это всё-таки нечто . И неужели хайлоад в 2006-м был таким?)

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

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

логично

Но еще зависит от размера данных, а на трафик это тоже влияет. То есть, на фронте можно сделать req_limit, а на клиенте замер времени и варьирование задержки в некотором диапазоне.Кривое решение, но тоже вариант.

Нет, резать через req_limit нельзя. У меня задача сделать мягкую подстройку, а не тормозить лишних. С динамическим числом фронт-серверов лимиты для nginx не рассчитать.

Oleg Tsarev Ага. Ради нее целый интернет построили