Re: [squid-users] Asking for advice on obtaining a better throughput.

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