On tis, 2007-10-09 at 11:21 +0200, Sylvain Viart wrote: > Would than mean we have some performance issue with singlethreaded > redirector? When not using the concurrent mode Squid sends a single request at a time to each helper, waiting for it to respond before sending the next reques. This works fine for small loads, but when the load increases you need very many helpers just to compensate for scheduling delays or Squid will get quite upset even if the helper as such is very fast. In the concurrent mode helper interface Squid batches up to the concurrency level number of requests to the same helper, making the communication squid<->helper much more efficient. This is actually unrelated of if the helper as such is multithreaded or singlethreaded. The decision on if a concurrent mode helper should be singlethreaded or multithreaded depends on the processing done by the helper. If CPU processing only then there is generally no benefits of going multithreaded. But if the helper often needs to wait on external resources such as DNS, databases etc then multithreading the helper may be quite beneficial to the operation of the helper, the alternatie is to use many helper instances. Most existing helpers can easily be converted to the concurrent mode interface to benefit from the batching. The requirements is * That the helper uses proper line-oriented reading of requests, making sure that the next request is not forgotten if then are received at the same time. * The format of request/responses is slightly different from the older interface, adding a request identifier in front. This needs to be echoed back with the answer. Regards Henrik
Attachment:
signature.asc
Description: This is a digitally signed message part
