Performance

Client-Server Communication

Innovator clients send queries to the server; the server then processes the queries and sends a reply back to the client. Innovator is a multi-user system; this means that various clients can be accessing the same server at the same time. Queries made by these clients are then sequentially dealt with by the server. If the server carries out a time-consuming action to deal with one of these queries then the other clients with queries have to wait for this one to be completed before their query can be dealt with. If server access is inefficient, this can slow everything down.

Plug-ins send queries like this using the server API. This is done by calling methods for model elements or querying their properties. The API then generates a "telegram" which contains the necessary data which will be sent to the server. The sending of a telegram to the server via the network requires time, which means that opportunities for summarizing similar queries for large element sets in a single telegram should be exploited.

Server Access in CanExeCmd Methods

If possible, avoid sending large numbers of telegrams. This may be a problem when testing executability of commands in CanExeCmd methods. These tests are accessed a lot which means that it does not make sense to access the server for these methods. It is a better idea to enable the commands and then check the condition which server access requires once the command is executed. Output an error message if the condition is not fulfilled and then abort the command execution.

InfoBulk and ViewBulk

It is often necessary to determine various properties of elements from one set (e.g. name, icon, namespace). The worst way to do this is to use a loop of all elements in the set which then queries the appropriate properties for each element respectively. The amount of server telegrams produced is based on the number of elements and properties.

It is much quicker to determine all information using just one telegram and the ServerUtilities.GetElementInfos (Util.dll) method. The name and access of the elements are determined in the following example.

The method only provides values from the string, bool, long or Point types. If the result is an element, the GetElementViews method should be used in the same way.

Tracer for Server Access

You can log telegrams so that you can check server accesses in your plug-in.

• Define a LogDir environment variable in the Environment backstage view in the Administration Program. The value must be the path of a directory that the Innovator model editor uses as the root for the storage of log files.

  For each started model editor, a separate directory is created for logs beneath this root.

  The content of the event viewer is logged in the Events.log file.

• A further Tracers environment variable defines additional logs that should be written to file. A value in the form ServerTelegram,8 is required for the server accesses. The number specifies the level of the call stack that describes the code position at which the server access takes place:

  14.04.2016 12:43:29.475
  77 - (101 ms, Total: 410 ms) RepositoryServer::SendAndReceive(SND:140 RCV:439 Bytes) Total(SND:12 RCV:802 KBytes)
  MID.Innovator.API.dll - icw2meta.cs::GetPropertyRegionInit():1863
  --> MID.Innovator.WorkAreaContent.Properties.dll - PropertiesToolWin.work.cs::oDisplayContent():83
  MID.Innovator.WorkAreaContent.Properties.dll - PropertiesToolWin.auto.cs::DisplayContent():55
  MID.Innovator.WorkAreaContent.Properties.dll - PropertiesToolWin.work.cs::MID.Innovator.ApplicationFramework.Public.IMessageHandable.MessageHandler():213
  MID.Innovator.ApplicationFramework.dll - WorkArea.work.cs::sSendMessage():415
  MID.Innovator.ApplicationFramework.dll - WorkArea.auto.cs::SendMessage():76
  MID.Innovator.ApplicationFramework.dll - InternalModelDockSite.work.cs::SelectData():579
  MID.Innovator.ApplicationFramework.dll - InternalModelDockSite.work.cs::StartSelectionTimer():542

  The first line contains the exact time of the access.

  The second line specifies the duration from the sending of the telegram to the server up to the time when a response is received. The second duration is the total of these times.

• Optionally, you can reduce the number of log entries using the TracerMinTime environment variable. The value is an integer. Only telegrams that have required at least this duration (in milliseconds) are then logged.