Hello oops,

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

Введение

Народ юзерский стал увлекаться качалками, самыми разномастными, суть
качалок проста - открывается 10..50 коннектов, где файл тянется
несколькими потоками. Понимаю, когда ранее данная технология была
нужна с медленными каналами у сайтов, либо для обдуривания глупых
шейперов, но сейчас... когда у пользователя 56К, и в один поток он
может использовать почти всю свою полосу - неясен смысл более 3-х
потоков.

Суть
Имеется сотня-другая работающих пользователей, имеется на данный
момент сквид, и "ускоритель". Пользователи зашейплены на 56К, внешний
канал на прием 2-3 Мбит. Определенный пользователь, врубает свою
качалку на максимально агрессивный режим, итого наблюдаю картину:
Делаются запросы на файл к примеру 600 Mbyte, запросы выглядит как
Range: 456000- , т.е. от этого смещения и до бесконечности, таких
запросов может быть штук 20 и больше. Если на запрос не приходит
ответа (а приходит он обычно на первый, который и забивает его канал),
соединение рвется и устанавливается заново. Но проблема заключается в
том, что сквида уже успела принять и загнать в буфер (как я понимаю
обычно 32-64кбайт плюс внутренний буфер если он есть), и получается:
Клиент сделал 19 запросов в течении секунд 10, оборвал,и тут же сделал их
снова, не получив ответ. Естественно, что на свои 56к он получил около
70 кбайт в лучшем случае. На сквид все прибегает очень быстро
(особенно проблема усугубилась с ускорителем), итого если все буферы
успели заполнится 320 Кбайт. В реальности цифры конечно "помягче", но
у меня возникла ситуация 100 Кбайт/c траффика на пользователей, и 170
Кбайт снаружи(потолок установленный в ускорителе). В связи с этим
возникла мысль как бороться...
Идея с ограничениями сессий не подходит, это не решение, а костыль,
кроме того в моем случае все пользователи попадают на проксю уже из
под NAT. Ограничивать по User-Agent нереально, это тоже костыль,
следовательно метод запрещения здесь не подходит, единственный
вариант:
Запросы на один и тот же контент не давать возможности делать
параллельно (pipelining), что-то отдаленно подобное в сквиде есть, но
похоже с ranges фокус не проходит, он их считает разными
запросами(???). Прийдется действовать более
жесткими методами, попробую поиграться с запрещением Range:, но это
убьет вообще любого типа качалки, что не есть хорошо. Если можно будет
прицепить после сквида опс, который будет это делать, вообще
замечательно, с моими умениями программировать сам я это сделать не
могу, но возможно у кого есть талант, и кто считает проблему
существенной придумает решение.

P.S. Возможно проблема высосана из пальца и надумана, но все таки эта идея
обьясняет иногда отрицательное кеширование удивляющее админов на mrtg
:)


-- 
Best regards,
 Denis                          mailto:[EMAIL PROTECTED]

=====================================================================
If you would like to unsubscribe from this list send message to
[EMAIL PROTECTED] with "unsubscribe oops" in message body.
Archive is accessible on http://lists.paco.net/oops-rus/

Дати відповідь електронним листом