Re: [squid-users] TCP_MISS:FIRST_UP_PARENT error when use COSS store type

Nguyen Cao Cuong wrote:
> Thank Amos so much,
>
> I have one question,
> How to configure squid with coss store type to arvice TCP_IMS_HIT:NONE code in access.log?

Using COSS will not automatically cause *_HIT, no more then any other
storage type.

AFAIK, the "max-size=1048576" you already have configured prevents
objects over 1 MB being stored there.

If objects are still being TCP_MISS then you need to look at each object
and see why it is not able to be stored.
The cacheability engine is good for finding out all about that
http://www.ircache.net/cgi-bin/cacheability.py
or the newer http://redbot.org which has been created as a slightly
better version (though still slightly experimental AFAIK).

Amos

>
>> -----Original Message-----
>> From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
>> Sent: Wednesday, May 27, 2009 7:42 PM
>> To: Nguyen Cao Cuong
>> Cc: squid-users_at_squid-cache.org
>> Subject: Re: [squid-users] TCP_MISS:FIRST_UP_PARENT error when use COSS store type
>>
>> Nguyen Cao Cuong wrote:
>>> Hi Everybody
>>> I am a newbie in Squid.
>>>
>>> I have a problem when configure squid with coss store type, can everybody help me to resolve
> this
>>> problem?
>>> �squid.conf
>>> cache_effective_user squid
>>> cache_effective_group squid
>>> cache_dir coss /usr/local/squid/var/cache 1024 block-size=512 max-size=1048576
>>
>>
>>> cache_swap_log /usr/local/squid/var/cache/cache_swap_log
>> Log for debug storage info, not very useful. You can set its to "none".
>>
>>> http_port "IP address1":80 accel defaultsite="IP address2"
>> So when random people on the Internet request "http://IPaddress2/ they
>> are magically supposed to know to connect to IPaddress1???
>>
>> #1 rule for testing a reverse-proxy is to set it up with the correct
>> final names and Squid settings for things. Only the public DNS and test
>> browser settings differ.
>>
>> ... defaultsite="public domain name"
>>
>> as per:
>> http://wiki.squid-cache.org/ConfigExamples/Reverse/BasicAccelerator
>>
>>> cache_peer "IP address2" parent 80 0 no-query originserver
>>> cache_mem 64 MB
>>> refresh_pattern data/test/.* 0 25% 43200 ignore-reload
>>> refresh_pattern data/.* 0 0 0
>>> refresh_pattern . 0 25% 4320 ignore-reload
>>> client_persistent_connections off
>>> server_persistent_connections off
>> When turned on these are very useful for reducing server load. Without
>> them the server is open to the N connections flooding in when Squid has
>> many clients.
>>
>>> acl all src 0.0.0.0/0.0.0.0
>>> http_access allow all
>> eeek!
>>
>>> emulate_httpd_log on
>>> access_log /usr/local/squid/var/logs/access.log common
>>> cache_log /usr/local/squid/var/logs/cache.log
>>> cache_store_log /usr/local/squid/var/logs/store.log
>>> forwarded_for off
>>> header_access X-Cache deny all
>>> header_access X-Squid-Error deny all
>>> header_access Via deny all
>> Welcome to WebApp hell.
>>
>>> �problem
>>> After restart squid and request a file (ex: logo.png) from browser, have
> TCP_MISS:FIRST_UP_PARENT
>>> error in access.log file.
>> These are NOT errors. They are IMS (if-modified-since) requests succeeding.
>> Errors have a code 4xx or 5xx or 6xx where the '304' is on that line.
>>
>>> [27/May/2009:16:50:10 +0700] "GET http://"IP address2"/logo.png HTTP/1.1" 304 157
>>> TCP_MISS:FIRST_UP_PARENT
>>> [27/May/2009:16:50:16 +0700] "GET http:// IP address2"/logo.png HTTP/1.1" 304 157
>>> TCP_MISS:FIRST_UP_PARENT
>>> [27/May/2009:16:50:17 +0700] "GET http:// IP address2"/logo.png HTTP/1.1" 304 157
>>> TCP_MISS:FIRST_UP_PARENT
>> Strange that these requests even get into Squid. They are supposed to be
>> a direct IP->IP link from browser to IPaddress2.
>>
>> Amos
>> --
>> Please be using
>> Current Stable Squid 2.7.STABLE6 or 3.0.STABLE15
>> Current Beta Squid 3.1.0.8 or 3.0.STABLE16-RC1
>

-- 
Please be using
   Current Stable Squid 2.7.STABLE6 or 3.0.STABLE15
   Current Beta Squid 3.1.0.8 or 3.0.STABLE16-RC1