Re: Re: WARNING: Could not determine this machines public hostname. Please configure one or set 'visible_hostname'.

[Amos Jeffries <squid3@xxxxxxxxxxxxx>]

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