Disallow web server to use 100% cpu

[caseydiers]

During todays mesh-oween, I discovered an issue on my lower memory (32MB) devices. When there where 1000 nodes all connected, and the device was taxed heavily, they could cope just fine passing traffic at idle. However, when the webpage was in use it was just too much. Loading the main page spiked CPU to 100% and loading the mesh status page would timeout several minutes into trying. It would occasionally drop its connection to the network altogether.

I wonder if the web server software could be limited in the percentage of system resources it can use so that when the device is heavily taxed (as it would be in an emergency) simply loading a webpage doesn't cause the rf link to fail due to the node becoming non-responsive. Or alternately have the web server system process priority set considerably lower than the other more critical priorities. I would prefer to have it pass traffic more reliably than load the webpage. Obviously the solution to all of this is to get a more powerful device, however in this (probably common in these tests) edge case, I believe the software could fail more gracefully. Especially given that when the connection is dropped, the webpage doesn't load either, so there is no benefit to prioritizing the page load.

Or even a radio box (I don't know how to do a radio box in markdown...:)

• Prioritize Mesh Traffic
• Prioritize Web Server

[dman776]

Which page where you trying to load? Thanks, Darryl

…

On Oct 30, 2021, at 9:13 PM, Casey Diers ***@***.***> wrote:  During todays mesh-oween, I discovered an issue on my lower memory (32MB) devices. When there where 1000 nodes all connected, and the device was taxed heavily, they could cope just fine passing traffic at idle. However, when the webpage was in use it was just too much. Loading the main page spiked CPU to 100% and loading the mesh status page would timeout several minutes into trying. It would occasionally drop its connection to the network altogether. I wonder if the web server software could be limited in the percentage of system resources it can use so that when the device is heavily taxed (as it would be in an emergency) simply loading a webpage doesn't cause the rf link to fail due to the node becoming non-responsive. Or alternately have the web server system process priority set considerably lower than the other more critical priorities. I would prefer to have it pass traffic more reliably than load the webpage. Obviously the solution to all of this is to get a more powerful device, however in this (probably common in these tests) edge case, I believe the software could fail more gracefully. Especially given that when the connection is dropped, the webpage doesn't load either, so there is no benefit to prioritizing the page load. Or even a radio box (I don't know how to do a radio box in markdown...:) Prioritize Mesh Traffic Prioritize Web Server — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[caseydiers]

The issue where the webserver uses a lot of cpu is observed in these conditions when loading any of the pages, however most pages load relatively quickly still so it isn't a problem. However, the mesh status page can take upwards of a minute, so it by far is the largest issue.

What I'm proposing is the 'big hammer' approach of just globally reducing the priority of the web server. However, I suppose it would also be possible to alleviate the stress by providing an option to not fully load the mesh status page, or somehow reduce the amount of detail, or something, when the memory on the device is full.