Re: [squid-users] Re: WARNING: Could not determine this machines public hostname. Please configure one or set 'visible_hostname'.

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Sat, 02 Nov 2013 14:46:26 +1300

On 2/11/2013 1:42 p.m., Dr.x wrote:
> Alex Rousskov wrote
>> On 11/01/2013 02:39 PM, Dr.x wrote:
>>
>>> in smp , im trying to let the acl load on a specific process , i mean
>>> that
>>> the acl verification watse alot of cpu ,
>> ACL verification _wastes_ CPU only if you do not need those ACLs to be
>> verified. If that is the case, simply remove them. In all other cases,
>> the CPU cycles are not wasted but spent on doing useful work.
>>
>>
>>> and i think that if i use a
>>> specific process for acl verification will make a loabd balance of
>>> squid.conf on my multi process.
>> Sorry, I do not follow your logic. Restricting some work such as ACL
>> processing to one CPU is more likely to make the "balance" worth, not
>> better, right? Why do you want to do that?
>>
>> Is your current CPU core balance a bottleneck? Have you solved all other
>> Squid-related problems? If you cannot answer "yes" to both questions,
>> then you are most likely doing what some call "premature optimization".
>> Focus on removing what you think is the performance bottleneck instead.
>> If you do not know where the bottleneck is, then focus on finding it.
>>
>>
>> Meanwhile, until you reach a very good level of Squid understanding, it
>> is best to use the same squid.conf for all Squid workers. While certain
>> exceptions to this rule of thumb are technically possible, random
>> attempts at giving different workers different configurations will
>> usually result in a broken Squid.
>>
>>
>>> here is Smp related configs :
>>> ##################################################
>>> if ${process_number} = 4
>>> visible_hostname squid
>>> acl blockkeywords dstdomain "/etc/squid/deny.acl"
>>> http_access deny blockkeywords
>>> http_port 127.0.0.1:4008
>>> http_access allow localhost manager
>>> endif
>>> #######################################################################
>>> workers 4
>>> cpu_affinity_map process_numbers=1,2,3 cores=1,3,5
>>> ####################################################################
>>
>>> 2013/11/01 16:37:29| WARNING: Could not determine this machines public
>>> hostname. Please configure one or set 'visible_hostname'.
>>>
>>>
>>> why ?!!
>> Because you have not configured visible_hostname for any of your Squid
>> processes except process #4.
>>
>> BTW, you also have not configured any access rules for most of your
>> workers which will result in them denying all requests they get.
>>
>>
>> HTH,
>>
>> Alex.
> hi ,
> i just want to let acl checking far from process # 1
>
> with config above ,
> i pumped about 500 users and i monitored my cores
>
> i found that process # 1 is about 30 % and all others about 10 %
>
> i think if i let acl verification far from process # 1 , it will make better
> for squid !!!
>
> is my suggestion better ??? or let acl verification shred on all processes
> ??
> ???

I think there are some other factors more likely to be the cause of
this. Namely that any two KB of HTTP traffic are *not* equal in
processing requirements.

The "load balancing" is not balancing of CPU load but of TCP connection
count. More properly what is being done could be called load
*splitting*. Additional to that TCP connection count has no relation to
either HTTP/1.1 message size or HTTP/1.1 request message count. HTTP
message count is directly related to CPU work done parsing the message
and doing calculations on it (including ACLs). Message size and count
both relate to delivery time and take up CPU in very different amounts
doing that.

So splitting the load by connections will always result in differences
in CPU consumption. A squid worker will take what CPU cycles it needs to
handle the traffic it is passed, when it gets too busy it spends more
time processing that traffic than checking for new connections - leaving
those connections for other workers with less load to pick up quicker
and start spendign their spare CPU cycles handling. There is nothing to
worry about CPU loading unless there is a bottleneck with a loaded
worker slowing the whole system down (such as sending all traffic
through a single worker for ACL processing...) or you reach the point
where workers are all heavily loaded (in which case you need more
workers, possibly on another machine).

Amos
Received on Sat Nov 02 2013 - 01:46:36 MDT

This archive was generated by hypermail 2.2.0 : Sat Nov 02 2013 - 12:00:05 MDT