Re: [RFC] One helper to rewrite them all

On 09/12/2012 02:50 AM, Alex Rousskov wrote:
> Yes, of course. Both ICAP and eCAP have meta-headers that can go both
> ways. But some people do prefer the helper simplicity, and my suggestion
> was meant to give those folks a performance boost.
>
> If the consensus is that performance-sensitive deployments should use
> performance-centric APIs such as eCAP while keeping the URL rewriting
> helpers as simple as possible, I am happy to subscribe to that approach.
I asked before about this option to use Icap for url_rewriting and the
answer that I got that we need the ICAP guy for that.
I have specific ICAP server I wrote which I use for url_rewriting and
his performance is more then 20,000 request per/s on a very little atom cpu.
The main problem was that squid after about 900 request per/s would have
a problem.
Else then that the ICAP server fit's for the task even more then a
helper (my opinion).

But the heavy part in the process is not really one or another interface
more then actually making the use of store_url url for mem_cache and
cache_dir properly.

I am having a bit trouble now because of the trillion loops and jumps in
the code while using over 100 times the mem_obj->original_url and
StoreEntry::origianlUrl (was ::url)
most of them are debugs so it helps me a bit but I am far from one place
that the hash is being calculated with the original url and neededs to
be replaced with store_url.

For the "no cachable" situation something should be done to lower
performance issues that could come from using store_url, some kind of
flag validation before sending it to the helper?

I will do my best to make the heart of the feature possible leaving the
rest for later to any other specialist who knows specifics of eCAP ICAP etc.

Regards,
Eliezer
Received on Wed Sep 12 2012 - 07:18:52 MDT