On 02/14/2014 04:38 AM, Nikolai Gorchilov wrote: > On Fri, Feb 14, 2014 at 7:22 AM, Alex Rousskov wrote: >> If you want to add an option to use the received ICP reqnum field as a >> public cache key for lookup, you should be allowed to do that IMO. If >> you want to add an option to add Store ID to ICP and HTCP requests, you >> should be allowed to do that too. AFAICT, each will give you the >> performance optimization you want without violating protocols and >> interfaces. >>> Maybe I'm wrong, but AFAIK Squid never uses "slow" processing methods >>> on incoming ICP/HTCP requests. Passing the incoming ICP/HTCP requested >>> URL via the StoreID will change this design principle. >> >> Lack of async code is not really a design principle and I am guessing >> that HTCP is already async by the very nature of TCP message processing >> (i.e., Squid may read a partial message). It is just that the code never >> needed an async step [badly enough]. However, with both of the solutions >> I am suggesting above, that async step is still not needed! > > I'm confused what solutions do you refer to. The first two sentences at the top of this email are the two solutions I was referring to. >> Would using ICP reqnum field as a cache key or adding StoreID to >> ICP/HTCP requests work for your use cases? I have not fully checked >> whether the former is possible, but I think it is. The latter is >> possible, but is more difficult to implement (and will bump into UDP >> packet size limits more often?). > Yep. Both will do. I personally prefer the second option - StoreID URL > normalization on incoming ICP/HTCP request, in order to avoid packet > size bumps as much as possible. Just to make sure we are on the same page, here is a list of options I recall being discussed: 1. Using ICP reqnum field as a cache key. 2. Adding StoreID to ICP/HTCP requests as an optional field. 3. Computing StoreID upon receiving a regular ICP/HTCP request. Out of those three, do you prefer #3? Note that #1 is a little hackish, but may be a easier to implement (and is a lot cheaper CPU-wise) than #3. Neither #1 nor #3 make the ICP packets bigger, unlike #2. > Especially if we memcache the StoreID > for later use, when the eventual HTTP request arrives few seconds > later. Caching to be considered as wish, not a must-have :) A StoreID cache is a good idea indeed. Cheers, Alex.
