Perspective: CPU usage goes high when multiple sessions are running

Is testing a new program in the last 2 weeks. saw the cpu usage went high when multiple sessions were opened. it is like every 1 session uses 1.2% CPU. when the number of sessions is 20, the CPU is running at 25% with some spikes but never comes down. when the sessions are closed, the CPU drops accordingly.
is it normal like this? this program is supposed to run over 100 sessions…(the Ignition is running on a server from AWS)

that really depends on the project.
If you notice it going slower you will have to improve your project i guess, reduce pollrates, reduce timerscripts ect ect

Try to avoid any polling in bindings in Perspective itself. Rely on the fact that bindings will refresh when a referenced tag or other property changes. Anything that needs to refresh on a schedule should happen in the gateway, not in Perspective. That way it only has to be calculated once for all clients.

With some exceptions, like real-time charts. However, when using now() or other changing datetime sources to feed an historical query binding or named query, preprocess the timestamp to eliminate milliseconds (or round to nearest two or five or ten seconds). This allows the gateway’s query cache to feed the same data to multiple clients.

Hey Phil,

My group has been having the same issues with CPU usage and latency on the loading of multiple perspective screens. We are pretty sure it has to do with the binding in our value indicator templates as well.

Do you have any examples of what polling may look like in bindings?

Currently we have a value indicator template with an OPC tag path as a parameter. We then use the tag_path to obtain the value itself, quality/quality code, alarm information and a few other things from the UDT the tag path points to with references like “value.alarm”. Based on my quick/short research on polling this seems as if it would cause polling but we are unsure of how to avoid this? We use the same format for templates/UDTs in Vision and it works well but as I stated previously we have CPU usage and latency issues with Perspective during loading/rendering of screens.

Any help would be very much appreciated.

Thank you for your time,

-Alec

Tag bindings and property bindings don’t poll. They subscribe and then sit idle until there’s a value change. You don’t have to worry about those.

Expression bindings that use now() or runScript() are polling unless the interval is explicitly set to zero. Query bindings are polling by default–select no polling for those.

When a binding doesn’t reference anything that will make it refresh, you can selectively use component.refreshBinding() to make it happen.

2 Likes

thank you , Phil.
i checked all the bindings and expression, i don’t have any now() or runscript() in the program.
my program has one thread starting with the page, most of the data is queried in this thread. the page set the related flag to 1 for what data it needs, the thread reads the flags, queries the data and writes back to the view. also if user doesn’t click any button on the page, it refreshes current page’s data every 2-5 minutes.
also, when navigate from a view to another view , i can see the cpu spike by 5 to 10%. it is like 1 second but i do see it. i think this can explain the spike in the CPU usage…

as my test, the current program can only run 50-60 sessions on one server. Or the user will feel slow when cpu gets 100%.

That sounds about right for a modest server setup. You might need beefier hardware.

This is relative, this depends on the load you’re putting on the backend.
I’ve seen some containers, for example, have better performance than others. And else people is saying. check your binding and scripting and make sure they are as clean as possible.

A detail that you can not control is the fact this runs on an AWS Server. Personally I haven’t seen either test its performance.