The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"загрузка канала и delay pools"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Настройка Squid и других прокси серверов (Public)
Изначальное сообщение [Проследить за развитием треда]

"загрузка канала и delay pools"  
Сообщение от oopsi (ok) on 03-Май-06, 15:27 
при использованиии 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 закачивает этот файл себе в кэш?
с максимально возможной для канала?

тогда получается и у клиентов скорость маленькая и канал всё равно забит ?!!

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

 Оглавление

Сообщения по теме [Сортировка по времени, UBB]


1. "загрузка канала и delay pools"  
Сообщение от DeadLoco (ok) on 04-Май-06, 11:53 
>но с какой скоростью 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 окажутся в одном групповом бакете, из-за того, что принадлежность к группе (подсети) определяется сквидом только по третьему байту адреса клиента. Имейте в виду этот глюк сквида.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру