Re: Storing of information

On 02/11/2012 12:57 AM, Pieter De Wit wrote:
> <snip>
>> I like the idea of pushing it off into ICAP. That does being up the
>> problem that things like auth loops, errors and related self-DoS
>> events are omitted from the quota counts. Also tunnels are adapted
>> only for the HTTP headers portion, once they get to the blind-tunnel
>> parts its direct byte shuffling between two TCP sockets.
>>
> <snip>
>> In squid it would have to be a AsyncJob to start with, since the
>> memory spaces are still too much twisted together to add threading
>> cleanly. When that is working, splitting process or thread away may be
>> an option for improving over the Job.
>>
> Scrap that idea then :)
>
> From my limited playing with the ICAP protocol, what would be the short
> comings ? I looked at RESPMOD mode, which seems to be "Respond Mode", as
> in, modify the response. I can't see the short fall here, it had the
> length and all that ?

ICAP is not ideal for implementing control points other than at the
beginning of messages. It would be awkward and performance-expensive to
use ICAP for quota control if you want to change things in the middle of
a transaction. ICAP also lacks proactive notifications from the ICAP
server to Squid, which would be nice for certain quota operations.

Compared to ICAP, eCAP has a much lower performance overhead, but has a
similar beginning-of-message design limitation. If you want to do this
using loadable modules, we could discuss extending eCAP, but I am not
sure it is the best approach.

I recommend considering reshaping client_db code to work with shared
memory so that it can work correctly in SMP mode. I do not think that
would be very difficult to do and it would be immediately useful.

Once that is done, you can add a control message queue and use external
processes to manage the quota database as needed. This design would
minimize performance impact while allowing for any external quote
management programs to co-exist with Squid.

HTH,

Alex.
Received on Mon Feb 13 2012 - 19:47:39 MST