On 13/01/11 23:19, Víctor José Hernández Gómez wrote:
Hi all,
Thank you for your quick reply..
[ rest of message skipped for clarity ..]
cache_dir aufs /san/cache 241904 64 512 <- NOt used
cache deny all
NP: with a cache_dir configured it *is* used. The "cache deny all" means
that new data will not be added AND that existing data will be removed
when detected as stale or a variant collision.
upss, what should I do if I do NOT want to use any disk at all?
Comment out the cache_dir entirely and set "cache deny all".
[ .........]
3.1.10 may be worth trialling. We have just had some surprising
benchmarks submitted for it. On a basic config it seems to perform a few
dozen % RPS faster than 3.1.9. Reason unclear, but the big change
between them was better memory management and better validation support.
I say trial because under high load the benchmarker found some CPU
problems we have not yet isolated and fixed. I hope you will experience
a similar improvement without the problems.
[.......]
I will be following your advice (trying 3.1.10) in one or two weeks. I
will keep you informed.
Would a "one frontend/some backends" multi-instance configuration help
in a situation such as that I explained? What about changing congestion
control schemes ? Any experiences on this particular subject?
The "some-backends" configurations only helps when caching AFAIK. Each
layer of software adds slowdown while it re-parses the request. Usually
the speed increase from proxies is gained from pulling an item quickly
from local cache instead of going remotely for a slower fetch.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.10
Beta testers wanted for 3.2.0.4
