A redirector can take an arbitrarily long time to return its answer. For example, it may need to make a database query, search through long lists of regular expressions, or make some complex computations. Squid uses a pool of redirector processes so that they can all work in parallel. While one is busy, Squid hands a new request off to another.
For each new request, Squid examines the pool of redirector processes in order. It submits the request to the first idle process. If your request rate is very low, the first redirector may be able to handle all requests itself.
You can control the size of the redirector pool with the redirect_children directive. The default value is five processes. Note that Squid doesn't dynamically increase or decrease the size of the pool depending on the load. Thus, it is a good idea to be a little liberal. If all redirectors are busy, Squid queues pending requests. If the queue becomes too large (bigger than twice the pool size), Squid exits with a fatal error message:
FATAL: Too many queued redirector requests
In this case, you need to increase the size of the redirector pool or change something so that the redirectors can process requests faster. You can use the cache manager's redirector page to find out if you have too few, or too many redirectors running. For example:
% squidclient mgr:redirector ... Redirector Statistics: program: /usr/local/squid/bin/myredir number running: 5 of 5 requests sent: 147 replies received: 142 queue length: 2 avg service time: 953.83 msec # FD PID # Requests Flags Time Offset Request 1 10 35200 46 AB 0.902 0 http://... 2 11 35201 29 AB 0.401 0 http://... 3 12 35202 25 AB 1.009 1 cache_o... 4 14 35203 25 AB 0.555 0 http://... 5 15 35204 21 AB 0.222 0 http://...
If, as in this example, you see that the last redirector has almost as many requests as the second to last, you should probably increase the size of the redirector pool. If, on the other hand, you see many redirectors with no requests, you can probably decrease the pool size.