Hi Amos,
Thank you for the response, actually i'am working with IPV4 on my network
architecture.
All the client are connected to a DC Windows 2012 server that manage
DNS,DHCP and AD.
The proxy server is not under the domain controller and have a static Ip
adress.
Any way I will try to run MTU Path
What is the authoritative source of cache statistics? The slots
occupied due to PUT requests (as suggested by mgr:storedir stats is
quite concerning.
Is there some additional config that needs to be added to ensure that
PUTs are simply bypassed for caching purpose.
NOTE: fwiw, I have verified that
On 17 Feb 2014, at 01:15, Monah Baki wrote:
> uname -a
> SunOS proxy 5.11 11.1 sun4v sparc SUNW,SPARC-Enterprise-T5220
>
> Here are the steps before it fails
>
> ./configure --prefix=/usr/local/squid --enable-async-io
> --enable-cache-digests --enable-underscores --enable-pthreads
> --enable-s
uname -a
SunOS proxy 5.11 11.1 sun4v sparc SUNW,SPARC-Enterprise-T5220
Here are the steps before it fails
./configure --prefix=/usr/local/squid --enable-async-io
--enable-cache-digests --enable-underscores --enable-pthreads
--enable-storeio=ufs,aufs --enable-removal-policies=lru,
heap
make
c -I
uname -a
SunOS proxy 5.11 11.1 sun4v sparc SUNW,SPARC-Enterprise-T5220
Here are the steps before it fails
./configure --prefix=/usr/local/squid --enable-async-io
--enable-cache-digests --enable-underscores --enable-pthreads
--enable-storeio=ufs,aufs --enable-removal-policies=lru,heap
make
c -I.
On Sun, Feb 16, 2014 at 3:39 PM, Amos Jeffries wrote:
> On 17/02/2014 11:41 a.m., Rajiv Desai wrote:
>> I am using Squid Cache:
>> Version 3.HEAD-20140127-r13248
>>
>> My cache dir is configured to use rock (Large rock with SMP):
>> cache_dir rock /mnt/squid-cache 256000 max-size=4194304
>>
>> My
On 17/02/2014 11:41 a.m., Rajiv Desai wrote:
> I am using Squid Cache:
> Version 3.HEAD-20140127-r13248
>
> My cache dir is configured to use rock (Large rock with SMP):
> cache_dir rock /mnt/squid-cache 256000 max-size=4194304
>
> My refresh pattern is permissive to cache all objects:
> refresh_
I am using Squid Cache:
Version 3.HEAD-20140127-r13248
My cache dir is configured to use rock (Large rock with SMP):
cache_dir rock /mnt/squid-cache 256000 max-size=4194304
My refresh pattern is permissive to cache all objects:
refresh_pattern . 129600 100% 129600 ignore-auth
I uploaded 30 GB of
On Sat, Feb 15, 2014 at 10:12 AM, Dr.x wrote:
> @Rajiv Desai
>
> have u found increasing in bandwidth saving when u used large rock ??
Yes. Large rock works pretty well with multiple SMP workers (in my
limited experience for past 5 days).
I get 85% hit rate for previously read (and thereby cached
On 02/16/2014 05:05 PM, Dr.x wrote:
cpu_affinity_map process_numbers=1,2,3,4,5,6,7,8,9
cores=2,4,6,8,10,12,14,16,18
Just wondering what would that even do?
If one of the CPUs\Cores is idle there is not much you can do.
It should be idle to not consume power.
It is not like it will consume power
hi all ,
i have implemented aufs with rock
i had that logs at logs of rock cache.log !!!
what does that mean ??
i have done the following
i have 5 hardsisk aufs dir
2hardsisk rock dir
i have as below :
workers 8
#dns_v4_first on
cpu_affinity_map process_numbers=1,2,3,4,5,6,7,8,9
cores=2,4,6,8
Sorry, I confused between PUT and DELETE. Actually the DELETE is
request doesn't invalidate the cache on 202 response.
And this doesn't conform with the spec:
"If a DELETE
request passes through a cache that has one or more stored responses
for the effective request URI, those stored response
On 16/02/2014 10:41 p.m., Boaz Citrin wrote:
> Hello,
>
> I want to invalidate the cache when my server returns 202 to a PUT
> request, however it seems like Squid ignores the Cache-Control when
> return code is 202.
>From the latest specification
http://tools.ietf.org/html/draft-ietf-httpbis-p2-
Hello,
I want to invalidate the cache when my server returns 202 to a PUT
request, however it seems like Squid ignores the Cache-Control when
return code is 202.
Tried to set must-revalidate or even not to return any Cache-Control
header but these all result no update to cache so subsequent GET
r
14 matches
Mail list logo
