AVEVA Intouch using single thread or multi thread ?

I would be very happy to work with your team to fix some of these things which can significantly improve the performance of intouch unlimited, most customers like the Intouch unlimited ( perpetual and subscriptions ) but have performance issues while scaling

We verify InTouch for hundreds of thousands of tags using tag server architecture so from my perspective it scales pretty well. InTouch will, however, not compare to a multi-million tag System Platform architecture.

Here are some tips for large and/or performat InTouch applications:

• Use bulk load to generate tags.
• Be careful not to load too much data on screens at the same time. Instead, use  Situational Awareness design principles, e.g. drill-down through L1-L4 screens.
• Use Historian instead of LGH files, which have an upper limit around 2GB which can fill fast with large tag counts.
• Be careful not to query history and other data stores for too much data at a time. When using Historian, leverage summary retrieval or other clever Historian features when accessing historical data.

FYI, we are working on a deployment guide for InTouch, much like the one for System Platform, which we expect to be helpful in chosing the right architecture as well as implementing it.

We are using Intouch unlimited between 10k to 100k tag region , may have customers using the 150k tag max. I think having deployment guide will really help in best practices/ gold standards that can bring out the max capabilities of Intouch

Hi rickard.norin  , for the tag server architecture, while using tag server , historical logging and alarming will be disabled. So then should we use the second session of Intouchview App for remote referencing for historical logging and alarming ?

Hi rickard.norin  I do have a solution to the above Intouch single core problem in a RDS environment, wanted to see if AVEVA is open to hearing it and providing it as a license !!