[squid-users] Squid 3.3.12, Multiple process, requests serviced by process.
Oleg Chomenko
oleg at ims.ca
Mon Nov 10 20:28:28 UTC 2014
Hello,
We use a squid cache for our robots to collects an information from
client's web sites.
The squid running on FreeBSD 9.3 , squid version 3.3.13
the configuration is like this:
if ${process_number} = 1
http_port 3001
cache_peer 1.1.1.1 parent 4567 0 no-query no-digest no-netdb-exchange
round-robin connect-fail-limit=3
cache_peer 1.1.1.2 parent 4567 0 no-query no-digest no-netdb-exchange
round-robin connect-fail-limit=3
cache_peer 1.1.1.3 parent 4567 0 no-query no-digest no-netdb-exchange
round-robin connect-fail-limit=3
cache_peer 1.1.1.4 parent 4567 0 no-query no-digest no-netdb-exchange
round-robin connect-fail-limit=3
cache_peer 1.1.1.5 parent 4567 0 no-query no-digest no-netdb-exchange
round-robin connect-fail-limit=3
endif
if ${process_number} = 2
http_port 3001
cache_peer 1.1.1.1 parent 4567 0 no-query no-digest no-netdb-exchange
round-robin connect-fail-limit=3
cache_peer 1.1.1.2 parent 4567 0 no-query no-digest no-netdb-exchange
round-robin connect-fail-limit=3
cache_peer 1.1.1.3 parent 4567 0 no-query no-digest no-netdb-exchange
round-robin connect-fail-limit=3
cache_peer 1.1.1.4 parent 4567 0 no-query no-digest no-netdb-exchange
round-robin connect-fail-limit=3
cache_peer 1.1.1.5 parent 4567 0 no-query no-digest no-netdb-exchange
round-robin connect-fail-limit=3
endif
if ${process_number} = 3
http_port 3002
cache_peer 1.1.2.1 parent 4567 0 no-query no-digest no-netdb-exchange
round-robin connect-fail-limit=3
cache_peer 1.1.2.2 parent 4567 0 no-query no-digest no-netdb-exchange
round-robin connect-fail-limit=3
cache_peer 1.1.2.3 parent 4567 0 no-query no-digest no-netdb-exchange
round-robin connect-fail-limit=3
cache_peer 1.1.2.4 parent 4567 0 no-query no-digest no-netdb-exchange
round-robin connect-fail-limit=3
cache_peer 1.1.2.5 parent 4567 0 no-query no-digest no-netdb-exchange
round-robin connect-fail-limit=3
endif
if ${process_number} = 4
http_port 3002
cache_peer 1.1.2.1 parent 4567 0 no-query no-digest no-netdb-exchange
round-robin connect-fail-limit=3
cache_peer 1.1.2.2 parent 4567 0 no-query no-digest no-netdb-exchange
round-robin connect-fail-limit=3
cache_peer 1.1.2.3 parent 4567 0 no-query no-digest no-netdb-exchange
round-robin connect-fail-limit=3
cache_peer 1.1.2.4 parent 4567 0 no-query no-digest no-netdb-exchange
round-robin connect-fail-limit=3
cache_peer 1.1.2.5 parent 4567 0 no-query no-digest no-netdb-exchange
round-robin connect-fail-limit=3
endif
.....
# COORDINATOR
if ${process_number} = 16
http_port 3099
endif
workers 15
in total 15+1 processes is running, traffic load over 100 Mbit; around
50K req/min (total #)
Problem is:
when we restart the squid all request to port 3001 do serve only
upstream proxy defined for this process. after couple hours, we see
request served by upstream cache NOT belonged to this 3001 ports. (
like in example above can served by 1.1.2.4)
The rate depend on the load, up to 15% all requests can be served by
others upstream proxy NOT belonged to this port
we use a java application and our website to logging all requests we
generating and passing trough the cache server.
This behavior is a serious trouble for us .....
Thanks in advance for any tips to solve it (Thinking it an internal
request distribution mechanism produce a fault )
--
This electronic message, including any attachments, may contain
proprietary, confidential or privileged information for the sole use of the
intended recipient(s). You are hereby notified that any unauthorized
disclosure, copying, distribution, or use of this message is prohibited.
If you have received this message in error, please immediately notify the
sender by reply e-mail and delete it.
More information about the squid-users
mailing list