On 6/10/20 12:20 PM, Antony Stone wrote: > On Wednesday 10 June 2020 at 18:11:03, Prem Chand wrote: > >> Hi Alex, >> >> Thanks for responding to my issue . I didn't get how the math was done(why >> it's multiplied by 2) to get 16 slots if possible could you please elaborate >> with an example. > > I believe what Alex meant was: > > You want 30 minute timeslots for each of 3 peers, which is 48 half-hour > timeslots throughout the day. > > However, you only need to define 48/3 of these for peer A, and 48/3 of them for > peer B, and then let peer C deal with anything not already handled (so it > doesn't need its own definitions). > > 48/3 = 16, therefore you define 16 half-hour periods when you want peer A to do > the work, 16 half-hour periods for peer B, and then just say "peer C, handle > anything left over". Thank you, Antony! Here is an untested sketch: acl usePeerA time 00:00-00:29 acl usePeerA time 01:30-01:59 ... a total of 16 ORed lines for the first peer ... ... each line matches a unique 30 minute period ... acl usePeerB time 00:30-00:59 acl usePeerB time 02:00-02:29 ... a total of 16 ORed lines for the second peer ... ... each line matches a unique 30 minute period ... # and now match peer to its time slots cache_peer_access peerA allow usePeerA cache_peer_access peerB allow usePeerB cache_peer_access peerC allow !usePeerA !userPeerB The above may need further adjustments and polishing. For example, I am not sure how Squid will round these time values. The above assumes that 00:29 limit includes all 60 seconds up to (but excluding) 00:30:00. HTH, Alex. >> On Wed, Jun 10, 2020 at 7:12 PM Alex Rousskov wrote: >>> On 6/10/20 6:09 AM, Prem Chand wrote: >>>> My squid cache peer has 3 parent IP’s configured. I need to send HTTPS >>>> requests to the first parent IP for 30 minutes and after to the 2nd >>>> parent IP for 30 minutes and then to 3rd IP for 30 minutes and this >>>> switching needs to happen continuously .Could you please let us know >>>> how I can achieve this? >>> >>> If you are OK with hard-coded usage time slots for each peer, then I >>> would use two[1] "time" ACLs and cache_peer_access rules. Look for >>> "aclname time" in squid.conf.documented. You will have to generate a >>> list of (24*2/3=16) staggered time slots for each of the two ACLs, but >>> it should work. This may be the simplest solution. >>> >>> [1] You need two ACLs for three peers because the third peer should get >>> the requests that the first two peers were not allowed to get. >>> >>> ---- >>> >>> With a modern Squid, you could also implement this using a more flexible >>> (and more expensive, on several layers!) architecture with two ACLs: >>> >>> 1. An external ACL that returns the right cache peer name to use via a >>> keyword=value annotation API. This always-matching ACL should be >>> attached to http_access or a similar directive that supports slow ACLs. >>> Its goal is to annotate the request. You will need to write a >>> script/program that will compute the right annotations based on time or >>> some other factors. This is where the flexibility of this solution is >>> coming from. >>> >>> 2. A "note" ACL attached to cache_peer_access directives, allowing >>> access to peer X if the external ACL in item 1 returned >>> use_cache_peer_=X. The "note" ACL is a fast ACL and, hence, can be >>> reliably used with cache_peer_access. >>> >>> If you already have another external ACL, you may be able to piggyback >>> annotations in item 1 to whatever that ACL is already doing. >>> >>> For more information, search for "keyword=value" and "acl aclname note" >>> in your squid.conf.documented and see >>> https://wiki.squid-cache.org/Features/AddonHelpers#Access_Control_.28ACL. >>> 29 >>> >>> >>> HTH, >>> >>> Alex. > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
