Re: [squid-users] New open-source ICAP server mod for url rewriting and headers manipulation.

On 15/06/2012 8:27 a.m., Eliezer Croitoru wrote:
> well first i'm not such a huge programmer.
> writing the code in ruby is very simple and e-cap will might be faster
> and it can be a good idea to write some code for it.
> if you have any example code i will be happy to hear about it.
>
> java is not that bad as it seems to some people and GreasySpoon offers
> so much:
> simple interface + web interface
> simple methods
> simple logs
> simple way to work with threads
> embedding external classes and libs.
>
> after all that the memory consumption is not that bad for a heavy load
> environment.
>
> but still my ruby simple server has nice interface to the user i have
> moduled (not finished yet).
> it's almost not consuming ram and cpu.
> writing a module for my icap server is just about writing the full
> class in only ruby, include it and run a simple matcher case to apply
> the class method operation.
>
> if you do ask me about caching post responses i would say that it's in
> most cases not suppose to be cached and is a mechanism to send the
> server forms and data.
>
> about url_rewriting there is already a url_rewrite interface for squid
> so it seems like a pointless operation to write new one at all.
>
> the main reason i wrote it was because i needed an independent service
> software and platform to work with for a high load proxy.
> i can use one (or two redundant) icap server as a rewriting platform
> for a whole proxy cluster but with the current cpu and ram usage of it
> i can put it on the same server instead of on another machine.
>
> i think that for any server to maintain a stress of above 900 requests
> per second (with the usage of one fork when there is an option for
> more with just a settings file, on an intel atom cpu) it will be an
> achievement.
> the only reason i havn't tested it for more then 1024 request per
> second stress is because i havn't had the time to tweak the machine\s
> descriptors to more then the soft limit of 1024.
> to make squid run without any cache.log errors i had to shutdown the
> access.log writing.

FTR: 800-850 req/sec is what we benchmark Squid-3.1 with defaut config
on a relatively average machine.

Your Squid+ICAP benchmarks will be capped at something like that, below
what your machine can benchmark a default Squid. Due to Squid having to
double-handle all requests sent to ICAP.

>
> more ideas for stress tests and if someone have a spare test
> environment to spare some testing time for the software i will be happy.
>

You may want to get in touch with Alex from TMF, they have a lot of
experience with performance measuring and ICAP as well.

If you happen to uncover anythign nasty and slow about the ICAP
behaviour in Squid he would also be the one to fix it.
Amos

> Eliezer
>
> On 14/06/2012 22:44, johan firdianto wrote:
>> why you don't play with ecap ?. it should faster than icap.
>> greasySpoon based on java, i'm not surprised consume much memory.
>> with i/e-cap you could also cache post request by using respmod vector.
>>
> <SNIP>
>
>
Received on Fri Jun 15 2012 - 02:32:17 MDT