при использованиии delay pools и кэша,
если мы ограничиваем скорость для закачки больших файлов,например
acl BIG urlpath_regex -i \.mp3$ \.avi$ \.mpg$
delay_pools 1
delay_class 1 1
delay_parameters 1 3000/3000
delay_access 1 allow BIG
delay_access 1 deny allто скорость закачки какого-то MP3 файла клиентом будет уменьшена до 3000,
но с какой скоростью SQUID закачивает этот файл себе в кэш?
с максимально возможной для канала?тогда получается и у клиентов скорость маленькая и канал всё равно забит ?!!
>но с какой скоростью SQUID закачивает этот файл себе в кэш?
>с максимально возможной для канала?
>тогда получается и у клиентов скорость маленькая и канал всё равно забит ?!!Нет, бакет пула загружается на максимуме скорости, прописанной для бакета. Но на максимуме скорости бакет пула загружается только при начальном заполнении, а при выгребании содержимого бакета юзером, догрузка его производится даже не то, что на скорости выгребания пользователем, а даже ниже - из-за "медленного старта" в ТСР-стеке.
Ваша проблема (малые скорости и большие лаги при забитости канала) - в неверной конфигурации бакетов. Обычно все делают, как в дефолтном конфиге:
#delay_parameters 2 32000/32000 8000/8000 600/64000
Но при этом агрегатный и групповой бакеты заполняются за одну секунду, после чего весь траффик юзеров протискивается, через буфер в 32кБ, а для группы - через 8кБ, при том, что средний размер пакета около 1200 байт. Разумеется, образуется "пробка", "затор".
Опыт показывает, что наиболее оптимальной стратегией есть пул второго класса, у которого групповой бакет ОЧЕНЬ большой, а индивидуальные бакеты - умеренных размеров.
Например, вот так: ( А/Б = скорость наполнения/объем бакета )
1MBps/10МВ 16kBps/256kB (цифрами, цифрами - аббревиатуры для наглядности)
При этом отсутствуют лаги сессий из-за переполнения бакетов массой клиентов, и траффик вниз идет плавно и гладко.
Жалко, что третий класс в сквиде реализован глючно. Например, клиенты из подсетей 10.11.12.0/24 и 10.75.12.0/24 окажутся в одном групповом бакете, из-за того, что принадлежность к группе (подсети) определяется сквидом только по третьему байту адреса клиента. Имейте в виду этот глюк сквида.