On tor, 2008-07-17 at 08:17 -0700, John Doe wrote: > So I did put back the tcp_outgoing_address. > Will I have to use it forever or just for testing?
You should have it for as long as you are running multiple instances on the same server.. > Does it have to be an IP different than the regular IP? The main ip per instance is easiest. > Again, post a bit long... > > squid1: 192.168.17.11 / tcp_ougoing 192.168.17.15 > squid2: 192.168.17.12 / tcp_ougoing 192.168.17.16 > squid3: 192.168.17.13 / tcp_ougoing 192.168.17.17 > squid4: 192.168.17.14 / tcp_ougoing 192.168.17.18 > > digest_rebuild_period 10 minutes > > I start the squids after an rm of the cache_dirs. > > ### I ask squid1 for object1 > > squid1: > 1216303244.157 2 192.168.17.11 TCP_MISS/200 2901 GET > http://192.168.16.23/index.html - FIRST_UP_PARENT/apache text/html > squid2: > 1216303243.855 0 192.168.17.11 UDP_MISS/000 52 ICP_QUERY > http://192.168.16.23/index.html - NONE/- - > 1216303244.155 0 192.168.17.15 TCP_MEM_HIT/200 477 GET > internal://squid2/squid-internal-periodic/store_digest - NONE/- > application/cache-digest > squid3: > 1216303244.053 0 192.168.17.11 UDP_MISS/000 52 ICP_QUERY > http://192.168.16.23/index.html - NONE/- - > squid4: > 1216303243.314 0 192.168.17.11 UDP_MISS/000 52 ICP_QUERY > http://192.168.16.23/index.html - NONE/- - > Then, 1mn later, squid3: > 1216303304.155 0 192.168.17.15 TCP_MEM_HIT/200 477 GET > internal://squid3/squid-internal-periodic/store_digest - NONE/- > application/cache-digest > Then, 1mn later, squid4: > 1216303364.156 0 192.168.17.15 TCP_MEM_HIT/200 477 GET > internal://squid4/squid-internal-periodic/store_digest - NONE/- > application/cache-digest > > ### I ask squid3 for object2 > > squid1: > 1216303708.034 0 192.168.17.13 UDP_MISS/000 55 ICP_QUERY > http://192.168.16.23/img/spain.gif - NONE/- - > 1216303708.324 0 192.168.17.17 TCP_MEM_HIT/200 477 GET > internal://squid1/squid-internal-periodic/store_digest - NONE/- > application/cache-digest > squid2: > 1216303707.821 0 192.168.17.13 UDP_MISS/000 55 ICP_QUERY > http://192.168.16.23/img/spain.gif - NONE/- - > squid3: > 1216303708.330 6 192.168.17.13 TCP_MISS/200 7300 GET > http://192.168.16.23/img/spain.gif - FIRST_UP_PARENT/apache image/gif > squid4: > 1216303708.242 0 192.168.17.13 UDP_MISS/000 55 ICP_QUERY > http://192.168.16.23/img/spain.gif - NONE/- - > Then, 1mn later, squid2: > 1216303768.325 0 192.168.17.17 TCP_MEM_HIT/200 477 GET > internal://squid2/squid-internal-periodic/store_digest - NONE/- > application/cache-digest > Then, 1mn later, squid4: > 1216303828.326 0 192.168.17.17 TCP_MEM_HIT/200 477 GET > internal://squid4/squid-internal-periodic/store_digest - NONE/- > application/cache-digest > > ### Etc... Now all objects are randomly spread each on 1 unique squid. > ### And in the meantime: > > squid2: > 1216303945.412 0 192.168.17.18 TCP_MEM_HIT/200 477 GET > internal://squid2/squid-internal-periodic/store_digest - NONE/- > application/cache-digest > squid3: > 1216303950.276 0 192.168.17.16 TCP_MEM_HIT/200 477 GET > internal://squid3/squid-internal-periodic/store_digest - NONE/- > application/cache-digest > Then, squid3: > 1216304005.426 0 192.168.17.18 TCP_MEM_HIT/200 477 GET > internal://squid3/squid-internal-periodic/store_digest - NONE/- > application/cache-digest > squid4: > 1216304010.277 0 192.168.17.16 TCP_MEM_HIT/200 477 GET > internal://squid4/squid-internal-periodic/store_digest - NONE/- > application/cache-digest > > ### I do another round... > ### Works well (3 UDP query and 1 HIT, unless the squid has it already) up to > object5... > ### Ask squid2 for object6 (squid1 has it, no UDP traffic in logs): > > squid2: > 1216304170.370 1 192.168.17.12 TCP_MISS/200 9042 GET > http://192.168.16.23/img/sweden.gif - FIRST_UP_PARENT/apache image/gif > squid4: > 1216304170.369 0 192.168.17.16 TCP_MISS/504 1585 GET > http://192.168.16.23/img/sweden.gif - NONE/- text/html > > Then works again for a few objects... > Then not: ask squid2 for object (no UDP traffic in logs). > > squid2: > 1216304475.185 0 192.168.17.12 TCP_MISS/200 8486 GET > http://192.168.16.23/img/polska.gif - CD_SIBLING_HIT/squid3 image/gif > squid3: > 1216304475.184 147 192.168.17.16 TCP_MEM_HIT/200 8392 GET > http://192.168.16.23/img/polska.gif - NONE/- image/gif > > ### I do another round... > ### ask squid2 for object1 (no UDP traffic)... > > squid1: > 1216304762.804 0 192.168.17.16 TCP_MEM_HIT/200 3018 GET > http://192.168.16.23/index.html - NONE/- text/html > squid2: > 1216304762.804 0 192.168.17.12 TCP_MISS/200 3112 GET > http://192.168.16.23/index.html - CD_SIBLING_HIT/squid1 text/html > > ### ask squid4 for object2 (no UDP traffic)... > > squid2: > 1216304825.551 0 192.168.17.18 TCP_MISS/504 1583 GET > http://192.168.16.23/img/spain.gif - NONE/- text/html > squid4: > 1216304825.552 1 192.168.17.14 TCP_MISS/200 7300 GET > http://192.168.16.23/img/spain.gif - FIRST_UP_PARENT/apache image/gif > > In fact, squid3 had it... For some reason squid4 thought squid2 had the object, but it didn't (or it had expired) so Squid4 recovered by going to apache. As there was no UDP traffic it's most likely a digest false hit. Regards Henrik
