Re: [squid-users] Re: ICP and HTCP and StoreID

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.
Received on Tue Mar 11 2014 - 23:27:59 MDT