On 11/14/2011 03:14 AM, Amos Jeffries wrote:
On Sun, 13 Nov 2011 18:33:12 +0000, Andrew Beverley wrote:
On Sun, 2011-11-13 at 23:12 +0530, Benjamin wrote:
On 11/13/2011 10:51 PM, Andrew Beverley wrote:
> On Sun, 2011-11-13 at 22:29 +0530, Benjamin wrote:
>> Hi,
>>
>> I want to use squid version on centos 6.So for that i wonder that
do i
>> compile squid latest stable version from squid source code or
should i
>> go with rpm package which i get from my distro.?
> You're normally best using the one provided with your distro, unless
> there are specific features you need from a later version.
>
>> Actually my concern is that installation of rpm / compilation from
>> source code are same while compare with squid features ?
> Try the one from the distro first and see if it meets your
requirements.
>
>> And as per my purpose with squid, we want to use it for only high
cache
>> performance, so for that do i need to take care of specific squid
feature ?
> I don't know, but others will be able to advise, or you can check the
> list archives.
>
>> And please provide me any good document or link from where i can
have
>> good understanding of each squid features which we get while
compilation
>> process in ./configure command.
> ./configure --help
>
> Andy
>
>
Hi,
Thanks for your kind response.If i do not want any authentication
module
from squid and when i install squid from distro rpm that time i have
that authentication module by default enabled so in that case, does it
impact on performance.
Well if you've not configured any authentication in squid.conf then I
imagine that the impact will be minimal.
Actually we need squid for forward proxy and cache gain only.
I'm sure you could tune Squid for your particular use, but I'm afraid I
don't know exactly how much difference that will make.
From others reports over the last year it seems possible to get a gain
of 5%-10% over the default settings when doing site specific tuning.
The more policies and control logics you add to the config the slower
Squid goes. So most of the optimization efforts I and others tend to
talk about here are aimed towards getting complex configs to work
without degrading the default performance.
The #1 bottleneck in caching is disk I/O. Performance gains in this
area are usually down to the type, size and write speed of the
hardware, since Squid constantly does a lot of writes randomly across
the disk. Benchmarks and measurements by hardware people are the areas
to look at there.
The #2 bottlneck is ACL processing and configuration complexity.
Naturally the more config you have the slower Squid appears as it
processes each request through all that logic.
The other bottleneck points are all down to the code optimizations and
the local HTTP traffic behaviours. Test, measure, tune are the bywords
there.
Amos
Hi Amos,
Thanks for your great response.You always guide us to resolve our
queries.Your knowledge sharing is great to us.For better performance
with squid, we need good h/w.
Thanks,
Benjamin
