On 2017/11/16 10:55 PM, Alex Rousskov wrote:
On 11/16/2017 12:18 PM, Evan Pierce wrote:
Any idea why when using www.speedtest.net on my squid proxy ( squid
3.5.27 on Centos 6.9) gives consistently false/bad speeds while doing a
speed test. The actual speed when downloading a file from a actual web
server like say the microsoft website is consistently good (30Mb/s fiber
- download speed 3.4MB/s) but a speed test done at the same time sits at
around 3 to 4Mb/s. I have tried turning caching off and various other
"tuning" settings on squid but nothing has fundamentally altered the
speed. Running command line speedtest gives a correct speedtest from the
squid host. Test machine was machine running firefox and chrome with the
proxy statically configured and wasn't under any load. A similarly
configured squid on smaller hardware and the same service provider runs
consistently gives an accurate speedtest (same centos and squid
versions). Any one have any ideas?
I trust you have checked cache.log, system log, and network interface
statistics for warnings, errors, and red flags unique to the non-working
use case.
Yes ... no obvious "red flags"
Make sure that browser-proxy path is about the same in all tests you
compare. The problem might be related to browser-Squid communication.
In both cases the test browser machines are physically cabled in to the
same gigabit switch as the squid proxy/firewall machine
Since you have a "working" case (on "smaller hardware"), I would try the
following using identical Squid versions:
1. Use the default Squid configuration with Squid memory caching
disabled on both boxes. Is one setup still a lot "slower" than the other?
Yes, however the "bigger" site has more vlans so it has slightly more
https access lines and acls.
2. Compare access.logs and mgr:info output of the two tests (one test
performed after a clean Squid start). Any unexpected differences?
Nothing jumps out at me.
3. If you have not already, test a Squid configuration identical to that
"working" case (you can rename directories/hostnames if really needed,
of course, but do not change anything you do not have to change). Is one
setup still a lot "slower" than the other?
Yes one is slower.
4. Comparing cache.logs of virtually identically configured Squids with
debug_options set to ALL,3 or higher may expose the critical difference.
Debugging will slow Squid down a lot, of course, but perhaps you will
see that one of the Squids is doing something that the other one does
not do.
I can't see anything but both are in production and being used while I
was testing so generated a lot of data
HTH,
Alex.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
