I’m running tinyproxy on a GL-AR750S. I’m the sole user of this router and traffic is light. tinyproxy is exceptionally slow on complex pages. I don’t get this behavior when I run tinyproxy on a different host.
If I route my traffic through tinyproxy, msn.com takes 30-40 seconds to load, uncached.
If I route my traffic through tinyproxy, MSN takes 3 seconds to load, cached.
If I send the same traffic direct (through the same router) it takes about 2 seconds, uncached.
If I route my traffic through tinyproxy, example.com loads in less than a second.
I put Wireshark on my laptop (where I’m running the browser), but all I can see is that the router/tinyproxy is taking several seconds to respond to some requests.
My first suggestion would be to run it on a different host.
These SoCs are really designed to do two things as cheaply as possible; provide a GUI that reviewers will say is “Highly powerful and easy to use” and to hit well-known benchmarks so they look good in reviews. Even a manufacturer with the attention to detail that I have seen from GL.iNet can’t overcome the architectural limitations of a single-core, MIPS-based processor and make it as powerful as a multi-core ARM/x86 CPU. There are also the challenges with “bare” flash (NOR and NAND both) being inappropriate for caching, and a limited amount of RAM available, compared to the page weight of even a couple minutes of browsing.
Guessing, the delays are perhaps due to the time required to set up the TLS connections to the remote servers. This is a non-trivial operation and modern browsers fire off ten or more connections simultaneously. A single-core, MIPS-based device may well be slow, or even CPU bound doing this. A quick check of https://www.msn.com/ shows over 250 individual requests using Chrome developer tools (and I have ad blocking in place, so it’s probably a lot more than that without).
@jeffsf - Thank you for your suggestions. You might be right. I notice that ‘top’ shows only about 35% idle when I’m not proxying, dropping as low as 10% when I’m pushing data via the proxy.
Looking at exactly what is consuming CPU (per top) when actively proxying, nothing individually is consuming even 10%, and only a handful of processes show more than 0%.
When I’m waiting and waiting for nytimes.com to display, “18% usr, 48% sys, 0% nic, 31% idle” and only 3 processes consuming any CPU, with 2%, 1%, and 1%.
Fully understood that these devices use slow flash, I don’t see any evidence in tinyproxy’s doc that it is doing caching.
This look like a box that is waiting for something, when I’m waiting on it.
That’s very high CPU utilization, as is ~50% sys. Handling the hard and soft IRQs for the Ethernet are likely what isn’t obvious in the output of top or the like.
Hmmm… It isn’t purely an issue of inadequate hardware. I removed tinyproxy and installed squid. With squid, results are much, much faster. They are as fast as non-proxied results, to a casual observer.
It’s not the routers fault, its just poor programming skills. Here is my own proxy solution running on an AR750s loading TLS pages with multiple connections as expected, nearly instantaneous:
I’ve abandoned tinyproxy on the AR750s. I can’t tell whether I’ve configured it wrong or it just doesn’t work well on this platform. squid works well. It does burn 25% of CPU when I’m loading MSN, but it loads it pretty close to the same speed as non-proxied.
My inner-geek would have preferred the simplicity of tinyproxy, but my ‘business goal’ is to proxy the traffic and squid is doing that.
I run a VPN. The VPN redirects all traffic via the VPN except “local LAN” traffic. For reasons not worth going into, I need one browser (out of the many I run) to NOT send its traffic via the VPN. By configuring that browser to proxy to the local LAN (which is provided by the ar750s), I route that browser’s traffic via a shorter path.
