Bewährte Verfahren für leistungsstarke Apps

Dieser Leitfaden beschreibt Best Practices für die Entwicklung leistungsstarker Tulip-Anwendungen, die sich in Produktionsumgebungen effizient skalieren lassen. Die Befolgung dieser Empfehlungen trägt dazu bei, dass Ihre Apps auch bei wachsendem Betriebsumfang reaktionsschnell und stabil bleiben.

Was ist ein Hochfrequenz-Trigger?

Ein Hochfrequenz-Trigger wird häufiger als alle 5 Sekunden ausgeführt (schneller als 0,2 Hz). Maschinenattribut-Ereignisse, Geräteereignisse und Timer-Trigger sind die häufigsten Ursachen für eine hochfrequente Ausführung.

Tulip empfiehlt, dass Trigger nicht schneller als alle 5 Sekunden (0,2 Hz) ausgeführt werden, um die Leistung und Reaktionsfähigkeit der App aufrechtzuerhalten.

Auswirkungen auf die Trigger-Warteschlange

App-Trigger werden von oben nach unten in einer sequenziellen, single-threaded Warteschlange ausgeführt, die als Trigger-Warteschlange bezeichnet wird.

Zwei Faktoren bestimmen, ob die Warteschlange effizient arbeitet:

1. Eintrittsrate in die Warteschlange: Wie häufig werden Trigger-Ereignisse zur Warteschlange hinzugefügt?
2. Warteschlangenausgangsrate: Wie schnell die Triggerlogik die Ausführung abschließt

Wenn Trigger schneller in die Warteschlange gelangen, als sie sie verlassen, staut sich die Warteschlange. Ein anhaltender Stau in der Trigger-Warteschlange führt zu App-Latenz und in einigen Fällen zum Verlust von Trigger-Ereignissen.

Stellen Sie sich die Triggerhäufigkeit wie den Verkehr auf einer Autobahn vor. Wenn zu viele Autos innerhalb kurzer Zeit auf die Autobahn fahren, verlangsamt sich der Verkehr. Um einen Stau zu vermeiden, müssen die Autos in einer Geschwindigkeit auf die Autobahn fahren, die diese bewältigen kann.

Kombinierte Häufigkeit

Die kombinierte Rate aller Trigger-Ereignisse in einer App bestimmt die gesamte Eintrittsrate in die Warteschlange. Jedes von Ihnen konfigurierte Trigger-Ereignis trägt zu dieser kombinierten Rate bei.

Beispiele für die kombinierte Frequenz finden Sie in der folgenden Tabelle:

Geschwindigkeitsskala der Triggerlogik

Die Art der Triggerlogik bestimmt, wie schnell Trigger die Warteschlange verlassen. Logik, die Cloud-Kommunikation, Übergänge oder Antworten von externen Systemen erfordert, benötigt deutlich länger zur Ausführung als lokale Vorgänge.

Die folgende Tabelle beschreibt die Geschwindigkeit verschiedener Logiktypen.

Technische Faktoren, die die Trigger-Leistung beeinflussen

• Lokale Hardware – Die Trigger-Logik wird auf lokaler Hardware ausgeführt, daher haben die Gerätespezifikationen entscheidenden Einfluss darauf, wie schnell Trigger ausgeführt werden und die Warteschlange verlassen. Informationen zu den Gerätespezifikationen finden Sie unter „Empfohlene Geräte für Tulip Player“.
• Externe Abhängigkeiten – Zu den externen Abhängigkeiten zählen die Verbindung zur Cloud, die Latenz im lokalen Netzwerk sowie die Reaktionszeit externer Systeme wie Enterprise-Resource-Planning-Systeme (ERP).
• Über Tulip-Edge-Geräte verbundene Geräte – Tulip-Apps sind auf eine Cloud-Verbindung angewiesen, was zu Latenzzeiten führen kann. Beispielsweise kommuniziert ein an ein Edge-Gerät angeschlossener Drehmomentregler weiterhin über Tulip-Cloud-Dienste mit dem Tulip Player. Um die Geräteverbindungen besser zu verstehen, sehen Sie sich diese Sequenzdiagramme für Geräteverbindungen über Tulip-Treiber an.
• Latenzprobleme bei Connector-Funktionen – Eine langsame Antwort eines Systems (z. B. eines ERP-Systems) über eine Connector-Funktion kann zu Verzögerungen in der App führen, insbesondere wenn die App viele Datensätze durchläuft, von denen jeder einen potenziell zwei Sekunden dauernden API-Aufruf erfordert. Um die Systemverbindungen zu verstehen, sehen Sie sich diese Sequenzdiagramme zur Anbindung an Unternehmenssysteme an.
• Latenz zwischen Fertigungsbereich und Tulip-Cloud-Infrastruktur – Um die Latenz zu minimieren, befindet sich Ihre Tulip-Instanz in derselben geografischen Region wie Ihr Fertigungsbereich.

Hinweise

Vermeiden Sie hochfrequente Trigger

Sie sollten hochfrequente Trigger nach Möglichkeit vermeiden und stattdessen andere Funktionen nutzen, wie z. B. „ Automations“.

Möglicherweise möchten Sie auch Ihre Anwendungsarchitektur so umgestalten, dass sie mit einer geringeren Frequenz arbeitet. Zum Beispiel:* Weniger häufige Datenauswertung durch Abfragen und Aggregationen* Bei asynchronen Anwendungsfällen können Schleifen über „Automations“ ausgeführt werden* Bei synchronen Anwendungsfällen sollten Schleifen, die sequenziell ausgeführt werden müssen, über „Functions“ erfolgen

Wenn Sie einen hochfrequenten Trigger verwenden müssen, sollten Sie diesen so konfigurieren, dass er nur lokale Aufgaben ausführt (z. B. die Aktualisierung einer App-Variablen). Verwenden Sie anschließend einen niederfrequenten Trigger für die langsameren Ausführungen (z. B. die Aktualisierung eines Tabelleneintrags).

Wenn Sie einen hochfrequenten Timer-Trigger verwenden, um schnell auf Kontexte außerhalb einer Tulip-App zu reagieren, können Sie möglicherweise eine „Event Stream“-Tulip-Machine mit Maschinen- und Gerätetriggern nutzen.

Verwendung von Tulip-Tabellen-APIs

Die Verwendung von Tabellen-APIs zum mehrmaligen Lesen oder Schreiben pro Sekunde kann die Leistung Ihrer Instanz beeinträchtigen und zu Verzögerungen beim Lesen oder Speichern von Daten führen. Die folgenden Empfehlungen gelten für alle Skripte und Trigger-Aktionen, die Tulip-APIs auf einer Tulip-Instanz ausführen:

Empfehlung

• Planen Sie die Ausführung Ihrer Logik so, dass die Tabellen-Ratenbeschränkungen von Tulip eingehalten werden
• Vermeiden Sie häufige Schreibvorgänge in denselben Datensatz einer Tabelle (mehr als 1 pro Sekunde)

Wenn Schwellenwerte überschritten werden, kann Tulip eine Ratenbegrenzung vornehmen und den Fehlercode 429 zurückgeben. Skripte sollten so ausgelegt sein, dass sie auf Fehlercodes 429 reagieren und den Vorgang nach einer Verzögerung erneut versuchen.

Maschinen-, Geräte- und Timer-Trigger

Timer-Trigger mit kurzen Intervallen (alle 1–2 Sekunden) können Ihre Anwendungen überlasten, insbesondere wenn diese Timer-Trigger mehrere API-Aufrufe beinhalten (z. B. Tabellenschreibvorgänge oder die Ausführung von Connector-Funktionen).

Maschinenauslöser überwachen Attributänderungen von angeschlossenen Geräten und führen als Reaktion darauf Logik aus. Wenn „ machine attributes “ mit hoher Frequenz Daten melden oder wenn mehrere Attribute gleichzeitig überwacht werden, kann die Ausführungsrate der Auslöser die Verarbeitungsrate der App übersteigen. Dies kann zu Leistungseinbußen führen.

Empfehlung

• Beschränken Sie die Abonnements für „ machine attribute “ auf diejenigen, die für den aktuellen Schritt oder Workflow erforderlich sind
• Trennen Sie hochfrequente Logik von Cloud-Vorgängen und verwenden Sie einen Trigger mit niedrigerer Frequenz, um cloudabhängige Aktionen zu verarbeiten

Beispielszenario: Ein „ machine attribute “ wird viermal pro Sekunde aktualisiert, und Sie müssen die Anzahl der Aktualisierungen in einem Tabelleneintrag erfassen. Trigger 1 (Maschinenereignis): Aktualisieren Sie eine App-Variable mit eingehenden Maschinendaten. Trigger 2 (Timer, alle 10 Sekunden): Schreiben Sie die gesammelten Daten in einen Tabelleneintrag.

• Erwägen Sie den Einsatz von Automatisierungen für die asynchrone Verarbeitung, um die Verarbeitungslast von der Trigger-Warteschlange zu nehmen. Beispielsweise, wenn Maschinendaten verarbeitet werden müssen, aber keine sofortige Rückmeldung an den Bediener in der App-Sitzung erforderlich ist
• Verwenden Sie in Triggern ausschließlich schnelle Operationen, wie z. B. „App-Variablen lesen/aktualisieren“ oder „Tabelleneinträge lesen“
• Überprüfen Sie Ihre App-Architektur und erwägen Sie eine Neugestaltung, um mit einer niedrigeren Rate zu arbeiten, falls Ihr Anwendungsfall die Überwachung vieler Attribute mit hohen Frequenzen erfordert. Alternative Ansätze sind:
• Aggregieren Sie Daten auf Maschinen- oder Edge-Geräteebene, bevor Sie sie an Tulip senden
• Verwenden Sie Automationen für die Datenerfassung und -verarbeitung
• Reduzieren Sie die Berichtsfrequenz an der Datenquelle
• Erwägen Sie die Verwendung von Tulip-Player-Treibern anstelle von auf Edge-Geräten gehosteten Treibern
• Torque-Tool-Player-Treiber

{{snippet.Haben Sie gefunden, wonach Sie gesucht haben?}}