Slow speedtest results

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Slow speedtest results

Evan Pierce
Hi all

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?

thanks

Evan

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Slow speedtest results

Antony Stone
On Thursday 16 November 2017 at 19:18:15, Evan Pierce wrote:

> Hi all
>
> 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.

> A similarly configured squid on smaller hardware and the same service
> provider runs consistently gives an accurate speedtest (same centos and
> squid versions).

Please explain in more detail what the difference is between these two:

 - what hardware?

 - what does "similarly configured" mean - what are the differences?

 - what are the differences in reported results?

Oh, and just to be sure - are these both on the same connection, or on two
different connections to the same provider?


Antony.

--
I just got a new mobile phone, and I called it Titanic.  It's already syncing.

                                                   Please reply to the list;
                                                         please *don't* CC me.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Slow speedtest results

Alex Rousskov
In reply to this post by Evan Pierce
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.

Make sure that browser-proxy path is about the same in all tests you
compare. The problem might be related to browser-Squid communication.

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?

2. Compare access.logs and mgr:info output of the two tests (one test
performed after a clean Squid start). Any unexpected differences?

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?

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.


HTH,

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Slow speedtest results

Evan Pierce
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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Slow speedtest results

Alex Rousskov
On 11/16/2017 02:53 PM, Evan Pierce wrote:
> I can't see anything but both are in production and being used while I
> was testing so generated a lot of data

Sorry, I did not realize you are using live Squids for these tests!
Combining real and test traffic makes triage a lot harder and pretty
much all of the tests I mentioned are nearly pointless on live Squids,
especially if those Squids handle substantially different traffic
streams. If there is no way to take these Squids offline for a test then

a) Consider starting a separate Squid instance (on each box) using the
otherwise default config with no memory cache and a dedicated http_port.

b) Consider fixing your overall architecture so that it becomes possible
to take any single Squid instance offline when needed without serious
effects on users.

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users