Есть широко известная проблема: при запросе от клиента сквид сразу начинает закачку файла на максимальной скорости, а клиенту отдает на скорости клиента, то есть при внешнем канале 2Mbit и клиентом на 56к, при начале закачки клиентом, например, isoшки на 600 мег и обрыве скачки через час, мы отдаем клиенту 10-12 мег, а скачиваем мег 600. Итого 590 мег ушло неизвестно куда. Delay pools проблему не решает, так как ограничивает, опять же, только скорость в сторону клиента. А теперь вопрос - кто виноват и что делать? :) Может кто уже патч написал на этот случай?

• Решение проблемы со Сквидом...,Michael, 10:39 , 30-Апр-03
  • Решение проблемы со Сквидом...,Shuttle, 11:42 , 30-Апр-03
    • Решение проблемы со Сквидом...,Ernesto, 12:21 , 30-Апр-03
      • Решение проблемы со Сквидом...,Michael, 12:43 , 30-Апр-03
        • Решение проблемы со Сквидом...,Shuttle, 12:19 , 02-Май-03
          • Решение проблемы со Сквидом...,Михаил, 08:32 , 04-Май-03
• Решение проблемы со Сквидом...,iiws, 12:25 , 05-Май-03

>Есть широко известная проблема: при запросе от клиента сквид сразу начинает закачку
>файла на максимальной скорости, а клиенту отдает на скорости клиента, то
>есть при внешнем канале 2Mbit и клиентом на 56к, при начале
>закачки клиентом, например, isoшки на 600 мег и обрыве скачки через
>час, мы отдаем клиенту 10-12 мег, а скачиваем мег 600. Итого
>590 мег ушло неизвестно куда. Delay pools проблему не решает, так
>как ограничивает, опять же, только скорость в сторону клиента. А теперь
>вопрос - кто виноват и что делать? :) Может кто уже
>патч написал на этот случай?
да... проблема есть...
если хорошие отношения с провайдером, то можно попросить его на его проксе сделать тебе ведра и качать трафик таких пользователей через его проксю.

>если хорошие отношения с провайдером, то можно попросить его на его проксе
>сделать тебе ведра и качать трафик таких пользователей через его проксю.
>

Хорош совет :) Т.е. предлагается перенести проблему к прову, если тот сдуру согласится... А если канал нормальный, то у прова он идёт прямо с роутера, без всяких прокси.

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

>Хорош совет :) Т.е. предлагается перенести проблему к прову, если тот сдуру
>согласится... А если канал нормальный, то у прова он идёт прямо
>с роутера, без всяких прокси.
   Как раз у меня такая же ситуевина.
>А существует ли проблема? В сквиде задаётся максимальный размер элемента в кэше
>(по умолчанию - 4Мб) и если ты его не менял, то
>больше он хранить не должен.
   32М у меня, для большего HitByteRatio (кстати, реально помогло). А теперь вопрос - файл 100М сквид просто пропустит через себя со скоростью, с которой он будет отдавать клиенту или опять же, выкачивать будет на максимальной?
p.s. в любом случае, ограничение на размер хранимого файла - очередной костыль. хотелось бы нормального решения.

>>Хорош совет :) Т.е. предлагается перенести проблему к прову, если тот сдуру
>>согласится... А если канал нормальный, то у прова он идёт прямо
>>с роутера, без всяких прокси.
канал каналом, но многие провы содержат свой прокси, почему бы им не пользоваться? мой пров вполне пошел бы мне навстречу, если бы я его от таком попросил бы...

>   Как раз у меня такая же ситуевина.
>>А существует ли проблема? В сквиде задаётся максимальный размер элемента в кэше
>>(по умолчанию - 4Мб) и если ты его не менял, то
>>больше он хранить не должен.
>   32М у меня, для большего HitByteRatio (кстати, реально помогло).
>А теперь вопрос - файл 100М сквид просто пропустит через себя
>со скоростью, с которой он будет отдавать клиенту или опять же,
>выкачивать будет на максимальной?
>p.s. в любом случае, ограничение на размер хранимого файла - очередной костыль.
>хотелось бы нормального решения.

насколько я понял из описания delay pools, сквид приостанавливает закачку когда ведро наполнится...

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

>насколько я понял из описания delay pools, сквид приостанавливает закачку когда ведро
>наполнится...
Да, вроде так. Поэтому delay_pools можно рассматривать как одно из страховочных решений.

>а максимальный размер элемента в кэше тут ни причем, он всего лишь
>задает сохранять ли файл в дисковом кэше или нет в зависмости
>от его размера.
А если нет вёдер и ситуация как описал Ernesto? Где по-твоему будут храниться эти 600 метров, пока их не выкачал по своей медленной линии клиент если размер элемента в кэше тут ни причем?

>>а максимальный размер элемента в кэше тут ни причем, он всего лишь
>>задает сохранять ли файл в дисковом кэше или нет в зависмости
>>от его размера.
>А если нет вёдер и ситуация как описал Ernesto? Где по-твоему будут
>храниться эти 600 метров, пока их не выкачал по своей медленной
>линии клиент если размер элемента в кэше тут ни причем?
где храниться - это личное дело сквида, скорее всего на диске. но если размер файла превышает заданный порог, то он не будет занесен в кэш и удален сразу после завершения закачки (ИМХО).

>Есть широко известная проблема: при запросе от клиента сквид сразу начинает закачку
>файла на максимальной скорости, а клиенту отдает на скорости клиента, то
>есть при внешнем канале 2Mbit и клиентом на 56к, при начале
>закачки клиентом, например, isoшки на 600 мег и обрыве скачки через
>час, мы отдаем клиенту 10-12 мег, а скачиваем мег 600. Итого
>590 мег ушло неизвестно куда. Delay pools проблему не решает, так
>как ограничивает, опять же, только скорость в сторону клиента. А теперь
>вопрос - кто виноват и что делать? :) Может кто уже
>патч написал на этот случай?

именно Delay pools проблему эту решает !!! ограничивает в обе стороны - проверено ! кроме того можно вообще ограничить полосу всему сквиду
классом пулов 2 или 3, чтобы при обрыве коннекта с юзером сквид не докачивал файл - настрой параметры
╧ quick_abort_min 16 KB
# quick_abort_max 16 KB
# quick_abort_pct 95
нужно указать что-то в этом роде
quick_abort_min -1 KB
quick_abort_max -1 KB
quick_abort_pct 95