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>
