Performance

Client-Server-Kommunikation

Innovator-Clients senden Anfragen an den Server, der diese bearbeitet und Antworten zurück an den Client schickt. Da Innovator ein Mehrbenutzersystem ist, greifen unter Umständen viele Clients auf denselben Server zu. Deren Anfragen werden vom Server sequentiell bedient. Führt der Server eine zeitaufwendige Aktion zur Bearbeitung solch einer Anfrage aus, dann müssen andere anfragende Clients auf deren Fertigstellung warten, bevor sie selbst bedient werden. Ineffiziente Server-Zugriffe bremsen also alle aus.

Plug-ins senden solche Anfragen mittels der Server-API, indem sie Methoden auf Modellelementen ausführen oder deren Eigenschaften abfragen. Die API generiert dann ein "Telegramm" mit den notwendigen Daten, das an den Server geschickt wird. Das Senden eines Telegramms an den Server über das Netzwerk benötigt Zeit, weshalb die Möglichkeiten ausgeschöpft werden sollten, gleichartige Abfragen für größere Elementmengen in einem Telegramm zusammenzufassen.

Serverzugriffe in CanExeCmd-Methoden

Vermeiden Sie nach Möglichkeit eine große Zahl an Telegrammen. Problematisch ist der Test auf Ausführbarkeit von Befehlen in den CanExeCmd-Methoden. Da diese Tests sehr häufig aufgerufen werden, ist es nicht sinnvoll, in diesen Methoden auf den Server zuzugreifen. Besser ist, die Befehle zu erlauben und erst bei der Befehlsausführung die Bedingung zu überprüfen, die den Serverzugriff erfordert. Geben Sie dann eine Fehlermeldung aus, wenn die Bedingung nicht erfüllt ist, und brechen Sie die Befehlsausführung ab.

InfoBulk und ViewBulk

In der Praxis ergibt sich häufig die Aufgabe, diverse Eigenschaften von Elementen einer Menge (wie z.B. Name, Symbol, Namensraum) zu bestimmen. Die schlechteste Lösung ist eine Schleife über alle Elemente der Menge, in der dann jeweils für jedes Element die entsprechenden Eigenschaften abgefragt werden. Die Anzahl der Servertelegramme ergibt sich dann als Produkt der Anzahl der Elemente und der Anzahl der Eigenschaften.

Wesentlich schneller ist es, alle Informationen mit einem einzigen Telegramm über die Methode ServerUtilities.GetElementInfos (Util.dll) zu bestimmen. Im folgenden Beispiel werden Name und Zugriff der Elemente ermittelt.

Die Methode liefert nur Werte, die vom Typ string, bool, long oder Point sind. Ist das Ergebnis ein Element, dann ist die Methode GetElementViews analog zu verwenden.

Tracer für Serverzugriffe

Sie können Telegramme protokollieren lassen, um die Serverzugriffe in Ihrem Plug-in zu überprüfen.

• Definieren Sie im Administrationsprogramm in der Backstage-Ansicht Umgebung eine Umgebungsvariable LogDir. Der Wert muss der Pfad eines Verzeichnisses sein, das dem Innovator-Modelleditor als Wurzel für die Ablage von Protokolldateien dient.

  Für jeden gestarteten Modelleditor wird ein eigenes Verzeichnis unterhalb dieser Wurzel für dessen Protokolle angelegt.

  Der Inhalt der Ereignisanzeige wird in der Datei Events.log protokolliert.

• Eine weitere Umgebungsvariable Tracers legt zusätzliche Protokolle fest, die auf Datei geschrieben werden sollen. Für die Serverzugriffe ist ein Wert der Form ServerTelegram,8 erforderlich. Die Zahl gibt die Höhe des Aufrufstapels wieder, der die Code-Position beschreibt, an der der Serverzugriff erfolgt:

  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

  Die erste Zeile enthält den genauen Zeitpunkt des Zugriffs.

  In der zweiten Zeile wird die Dauer vom Abschicken des Telegramms an den Server bis zum Eintreffen der Antwort angegeben. Die zweite Dauer ist die Summe dieser Zeiten.

• Optional können Sie die Anzahl der Protokolleinträge mittels der Umgebungsvariablen TracerMinTime reduzieren. Der Wert ist eine ganze Zahl. Es werden nur solche Telegramme protokolliert, die mindestens diese Zeit (in Millisekunden) benötigt haben.