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
