Sorry for the late reply. See inline - including another apology. On Tue, Nov 10, 2009 at 14:23, Henrik Nordstrom <henrik@xxxxxxxxxxxxxxxxxxx> wrote: > tis 2009-11-10 klockan 14:01 -0800 skrev Kurt Buff: > >> > Browsing on the proxy without using the proxy is the same as going via >> > the proxy in terms of networking.. > >> Yes. >> >> But currently all users on the network are forced through squid to >> browse the web. > > Which is relevant to the case of browsing directly from the proxy server > host how? It might not be relevant to that, but it's relevant to the fact that all users use squid, and bypassing squid gives me a baseline of performance. Squid is on a separate subnet, which lies between the backbone switch and the firewall - this subnet contains only the squid box and our mail gateway. Thus, measuring direct browsing vs. browsing through squid seems very relevant to the question of whether squid is at least some part of the issue. I frankly don't think it is, but need to verify that. Or, more accurately, I don't think that squid as a technology is at issue, but that there might be a problem with the hardware it's running on, or the connection to the squid box (cable, port, etc.). >> I'm opening an exception in the firewall this evening so that I can >> turn off the proxy settings on my workstation and go to the firewall >> directly. I'll turn off the proxy settings for FireFox so that I can >> compare performance against IE, which will be using squid. > > Testing from another host than the proxy itself is interesting, but not > conclusive regarding if the problem is Squid or something else.. I think it's more than just interesting. I think it's entirely pertinent. However... >> If I get anything like normal response times FF, but not in IE, I'll >> have evidence that it's squid. If they both have really crappy times >> loading, then it's something else, and I'll be that much further ahead >> in troubleshooting. > > The first is not a valid conclusion due to the large differences > networking wise how the requests is sent. There is just too many other > things that can go wrong, and very often is. I think I grasp your meaning here: FF vs. IE difference might well mask issues with external influences, such as whether or not squid (or some part of the chain of connections - hardware and software - from workstations to the Internet of which squid is a part) is at fault. > Testing on a workstation not using the proxy compared to a workstation > using the proxy will honestly not tell you anything, except if that also > fails then you know you can completely rule out it's anything related to > the proxy. > > If the workstation going direct works fine then you are pretty much > still at the same square in terms of testing, still not knowing if it's > Squid, the server Squid runs on, the tested web site, firewalls going > bad, broken routers (currently having a fight with a such case where a > router randomly messes with TCP traffic in certain flows but icmp > works). And this is where I have to apologize - I didn't mean to put all of the onus on squid. It was a convenient shorthand for the entire host configuration of which squid is a part. > By testing by running a browser on the proxy server itself you can > identify if the problem is Squid or something outside Squid. Unless you think lynx (or some other text-based browser, or using wget/curl/other) is sufficient, I am leery of doing this. I'd have to install all the bits to do this, including X and a browser, and all that. I'm all up for learning, though, so your suggestion on how to do this is very warmly welcomed. > If the test where you run a browser directly on the Squid server host > works fine when going direct but fails when going via Squid on the same > host then you know it's most likely a Squid issue and you should file a > Squid bug report. Again, I apologize - this wasn't directly about Squid, but about the host as a whole, and where to begin troubleshooting. > If the test where you run a browser directly on the Squid server host > shows the same problems when not using the proxy then you know it's > something outside Squid, and you need to continue searching a bit to > find the culpit, which could be any of > > - Problem with the Squid server host (bad cables, bad drivers, problem > in duplex negotiation, bad operating system, etc..) > > - Problem triggered by differences in the TCP/IP capabilities of the > Squid server host. This is for example a very common problem when Squid > is running on Linux hosts as the linux TCP/IP stack is far more evolved > than Windows and often triggers problems in other equipment such as > firewalls, routers etc causing very bad response times, partially loaded > pages etc. As noted, I'm running it on FreeBSD. I must also mention, if I didn't before, that this is relatively new behavior - we started seeing these non-workhours slowdowns about two weeks ago, and I'm at a complete loss as to why. I have not changed anything in that part of our environment that would have an effect like this. I was unable to do any testing in the past few days - a new child is taking me away from working longer hours... I hope to do some work on it this weekend. Kurt
