On Wed, 28 Jul 2010 17:43:28 +0000, Jenny Lee <bodycare_5@xxxxxxxx> wrote: >> Jenny Lee wrote: >> > >> > Hello folks, >> > >> > I am trying to load-balance a username among 2 parents and the cache >> > itself (direct). >> > >> > I have: >> > >> > [auth_param parts snipped, username works fine] >> > >> > acl 33PERCENT random 1/3 >> > acl TESTUSER proxy_auth TESTUSER >> > >> > cache_peer 2.2.2.3 parent 4444 0 proxy-only name=P2 login=PASS >> > cache_peer 2.2.2.4 parent 4444 0 proxy-only name=P3 login=PASS >> > >> > cache_peer_access P2 allow TESTUSER 33PERCENT >> > cache_peer_access P3 allow TESTUSER 33PERCENT >> > >> > cache_peer_access P2 deny all >> > cache_peer_access P3 deny all >> > >> > >> > I can't seem to get this working. I surely must be overlooking >> > something. >> >> Are you running the 3.HEAD development (alpha release) code which >> supports the random ACL? > > Yes. > > >> check the particular HEIR codes being logged, I'm not sure what to >> expect under these circumstances but I suspect you are getting a mix of >> FIRST_UP_PARENT, DIRECT and something else. For this to work you are >> wanting only one of the parent selection algorithms to work in addition >> to DIRECT. > > It is never going DIRECT. It is going fine to parent2 and parent3... > However, I get 407 both from P2 and the local cache trying from > squidclient. PASS,PASSTHRU,PROXYPASS... all tried witht he same outcome. > >> > >> > How can I make the username go from 2 parents and cache itself >> > (direct) randomly? >> >> The traditional way is still easy... >> >> Setup a non-caching gateway instance which does the load balancing >> between the two parents and a local caching instance. > > None of these are doing any caching at the moment. This is for testing > only. I would like this to be done on the config of one squid only. The > others don't forward anything. The just fetch whatever leecher squid asks > them. > > >> If you have the 3.HEAD code for random ACL you could also try out the >> new worker-based equivalent to the above.... >> One worker process-id on the localhost+caching, and another on the >> public port + random ACL + peers to balance between localhost parent >> and the parents. :) > > I didnt really understand the logic how the workers work. Is there any > documentation or pointers? Sketchy at present since its so new. In the background its identical to starting multiple instances with slight variations on their squid.conf. Only one squid.conf is needed now, with wrapping bits that are specific to one worker in an if...endif statement using a process number (integer) to tell the workers apart. Numbering I think is arbitrary 1,2,3,etc as long as your config is self-consistent. The config bits that are not wrapped in if...endif are shared by all workers. > > acl random has a load balancing example for cache_peer. How to add DIRECT > to that equation? always_direct? never_direct? I tried everything > imaginable. There must be some solution. Always direct forces peers never to be used. hmm, I had overlooked *_direct. never_direct would leave a number of requests with no access if the randomness failed to select a parent and then selected never_direct. I think always_direct should work. If you 1/3 randomly the always_direct and also round-robin the parents it should be expected to always have one route outwards. > > Thanks for acl random. That is a true gem. I waited so long for it, but > unfortunately you did not incorporate it to 3.1 so i went with 3.HEAD on a > production machine. Ouch, sorry about that. At least it's beta in a few days. The lame excuse: I/we are trying to get 3.x into a predictable schedule that works for both us few dev and yourselves the clients. That means some pressure on feature porting to encourage more testing. 3.2 is only 6 months off the desired yearly turnover. Fingers crossed the following ones will close the gap even further. Amos
