Limit rate is another direction to limit traffic, I will think about it. Currently, I prefer to use the script to monitor access.log, and I find a problem today: >From [squid wiki](http://wiki.squid-cache.org/Features/LogFormat): > bytes The size is the amount of data delivered to the client. Mind that this does not constitute the net object size, as headers are also counted. It seems that **bytes** only includes response size (including http header). What I really want is counting both http-request and http-response. Is there any way to enable http-request **bytes** being logged in access.log? > On Dec 4, 2015, at 12:23 AM, Robert Plamondon <robert@xxxxxxxxxxxxx> wrote: > > I haven't used delay pools in a while, but I would think that the updated Squid 3 delay pools (with 64-bit counters and per-authenticated-user buckets) would allow such quotas. > > I'd take the monthly quota and turn it into a per-second rate. If my math isn't failing me, 100 GB/month = 38,500 bytes per second. That would be the refill rate on the delay pool. Users will be guaranteed this rate. Their BW would never be cut off, just throttled to the rate they're paying for. > > Then pick a max value to taste. I like to populate delay pools to support an enormous burst size (the "maximum" parameter in the pool), so the bandwidth limitations will rarely if ever be encountered by the average user. 10% of the monthly allotment, or 10 GB, (3 days' worth of bandwidth) strikes me as a good starting point, but I wouldn't have much resistance to even higher numbers, like 25%. > > Robert > > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
