Make the ASUS Router GUI faster ...

[eclp]

The different opinions are interesting to read, thank you for that.

But, let's not forget, this is not about a speed comparison of Asus, Netgear & Co. And when I look at the various threads with countless topics here I wonder why this topic is treated so stepmotherly.

If you can achieve a significantly higher performance with the simplest means, why not? Those who are satisfied now would also be after. At that time I was also very happy with my first car with 45hp.

Of course, it is clear that RMerlin would have to implement these things, it is also clear how much work he already has. But you can support. Everyone as they can and like.

 

[Zirescu]

Would be better to send the suggestions to Asus directly as they maintain the original source code and RMerlin would have to modify it every time they put out new code.

 

[RMerlin]

OP made a few good points in the original post. If I were ASUS, I would listen and check how I could improve myself.

Don't be so negative to ideas and suggestions...

You're assuming that I have never looked into any of these suggestions before - I actually did. It's not about being negative, it's about being realistic as some of those suggestions are already implemented. Pagespeed makes assumptions based on the fact that the whole test suite is designed for a public fronted web server, based on a real web server platform rather than a custom-designed httpd daemon running on a low-powered CPU and accessed within a LAN. RTT is an important issue over the Internet, but not so much over the LAN.

Caching: as indicated that has already been done to its limit (I even went too far, as witnessed by people having a broken webui after moving from 380 to 384 due to those cached CSS files). I'm already more aggressive in caching than the stock firmware, as I currently cache images, CSS, and a few select large static JS files. The rest cannot be cached, because they are dynamic pages that contain embedded EJS tags (those <% %> that get pre-processed by the web server before the page gets sent to the browser). List of commits targeting caching improvements:

https://github.com/RMerl/asuswrt-me...6ddabfd#diff-ea073088743aeb470ced991dadab8003
https://github.com/RMerl/asuswrt-me...0e37f80#diff-ea073088743aeb470ced991dadab8003
https://github.com/RMerl/asuswrt-me...aa3692d#diff-ea073088743aeb470ced991dadab8003
https://github.com/RMerl/asuswrt-me...c817e3f#diff-ea073088743aeb470ced991dadab8003
https://github.com/RMerl/asuswrt-me...9353067#diff-ea073088743aeb470ced991dadab8003

Compression: the web server does not support compression (this isn't Apache/Nginx where you can simply enable a setting to get compression, it's a custom-designed web server). And the CPU on the router isn't powerful enough, it will slow things down. Just see how much slower the webui gets when using https - compression will make things even slower, because compression time > transport time of the uncompressed data.


The only way to further improve performance right now in any significant way is for someone to rewrite the socket code in httpd to make it multi-threaded, and support more than one concurrent connections. I even spent a few nights on a proof-of-concept experiment where I ended up having HTTPS performance run just as fast as non-HTTP access on an RT-AC86U... except that you could no longer change any setting, and user authentication no longer worked (I had to completely disable it to execute those tests). But it showed the potential performance gain possible by having multithreaded support. Working around those issues would require redesigning most of the httpd code. Not a 1-2 days task, more like a multi-weeks task, with no guarantees that it would eventually be fully working. Basically, a lot of the web server's internal architecture would have to be redesigned. It's a major project - time would be better spent on more critical issues.

 

[kvic]

@RMerlin

Frankly I don't expect you to take up the ownership. More for ASUS to improve. However, if you really want to try, shall tackle KEEP_ALIVE. Simple change and instant speed-up.

 

[PDinDetroit]

I moved to the RT-AC86U and plenty fast. Always room for improvement and suggestions can spark something or someone into motion at times...

 

[RMerlin]

@RMerlin

Frankly I don't expect you to take up the ownership. More for ASUS to improve. However, if you really want to try, shall tackle KEEP_ALIVE. Simple change and instant speed-up.

That's one area I haven't investigated, definitely worth having a look. Thanks.

My experiments were done by running haproxy on the router, sitting between httpd and the clients. Initially I only wanted to see if it would resolve the https stalls experienced at the time (it did). The major performance boost was an unexpected surprise. But the other issues it caused forced me to shelve the project. I kept my local git branch with the changes in case I ever go back to it in the future.

Asus are quite behind regarding httpd performance, I don't think they have implemented any of those cache improvements I implemented. Maybe because they want to avoid the issues experienced when they make any major CSS changes, like what happened when moving from 380 to 382/384. I'm glad they at least picked all my mssl changes, so Asuswrt's httpd could get a Qualys score of A at the time I implemented them. Better than many public websites!

Another improvement I did a year or two ago was to reprocess all the images to further compress them. It resulted in notable size reductions with no image quality loss. I don't remember however if those recompressed images were reused when I moved to 382, or if they were replaced with the GPL images.

 

[kvic]

My experiments were done by running haproxy on the router, sitting between httpd and the clients.

This is not a bad idea either only at the expense of an extra process. You could use Haproxy as SSL termination, and redirect as HTTP to Asus' httpd. Practically not use Asus httpd for HTTPS. Speed up shall be instant with proper config in Haproxy. No code to write.

 

[RMerlin]

This is not a bad idea either only at the expense of an extra process. You could use Haproxy as SSL termination, and redirect as HTTP to Asus' httpd. Practically not use Asus httpd for HTTPS. Speed up shall be instant with proper config in Haproxy. No code to write.

That was the idea at the time, especially for the SSL part. But it caused numerous issues around client authentication.