Cache Tuning

Tune the cache large enough so that unnecessary reads are not generated, and small enough that old data is not returned while keeping the communication channel busy. If the cache is too large, the communication channel might become idle for a while and so waste its bandwidth. Also if the cache is too large, a Citect SCADA client might start to short cycle on reads request, which will generate unnecessary network or internal traffic load.

Read short cycling occurs when a client requests data from the I/O Server, and the data is returned from the cache, so it is returned quickly. The client will process the data (display it on screen) then ask for the same data again. If the I/O Server again returns the same data from the cache, the client will process the same data again which is redundant and a waste of CPU and the network (to transmit the request and response). When short cycling starts to occur, the CPU and network loading will rise while the PLC communication traffic will start to fall.

To tune the cache you need to balance the cache time between unnecessary reads and short cycling. The method described below assumes you know how to use the Citect SCADA debugging Kernel.

1. Turn off unit caching, use the CACHE command in the Kernel so you don't have to re-compile your project.
2. Run one Citect SCADA client only on the network, use the Client in the I/O Server for the test.
3. Display a typical page to generate normal PLC loading for your system.
4. In the Kernel use the STATS command to reset the Citect SCADA statistics.
5. In the Kernel display the page 'PAGE TABLE STATS'. This page shows the cycle and execution time of various Citect SCADA tasks, some of which consume PLC data. The tasks called 'Citect n' where n is a number are the tasks which get data from the PLC and display on screen. Look at the Avg Cycle time, this is the third column from the left. Assume that the Avg cycle time is 1200 ms. T his will mean that the current page is gathering PLC data and displaying its data on the screen in 1200 ms.
6. Always set the cache time below this average cycle time to minimize short cycling. On average set it to less than half this time, that is 600 ms.
7. Set the cache time to half the cycle time (600 ms). You might not see any improvement in performance with a single client, as caching will only improve performance with multiple clients. You might see improvements if you are also running trends, alarms or reports which are requesting the same data.
8. Add another Citect SCADA client that is displaying the same data. Reset the STATS and check the Average cycle time. Each new client will not increase the cycle time, it will drop slightly. Also look at PAGE GENERAL, to see that each new client services its reads from the cache; i.e., the % cache reads increases.
9. If the average cycle time drops to less than half the original time then short cycling is occurring and you need to decrease the cache time until this stops.
   Tuning the cache is a trial and error process - as you change it, the read cycle time will also change. The cache time will also depend on what the current PLC traffic is. The current traffic is dynamic as Citect SCADA will only read what is needed depending on the current page, trend, alarm and reports running. Monitor the average cycle time under lower loading conditions and set the cache as low as necessary to stop or help prevent short cycling.

Published June 2018