On 30/08/2013 4:47 a.m., Matthew Ceroni wrote:
Hi: I am seeing a peculiar symptom of slow responses times for certain websites. On my production proxy server (which has a large on disk cache and in memory cache) if I navigate to www.wellsfargo.com and click on Comericial and then login, the login page takes upwards of 60 seconds to display. Tailing the access logs shows this as the total response time is 60k ms. As I was using CentOS and it only has 3.1 in the official repositories I spun up a test proxy and upgraded to the latest squid 3.8.1. I then tested going to the same website. Everything appeared great. The WellsFargo site loaded up instantly. Therefore I upgraded my physical production proxy to 3.8.1 and hoped to see the same thing. Unfortunately that did not happen. I still saw 60 seconds response times. I then went back to my test proxy and tried to test again. While point to the test proxy the page loaded just fine. However the peculiar thing is in the access log I wasn't see a log message logged right away. Then after 60 seconds or so I would see 29/Aug/2013:09:39:22 -0700 41553 192.168.2.123 TCP_MISS/200 23273 CONNECT wellsoffice.wellsfargo.com:443 HIER_DIRECT/wellsoffice.wellsfargo.com - So while the page loaded instantly (I even cleared the browser cache, restarted squid so the memory cache was cleared, there is no disk cache on my test proxy) squid reported that it took 41 seconds to service.
This is a CONNECT. It is *not* a single object load like other requests types.
What CONNECT actually contains is a SSL handshake/setup then an entire series of multiple HTTP / Websockets / SPDY transactions inside it. With delays between each request-response pair same as in normal traffic. If you have users with accounts in Facebook or GoogleTalk you probably see some of these CONNECT requests taking hours or even days to complete.
What you are seeing is that this *entire* multiple transaction process is taking 41.553 seconds. Whether that is good or bad depends on the how many transactions are taking place inside the tunnel. Squid has nothing to do with it beyond setting up the TCP connection requested.
Amos
