Performance and optimization

Note: For information on overriding default configuration settings, refer to Modify configuration settings.

Although the Open Platform Communications (OPC) server is fully capable out-of-the-box, an OPC client can cause performance problems when attaching to a large number of items from the RealTime database (RTDB). Using entries in the OPC server’s configuration file can eliminate this issue.

The OPC server establishes a separate PubSub subscription for every item a client adds to their attach list. Once the number of items gets large (greater than 5000) the process responsible for tracking and publishing RealTime data begins to use too much memory and CPU in order to track all the subscriptions.

This problem can be eliminated by using some entries in the OPC server’s configuration file. If you know that your application is attaching to the same field in a large number of RealTime records, you can inform the OPC server when it first starts. The OPC server can then use star subscriptions to subscribe to an entire collection of data with a small number of subscriptions. This results in a largely reduced load on the RealTime server with no cost to the client.

As an example, let us assume that your client wishes to acquire data from the following:

primary.realtime.db.analog.*.curval --> curval field for all analog records

primary.realtime.db.analog.*.timestamp --> timestamp field for all analog records.

primary.realtime.db.analog.*.flag.fresh --> flag.fresh field for all analog records.

primary.realtime.db.status.*.cursta@raw --> numeric cursta value for all status records.

primary.realtime.db.status.*.flag.msgtxt --> string status value (open, close, etc.).

primary.realtime.db.analog.*.timestamp --> timestamp field for all analog records.

primary.realtime.db.analog.*.flag.fresh --> flag.fresh field for all analog records.

To reduce the load on the RealTime server

1. In the %DNADataRoot%\RealTime\config\Settings directory, either create or open the OPCDAServerConfig.json file.

2. Add the following lines to the file:

   "realtime.db.analog.|*|.curval",

   "realtime.db.analog.|*|.timestamp",

   "realtime.db.analog.|*|.flag.fresh",

   "realtime.db.status.|*|.flag.msgtxt",

   "realtime.db.status.|*|.flag.fresh",

   The file should look as follows:

   "RealTime":{

   "OPCDAServer":{

   "SUBSCRIPTIONS":["realtime.db.analog.|*|.curval",

   "realtime.db.analog.|*|.timestamp",

   "realtime.db.analog.|*|.curval",

   "realtime.db.analog.|*|.timestamp",

   "realtime.db.analog.|*|.flag.fresh",

   "realtime.db.status.|*|.flag.msgtxt",

   "realtime.db.status.|*|.flag.fresh"]

   }

   }

3. Save the file.

4. Restart the RealTime service.

The OPC server establishes optimized subscriptions to this data when it starts, and the data is pre-loaded into the server’s cache when the client connects to the server.

You can also optimize the performance of the OPC server by careful selection of the RTDB fields to which the client attaches. For example, realtime.db.status.fred.cursta is returned to the client as a string value, such as, open, close, on, off. This requires a substantial amount of effort by PubSub to read the raw enumeration value and then look up the translated string. A faster alternative is to attach to the cursta@raw field if you want the raw numeric value, and if you desire the current value as a string, attach to status.flag.msgtxt.

Always use the @raw variations of any field where possible, such as flag.fresh@raw instead of flag.fresh. It is always faster to obtain the boolean value (1 or 0) for the flag.fresh field as opposed to obtaining the string yes or no.