> If you are up for the task to develop this point in squid code and kind
> of port or redesign the way squid recognize a cache_peer down state it
> would be wonderful for many admins.
mh, we can see in the cache.log that squid says "parent down/dead". so I will recognize it first. but it seems that somewhere it hangs and gets slow, maybe still waiting for an answer, although squid first marked the parent down.
I am still looking for a way to really check and prove it. at the moment it is just the "feeling" while surfing that it is slow, we don'T have any numbers.
one more problem - as so often - we have at about 600 users on our location, one of 150 locations, so it is always difficult to check thinks in production environment. when we are on the development system only a few (<5) users are surfing. so some effect won't happen because everything is fast enough for those 5 but when 600 will access...
>
> Just one point: is this PC access the proxy as a forward proxy or the
> proxy intercepts the requests?
it is a forwarding proxy, so we have setup using proxy in the settings of the browser, either via proxy.pac or manual settings.
>
> Eliezer
>
> On 07/03/2013 03:01 PM, Rietzler, Markus (RZF, SG 324 /
> <RIETZLER_SOFTWARE>) wrote:
> > we have setup a squid hierarchy in our environment.
> >
> > all PCs are talking to a local proxy_user in their location (up to 150
> locaitons).
> > those proxy_user will have setup parent-proxies. with different acl we
> define wether it is an intranet or an internet access and will forward the
> request to proxy_inter or proxy_intra.
> >
> > so:
> >
> > PC -> proxy_user [some ACL]-> proxy_inter -> proxy_dmz -> {internet}
> > -> proxy_intra
> >
> > in fact we have at the moment 4 separate servers working as proxy_inter
> and proxy_intra. so it really means
> >
> >
> > PC -> proxy_user [some ACL]-> proxy_inter1
> > -> proxy_inter2
> > -> proxy_inter3
> > -> proxy_inter4
> >
> > we do this as HA and fallback. so in the past we could just shut down
> proxy_inter1 and proxy_inter2 without any problem. ok, the load on the
> remaining proxies (inter2, inter3) will increase but this can be handled
> and the user won't suffer (much/at all) from missing one of the four
> parents. proxy_user will detect the dead parent and will switch to the
> remaining parents. if proxy_inter1 comes back it will used again. so we
> have a very robust setup. where we can shutdown server1 or stop squid
> (proxy_inter1) on server1.
> >
> > this all worked very well with squid 2.7. we have upgraded to squid 3.2
> and with the same setup we had one big problem. I have to add, that the
> proxie_user now runs in smp-mode with 2 workers defined. if all proxies
> are up everything is ok. surfing the internet is fast and reliable. but
> after a electricity failure only two of our four central servers came up.
> so we only had proxy_inter1 and proxy_inter3 running, inter2 and inter4
> were dead. now the problem was, that the load on inter1 and inter3 was
> absolutely ok, no problem. load on proxy_user seems also ok, but you could
> not surf very well, all requests were sloooooow and some of the failed
> completely.
> >
> > so just going from squid 2.7 to 3.2 had changed the behavior with dead
> parents.
> >
> > I am looking for a reason, why 3.2 will behave so bad in this case.
> >
> >
> >> >I would imaging you have a PC and on it 4 proxies as cache_peers and
> you
> >> >would like to not have an option for a connection to be down??
> >> >If do and it's on a PC then what version of squid are you using?
> >> >ICP is not to detect if the proxy is up but to*know* if the proxy has
> >> >the specific cache object in case it's on one of the 4 the request
> would
> >> >pass thorough it.
> >> >there is another option that existed on squid 2.X that checks if the
> >> >cache_peer is up.
> >> >I built a helper that can help you detect if there is a problem in on
> of
> >> >the cache_peers to minimize the downtime to very very low.
> >> >https://github.com/elico/squid-
> >> >helpers/tree/master/squid_helpers/proxy_hb_check
> >> >
> >> >the above link contains the helpers which are very simple but are not
> >> >optimized for very high-load.
> >> >You can optimize the usage of a similar helper when used with squid
> >> >internal ttl for 2 secs and use the src IP instead of the url which is
> >> >changing all the time.
> >> >
> >> >If you have more questions feel free to continue this thread.
> >> >If you have an idea on how to integrate the feature into squid many
> will
> >> >be happy.
> >> >
> >> >Best Regards,
> >> >Eliezer
> >> >
> > hi eliezer,
> >
> >
