Performance, Processes, Threads.

[jsobon]

Dear ETM team,
I would like to ask you several questions, to better understanding WinCC OA.
We have a pretty big and complex application, and need to improve performance.
Our App:
- Running on WinCC OA 3.14,
- 20 Control Managers,
- 15 other (API, drivers,..)

1.) As I know, WinCC OA is written as single thread application, it means all managers are runnig on same thread as Event/Data manager? Each manager is in Windows OS running as separate process it means created own thread? Or program flow and everything inside of managers are controlled by pmon (process monitor manager)? How it is working please?

2.) Is there any reccomendation how many active dpConnects could be created in system?

Any information about those topics will be appreciate.

Thank you

[leoknipp]

Jaroslav Sobon wrote:

We have a pretty big and complex application, and need to improve performance.

First of all you can check which processes are using CPU time / memory during runtime of the project, e.g using top on Linux or the Performance Monitor (perfmon.exe) on Windows.
If you have identified which processes use most of the system resources you can do further investigation on this processes.

1.) As I know, WinCC OA is written as single thread application, it means all managers are runnig on same thread as Event/Data manager? Each manager is in Windows OS running as separate process it means created own thread? Or program flow and everything inside of managers are controlled by pmon (process monitor manager)? How it is working please?

WinCC OA is not a multi threaded application. Even if it is not multi threaded every process has it's own threads.
E.g. the threads running in a CTRL manager have not connection to threads running in the Event Manager.
Every WinCC OA manager is controlling/executing the threads on his own.

The process monitor is only monitoring the state of the processes (running, stopped, ...) by alive information stored in a shared memory without having any interaction to the threads running in the WinCC OA processes. The WinCC OA processes only write information (alive counter) to the shared memory of the process monitor.

2.) Is there any reccomendation how many active dpConnects could be created in system?

No, there is no "magic" number defined how many dpConnects can be used in a system.
A dpConnect itself does not cause performance problems, only executing the work function will probably cause performance issues.
As long as no value is changed (where a dpConnect is connected to) the dpConnect has nothing to do.

Best Regards
Leopold Knipp
Senior Support Specialist

[fmulder]

Just to add to your dpConnects(). Let me add some of my experience.

- One dpConnect with 10 elements if faster than 2 dpConnects() with each just one element. Therefor, all our icons just have one dpConnect (that varies in number of elements)
- Absolutely be carefull with dpGet(). do not put any dpGet()'s in our callback. ( Instead, add the element that you need to the dpConnect)

Always keep in mind that your system is event driven. This means : when there's no change, then there should be no script code running.

Just try the following:
- disconnect your plc
- start your GUI (or script manager0 with '-dbg 29'
- Look at the script code that you see in the LogViewer. When you see a lot of script code----> then probably your design is bad

Good luck

share the fun
Frenk Mulder

[AngusETM]

Hi all,

Thanks for your response above, that's very informative. I have some more specific questions on this same topic so thought best to add them here.

From the responses I understand the following, is this correct?
- Each manager runs its own thread(s) on the processor.
- Each manager can multithread.
- Consequently, if fast performance is required a DPQueryConnect could be multithreaded inside the same manager.

Some more detailed questions:
- For a given number of events, can using multiple DPQueryConnect functions decrease the processing time even if both functions are not multithreaded?
- For example, a DPQueryConnect returns 10,000 points and 1000 of those points change at the same time. Would the processing occur more quickly if this was split into 10 DPQueryConnects returning 1000 points each, processing 100 each, even if all the DPQueryConnects were not multihreaded?
- I think the answer is "no", because all ten calls would still be single-threaded. In fact, it might be slower. Is this correct? Or, is there some efficiency to splitting up the functions even if multithreading is not used?
- Is there a number of events which can occur "at the same time" for a single DPQueryConnect which could cause a problem? Or if the number gets large, will the events just keep stacking and be run through sequentially, however long it takes?

Kind regards,
Angus Heyworth

[leoknipp]

Angus Heyworth wrote:

Thanks for your response above, that's very informative. I have some more specific questions on this same topic so thought best to add them here.

From the responses I understand the following, is this correct?
- Each manager runs its own thread(s) on the processor.
- Each manager can multithread.
- Consequently, if fast performance is required a DPQueryConnect could be multithreaded inside the same manager.

In a WinCC OA processes several threads can be used but only one thread is processed at a specific time.
If there are several threads running, e.g. in a CTRL manager the process is doing some statements in one thread and switches then to another thread, processing again some statements before switching to the next thread.

Some more detailed questions:
- For a given number of events, can using multiple DPQueryConnect functions decrease the processing time even if both functions are not multithreaded?
- For example, a DPQueryConnect returns 10,000 points and 1000 of those points change at the same time. Would the processing occur more quickly if this was split into 10 DPQueryConnects returning 1000 points each, processing 100 each, even if all the DPQueryConnects were not multihreaded?
- I think the answer is "no", because all ten calls would still be single-threaded. In fact, it might be slower. Is this correct? Or, is there some efficiency to splitting up the functions even if multithreading is not used?
- Is there a number of events which can occur "at the same time" for a single DPQueryConnect which could cause a problem? Or if the number gets large, will the events just keep stacking and be run through sequentially, however long it takes?

If a connect (e.g. dpConnect, dpQueryConnectSingle) is used the execution of one work function is finished before the next one is started.
The queue of work functions is handled for every connect on it's own. If there are several connects in one script every connect has it's own queue of work function even if the same work function is used.

If a dpQueryConnectSingle is made for a given number of datapoint elements and some of them are changed with the same time (same message) the work function is called only once with the array of dp elements which have changed.
In that case the work function is not started for every single dp element passing only one element to the result table in the work function.

Best Regards
Leopold Knipp
Senior Support Specialist

[mkoller]

From the responses I understand the following, is this correct?
- Each manager runs its own thread(s) on the processor.
- Each manager can multithread.
- Consequently, if fast performance is required a DPQueryConnect could be multithreaded inside the same manager.

One important note here:
Do not confuse CTRL threads with OS threads.

A UI/CTRL can run multiple CTRL script threads, but a CTRL script thread is NOT an OS thread, meaning: they do not leverage multiple CPUs/cores.
Instead, as Leopold described, CTRL script threads are executed in a single OS thread and the CTRL interpreter core just executes a script thread
for some time and then goes to execute the next script thread.

[jsobon]

Thank you very much for all. Now is this topic much cleared for me.

One more question, I am sorry if I missed in in documentation, but I did not find it. Can you tell me how it works in WinCC OA, what is in other programming language called Garbage collector? How memory management is working in WinCC OA?

thank you

[mkoller]

It is using the normal C/C++ memory management. No special garbage collection needed.