Realtime frontend dashboard, calling api every 3 seconds, reduce cpu loads

Question

I am working on a networking project. Where I am creating a dashboard to view real time status (CPU/memory usage, up/down traffic and few others) of multiple routers by calling API request to server which will call another API request to the routers ( Mikrotik Routers, they offer api to do configuration and get statuses ).

Problem: In testing each request surge my VPS CPU usage up to 20%. This is only one user viewing the dashboard and doing request. What if I have multiple customers and each one of them viewing the dashboard and doing multiple request to the servers. It is going to go down for sure, right?

Here is part of back end code:

$routers = //Get all the routers belong to that users

foreach($routers as $router){

            $api = connectRouter();
            if($api === false){
                continue;
            }

            $api->write('/ip/hotspot/user/getall');
            $users = $api->read();


            $api->write('/ip/hotspot/active/getall');
            $actives = $api->read();

            $resources = $api->comm('/system/resource/print');
            $resources = $resources[0];


            $api->write('/interface/getall');
            $router->interfaces = $api->read();

} 

Question: What option do I have to reduce the CPU usage and be able to provide this services to multiple customers?

Up to what I had researched:

1. I should try Node.js ?
   
2. Change ways I am calling from front end: instead of calling API to getting all routers data at once, change it to get one by one?

NOTE 1. Those values in routers change every second (if not millisecond). I want to get value in real time as much as possible. So caching is not a solution here I think.

2. Every users have their own set of routers. They don't share routers. So doing some duplicate router query check won't be a benefit I think. ( Yeah can be useful if the same logged in user trying to view on multiple devices or browser tabs. ) But I am trying to optimize for multiple users.

Answer 1

Would you not be wanting to cache the data on backend somewhere then allow the Ui to request this, rather than setting off a chain of calls every time.

You can then reduce the internal calls to one set per 3s or whatever the refresh rate is?

Having the calls chain through the system is good for testing, caching lets you scale up.

Answer 2

A good option would be a bi-directional communication. For that you will need a server which is able to hold a persistent connection, so PHP is a no-go (even though you can hack it with something like ReactPHP/Ratchet) and Node.js would be a much better option.

Your main issue currently is, should two users have access to same router, you would be querying the router two times, even though the output data is the same for both of them. And the numbers go higher once more and more users connect.

What you should so is:

• setup a Node.js server, which will be used for querying the routers,
• when a users connects, check their router list and add the routers to router SET (set cannot contain duplicates, each router would only be present once),
• establish a persistent bi-directional connection between the client and the Node.js server (using sockets),
• query all routers in the router pool to retrieve data,
• upon receiving response from the routers, check clients of the router you have just received data from feed/push the new data to the connected clients,
• when a client disconnects check the router pool for their routers and if they were the only client using some of the routers, remove them from the querying pool.

This way you prevent querying the same router multiple times.

Which strategy of feeding the data from the routers to their clients you choose, whether you:

1. query all routers and upon finishing the cycle send data of all routers to clients,
2. or feed data to the clients upon receiving data from each router,

you must device for yourself, what works the best for you. I personally would go with the second option.