Уважаемые коллеги!

после вполне успешного использования delay_pools, прозрачной аутентификации ntlm и ограничения времен доступа и скорости на разных пользователей посредством создания различных групп в виндовом домене
всплыла такая особенность:
ограничение по скорости можно обрулить, пусть несколько и замысловатым образом, но всё же можно:
требуемый документ (обычно неплохого размера) запрашивается многократно, скажем 5-6 раз, первая сессия придерживается отведенной скорости, вторая придерживается, третья еще вроде в пределах, но дальше больше, 4, 5-ые копии этого документа начинают сгружаться на "всех парах", как этот эффект достигнут, так остальные сессии можно и обрывать, оставшаяся всё равно обслуживается с полной скоростью.

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

технические аспекты:
squid/2.5.stable5
samba 2.2.8a
freebsd 4.8

некот. параметры из squid.conf
которые на мой взгляд имеют отношение к делу:
quick_abort_min 0 KB
quick_abort_max 0 KB
quick_abort_pct 98  

half_closed_clients off
client_lifetime 120 minutes
client_db on
client_persistent_connections on  (без этого проблема с ntlm auth)
server_persistent_connections off
pipeline_prefetch off
memory_pools on
memory_pools_limit 1400 MB

эффект наблюдается и при ограничении на основе членства в группе windows
и на основе ip-адреса станции

возможно кто-то уже сталкивался с подобным явлением и нашёл способ избавления от него, пожалуйста, поделитесь опытом

или в приведенных директивах найдет ошибки
или просто сможет объяснить почему происходит подобное
-- буду очень признателен

• очень неприятное открытие при участии delay_pools,ipmanyak, 07:34 , 26-Мрт-04
  • очень неприятное открытие при участии delay_pools,waldis, 07:48 , 26-Мрт-04
• очень неприятное открытие при участии delay_pools,Junior, 08:11 , 26-Мрт-04
  • очень неприятное открытие при участии delay_pools,waldis, 08:20 , 26-Мрт-04
    • очень неприятное открытие при участии delay_pools,Shuttle, 12:29 , 26-Мрт-04
      • очень неприятное открытие при участии delay_pools,waldis, 14:49 , 26-Мрт-04

ну и где у тебя тут настройки delay pool, что-то я их не приметил !

>ну и где у тебя тут настройки delay pool, что-то я их
>не приметил !
я кажется не упоминал, что это весь конфиг

их много, ок, относительно много -- 13, с участием многих разнородных правил,
есть ли смысл приводить их здесь?
но с ними проблем нет, в штатных условиях они ведут себя как и запланировано

>Уважаемые коллеги!

>возможно кто-то уже сталкивался с подобным явлением и нашёл способ избавления от
>него, пожалуйста, поделитесь опытом
>
>или в приведенных директивах найдет ошибки
>или просто сможет объяснить почему происходит подобное
>-- буду очень признателен

Боюсь показаться назойливым с советом, но если перерасход в трафике является величиной критичной и требует незамедлительных и жёстких мер, то рекомендую поставить на канале Linux-машинку с iptables пересобранным.
там есть замечательный модуль limit, который будет ограничивать количество пакетов в заданный интервал времени. Выгода очевидна. Снижается нагрузка на другой сервер, т.к. разруливать трафик на перегруженном канале будет Linux, а не прокси-сервер. Ну и для вкуса можно в фильтре использовать ограничение на количество соединений с одного адреса (хоть IP, хоть заданного MAC-адреса) - connlimit. Есть и на ограничение полученных данных в период времени - connbyte, fuzzy.
В общем проблему можно решить другим способом, на мой взгляд, не углубляясь в настройки squid и не усиливая нагрузку таким образом на железо сервера.

Удачи.

идея-то нормальная,
но есть возражения такого плана:
экономия-экономией, но совсем зажимать тож не хочется,
документы, имеющиеся в кэше выдаются уже без притормаживания,
комфортность пользования несколько возрастает

да и сеть весьма неоднородна, на соседних ip-адресах могут находиться пользователи с разными требованиями к скорости, да и распределение адресов к тому же далеко не статично.

>экономия-экономией, но совсем зажимать тож не хочется,
>документы, имеющиеся в кэше выдаются уже без притормаживания,
>комфортность пользования несколько возрастает

Что-то мой опыт этого не подтверждает. Я год или полтора назад уже задавал здесь вопрос как сделать чтобы содержимое кэша шло мимо пулов. Ответили что невозможно в текущей версии. У меня тогда была 2.5st2 Может в 2.5st5 этим уже можно управлять?

>>экономия-экономией, но совсем зажимать тож не хочется,
>>документы, имеющиеся в кэше выдаются уже без притормаживания,
>>комфортность пользования несколько возрастает
>
>Что-то мой опыт этого не подтверждает. Я год или полтора назад уже
>задавал здесь вопрос как сделать чтобы содержимое кэша шло мимо пулов.
>Ответили что невозможно в текущей версии. У меня тогда была 2.5st2
>Может в 2.5st5 этим уже можно управлять?

зря он не подтверждает, то, что уже на диске, наша прокся не зажимает

один момент она работала в режиме свободной отдачи кэшированных данных тем, кто в данный момент не должен обслуживаться

но потом стало сложно поддерживать актуальность между
http_access & miss_access