Re: [squid-users] Testing Squid 3.2 - Some advices

I would first start by enabling a RAM cache to see how differently the
machine behaves. In my opinion, the hardware sounds like overkill for
1000+ users. Also, if you want to enable cache_dir's, create one on
separate partitions, depending on however you decide to slice them up.
I don't believe the "cache_dir per a worker" is a big improvement, over
the standard "single large cache_dir", or the like. The cache_dir's
biggest bottlenecks are Disk I/O, and all of it's overhead, and with
16GB of RAM available, Squid should be able to use a good portion of
that for a _fast_ Heap LRU cache, such as 4GB. The disk cache, is
better served for lesser-used objects, and I would personally
recommended enabling Heap GDSF for them. That only being my opnion.
The cache_dir arrangement depends on your actual RAID configuration.

>>> Agua Emagrece <aguaemagrece_at_gmail.com> 7/5/2011 8:35 AM >>>
Greetings,

I would like to ask for some advices testing squid 3.2 beta on a
semi-production scenario.
We are already running it for 1,000+ users in our company, but without
caching (just using redirector for now).
We want to start using the caching capabilities of squid, but the
right way. We chose to test the 3.2 beta mainly because of the SMP
features. We set it to use 14 workers and, so far, no critical
problems at all.
The server is a 16 virtual proc with 16GB ram and fast SAS disk array
of 4TB.

O.S.: Slackware 64 13.37 with custom 2.6.39.1 kernel
Proxy mode: Tproxy Bridge

Squid compile info:

Squid Cache: Version 3.2.0.7-20110509
configure options: '--enable-linux-netfilter' '--disable-ipv6'
'--enable-http-violations' '--enable-dlmalloc'
'--enable-useragent-log' '--enable-cache-digests'
'--enable-follow-x-forwarded-for' '--enable-storeio=aufs,ufs'
'--enable-removal-policies=heap,lru' '--with-maxfd=16384'
'--enable-poll' '--with-filedescriptors=16384' '--enable-async-io=128'
'--disable-ident-lookups' '--enable-zph-qos' '--enable-truncate'
'--with-pthreads' '--with-large-files' '--enable-ssl'
'--with-openssl=/usr/include/openssl/' '--disable-htcp'
'--enable-inline' '--enable-underscores' '--enable-icap-client'
'--enable-carp' '--with-default-user=squid'
'--enable-ltdl-convenience' '--enable-delay-pools' '--disable-wccp'
'--disable-wccpv2' '--disable-auto-locale'
'PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig:/usr/lib64/pkgconfig'

My squid.conf is pretty simple and almost default for bridge+tproxy
configuration for now. No cache_dir, no RAM cache. Pure proxy with a
redirector and Workers set to 14 as I said before.

The only problems I can see now are:

1) squidclient mgr:* is showing me duplicated or wrong information,
like 36,000+ clients accessing the proxy when we just have 1,000+
2) Some delay showing sites during times of the day, even when load
and link is low (we are not caching anything yet)

As the rocksolid is not ready yet (correct me if I'm wrong or
misinformed about it, please), I need to use one cache_dir per worker,
right? Should I configure 14 cache_dirs or there is another way? Any
advices about my compile options? Our main objective is give our users
optimized http access and some link economy. Am I going the wrong way?

Thank you very much!

Travel Impressions made the following annotations
-------------------------------------------------------------
"This message and any attachments are solely for the intended recipient
and may contain confidential or privileged information. If you are not
the intended recipient, any disclosure, copying, use, or distribution of
the information included in this message and any attachments is
prohibited. If you have received this communication in error, please
notify us by reply e-mail and immediately and permanently delete this
message and any attachments.
Thank you."
Received on Tue Jul 05 2011 - 13:26:00 MDT