On 12/09/2016 3:04 a.m., Omid Kosari wrote: > > I refer to following messages .i have same problem > The "problem" is misunderstanding of the log entry meaning. > > FredT wrote >> Hi Amos, >> >> We have done additional tests in production with ISPs and the ORIGINAL_DST >> in tproxy cannot be cached. >> In normal mode (not tproxy), ORIGINAL_DST can be cached, no problem. >> But once in tproxy (http_port 3128 tproxy), no way, it's impossible to get >> TCP_HIT. >> >> We have played with the client_dst_passthru and the host_verify_strict, >> many combinaisons on/off. >> By settings client_dst_passthru ON and host_verify_strict OFF, we can >> reduce the number of ORIGINAL_DST (generating DNS "alerts" in the >> cache.log) but it makes issues with HTTPS websites (facebook, hotmail, >> gmail, etc...). Nod. That is the purpose of those controls. So they are working. >> We have also tried many DNS servers (internals and/or externals), same >> issue. >> >> I read what you explain in your previous email but it seems there is >> something weird. >> The problem is that the ORIGINAL_DST could be up to 25% of the traffic >> with some installations meaning this part is "out-of-control" in term of >> cache potential. Any server type could be up to 100%. The type of server used implies nothing about caching potential. The reverse is true: caching potential implies server type, with adjustments for traffic mode type and squid.conf settings. For example: HIT implies HEIR_NONE. MISS with intercept/tproxy implies ORIGINAL_DST or a peer. REFRESH with intercept/tproxy implies ORIGINAL_DST or a peer. MISS in forward-proxy implies DIRECT or a peer. REFRESH in forward-proxy implies DIRECT or a peer. > > FredT wrote >> Hi Eliezer, >> >> Well, we have done many tests with Squid (3.1 to 3.5.x), disabling >> "client_dst_passthru" (off) will stop the DNS entry as explained in the >> wiki, the option directly acts on the flag "ORIGINAL_DST". >> As you know, ORIGINAL_DST switches the optimization off (ex: StoreID) then >> it's not possible to cache the URL (ex: >> http://cdn2.example.com/mypic.png). ORIGINAL_DST does nothing. It is simply a label indicating which type of server supplied the HTTP response message for the transaction. >> >> In no tproxy/NAT mode, the client_dst_passthru works perfectly by >> disabling the DNS entry control, so optimization is done correctly. >> But in tproxy/NAT, the client_dst_passthru has no effect, we see >> ORIGINAL_DST in logs. >> >> So, maybe I'm totaly wrong here the client_dst_passthru is not related to >> the ORIGINAL_DST, "client_dst_passthru on" makes Squid use ORIGINAL_DST (client provided) server instead of DIRECT (DNS lookup) server(s) for *all* intercepted traffic. Even requests where DIRECT is possible. > or there is an explaination why the client_dst_passthru >> does not act in tproxy/NAT... >> There is. The "transparent" part of "transparent interception proxy" means that MISS should use the same server the client was originally sending its request to (the ORIGINAL_DST server). >> Bye Fred > > please look at following results ... > > 60% vs 2% hit ratio(bytes) . The problem is ORIGINAL_DST > The only visible problem is why that 2% exists. ==> ORIGINAL_DST is should *only* ever be used on MISS or REFRESH/revalidate traffic. Never on a HIT. Thus zero (0%) hit-ratio is the expected behaviour. For the same reason that a report of the log traffic using "grep -v HIT" will show zero cache ratio. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
