RE: [squid-users] Running Multiple instances and reporting confusion.

From: GIGO . <gigoz_at_msn.com>
Date: Thu, 27 May 2010 18:38:06 +0000

Hi Amos,
 
Related to my earlier query regarding how to handle reports with multiple instances. The problem was that inst1access.log though track client activities correctly however give incorrect information regarding the in-cache returned objects.As the caching part is instead being done by Instance-2. So the SARG reports (parsing of inst1access.log) wrongly depicts about objects returned from the cache.....
 
Now i just thought an idea that may be pointing to the same cache will solve the problem if instance 1 has no-store option set. Please read below and guide me i would be thankful
 
 
# INSTANCE-2 Cache directory setup of the instance that is doing the caching/fetching part
-------------------------------------------------------------------------------
cache_dir aufs /cachedisk1/var/spool/squid 50000 128 256
coredump_dir /cachedisk1/var/spool/squid
cache_mem 1000 MB
range_offset_limit -1 KB
maximum_object_size 4194304 KB
maximum_object_size_in_memory 1024 KB
quick_abort_min -1 KB
cache_replacement_policy heap LFUDA
memory_replacement_policy heap GDSF
 
 
# INSTANCE-1 Cache Directory setup Thought of the instance that is user facing....
-------------------------------------------------------------------------------------------------
cache_peer 127.0.0.1 parent 1975 0 default no-digest no-query proxy-only
prefer_direct off
# point to the directory of instance 1?
cache_dir aufs /cachedisk1/var/spool/squid 50000 128 256 no-store
cache_dir aufs /var/spool/squid 10000 16 256
coredump_dir /var/spool/squid
cache_replacement_policy heap GDSF
 
 
1. Is it possible for 1 instance to point to the cache directory of other insance in read only mode?
 
 
 
2. My original intention for multiple instances was to cache directory failover? However if the setup above mentioned is possible then would the setup will remain faulttolerant or failing of /cachedisk1 now will terminate both the instances and it is no longer faulttolerant?
 
 
 
 
 
regards,
 
Bilal
 
 

> Date: Sat, 22 May 2010 02:18:51 +1200
> From: squid3_at_treenet.co.nz
> To: squid-users_at_squid-cache.org
> Subject: Re: [squid-users] Running Multiple instances and reporting confusion.
>
> GIGO . wrote:
>> Hi all,
>>
>> I am running multiple instances of squid on the same machine. One
>> instance is taking the clients request and forwarding to its parent
>> peer at 127.0.0.1. All is going well. However there is a confusion
>> related to reporting through sarg. To capture the client activity
>> sarge is parsing the access.log file of the instance i.e user facing
>> which is correct. However obvioulsy it is depicting a wrong in-cache
>> out-cache figures as this value should be instead of the instance
>> which is managing/doing caching.
>>
>> Is there a way/trick to manage this? Is it possible that a cache_hit
>> from a parent cache be recorded as in-cache in the child?
>>
>
> The parent cache with the hier_code ACL type may be able to log only the
> requests that did not get sent to the child.
>
> The child cache using follow_x_forwarded_for trusting the parent proxy
> and log_uses_indirect_client should be able to log the remote client IP
> which connected to the parent with its received requests.
>
> Combining the parent and child proxies logs line-wise for analysis
> should then give you the result you want.
>
> That combination is a bit tricky though, since we have only just added
> TCP reliable logging to Squid-3.2. UDP logging is available for 2.7 and
> 3.1, but may result in some lost records under high load. With either of
> those methods you just need a daemon to receive the log traffic and
> store it in the one file.
>
> Amos
> --
> Please be using
> Current Stable Squid 2.7.STABLE9 or 3.1.3
_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969
Received on Thu May 27 2010 - 18:38:12 MDT

This archive was generated by hypermail 2.2.0 : Fri May 28 2010 - 12:00:06 MDT