>быстро усосет 4Кб, а потом будет лить со скоростью в 2Кб/cек.
>Точнее быстро будет усасывать объекты размером до 4Кб (на скорости в
>16Кб/сек), объекты больше 4Кб будет сосать на скорости 2Кб/сек. Строго говоря, это совершенно неверно. Ну, то-есть, так написано в доках сквида, но в исходниках написано совершенно другое. Во всех примерах байт-рейт пула и объем бакета выставлены примерно одинаковыми. В этом засада, потому что внятно смысла этих величин дока сквида не объясняет.
С точки зрения реализации бакет - это просто буфер, из которого элементы выдергиваются индивидами по мере надобности. Если это индивидуальный бакет, в пуле 1-го класса, то вполне можно настраивать по примеру в конфиге. Т.е.:
delay_parameters 1 32000/32000
Но если у нас используется второй класс с агрегацией и агрегированым бакетом, то настраивать, как нарисовано в конфиге - себе дороже выйдет. Настраивать нужно примерно так:
delay_parameters 1 128000/5120000 32000/32000
Агрегированный бакет задается существенно большим, чем байт-рейт пула. В идеале он должен быть несколько больше, чем суммарный объем бакетов отдельных индивидов. Надо учитывать, что индивидуальные пулы создаются автоматически, и не всегда их количество можно заранее предугадать. Оптимально - ставить натурные эксперименты и следить за статистикой сквида, раздел "делей-пулы".
Так или иначе, нужно помнить, что размер агрегированого бакета (тотального или подсеточного - для 2 и 3 классов) должен быть БОЛЬШИМ. В некоторых тяжелых случаях - десятки мегабайт. Маленький агрегированный бакет приводит к тому, что заполняясь трафиком отдельного индивида, он тормозит потоки всех остальных пользователей, отчего появляется мультипликативный эффект постоянного затора. Чтобы поток к индивидам был плавным и гладким, агрегированные бакеты не должны заполняться полностью НИКОГДА.
Вариант для распечатки
(ok) on 30-Июн-10, 10:07 
