What is a method to measure webpage lag?

I have been observing slow load times for webpages recently (both wired and wireless). This recent thread raised the potential that SQM on 19.x might be degraded vs 18.x. Since I am running 19.07.0-rc2 on a R7800, I wanted some a quantitative and reproducible way to get some numbers rather than relying on perception.

I thought a place to start would be using a tool like dig to measure DNS response rates and ended up finding this script which seemed to do just that. Here are the raw data if you're interested.

On my wired desktop, I cleared the local DNS cache systemd-resolve --flush-caches) and ran the script with SQM disabled, and then with it enabled.

This table shows the ratio of average response times (without SQM/with SQM). Values >1 mean SQM was faster.


For the most part, they are within 2-fold. The two exceptions are freenom and neustar. In my case, I use quad9 so I am not concerned about these (actually never heard of them before finding that script).

The conclusion I came to is there is no appreciable difference in DNS response rates with or without SQM enabled.

I think I still need some test of the entire transaction (dns lookup, data download) to answer the original question. Before I go hacking together some shell script that goes out and times webpage loads, perhaps someone has an idea to test that is already made?

1 Like

SQM testing with single connections gives you little in isolation.

You either need to dig lower... ( internal sqm counters, something like perf which is generally a recompile ) or simulate multiple streams at a given scale and frequency... which is the domain of iperf3 and related tools...

But for raw simplicity... have a few clients... one chugging a debian dvd... and the other one forking a few httping 's might get you close... the key is to mimick the real demands ( number of clients, connections, packet sizes ) in a way that you can control / reproduce....

I'd me more inclined to monitor htop (etc) / sqm stats during peak periods... and do the same with the firmware switched first... if nothing more than to first eliminate other core os processes with relation to resource utilisation, so you know for sure that your looking in the right place.