Best practice per app ad alte prestazioni

Questa guida illustra le migliori pratiche per la progettazione di applicazioni Tulip ad alte prestazioni in grado di scalare in modo efficiente negli ambienti di produzione. Seguire queste raccomandazioni contribuirà a garantire che le vostre app rimangano reattive e stabili, anche man mano che la vostra attività cresce.

Che cos’è un trigger ad alta frequenza?

Un trigger ad alta frequenza si esegue più spesso di una volta ogni 5 secondi (a una frequenza superiore a 0,2 Hz). Gli eventi relativi agli attributi delle macchine, gli eventi dei dispositivi e i trigger del timer sono le fonti più comuni di esecuzione ad alta frequenza.

Tulip raccomanda che i trigger non vengano eseguiti a una frequenza superiore a 5 secondi (0,2 Hz) per mantenere le prestazioni e la reattività dell'app.

Impatto sulla coda dei trigger

I trigger dell’app vengono eseguiti dall’alto verso il basso in una coda sequenziale a thread singolo, nota come coda dei trigger.

Due fattori determinano l’efficienza operativa della coda:

1. Frequenza di inserimento nella coda: la frequenza con cui gli eventi trigger vengono aggiunti alla coda
2. Velocità di uscita dalla coda: la rapidità con cui la logica del trigger completa l’esecuzione

Quando i trigger entrano nella coda più velocemente di quanto ne escano, la coda si accumula. Un accumulo prolungato nella coda dei trigger causa latenza nell’app e, in alcuni casi, la perdita di eventi trigger.

Pensate alla frequenza dei trigger come al traffico autostradale. Se troppe auto entrano in autostrada in un breve lasso di tempo, il traffico rallenta. Per evitare l’accumulo, le auto devono entrare a una velocità che l’autostrada sia in grado di gestire.

Frequenza combinata

La frequenza combinata di tutti gli eventi trigger in un’app determina la frequenza complessiva di inserimento nella coda. Ogni evento trigger configurato contribuisce a questa frequenza combinata.

Consultare la tabella seguente per alcuni esempi di frequenza combinata:

Scala di velocità della logica di trigger

Il tipo di logica di trigger determina la velocità con cui i trigger escono dalla coda. Le logiche che richiedono comunicazione con il cloud, transizioni o risposte da sistemi esterni richiedono un tempo di esecuzione significativamente più lungo rispetto alle operazioni locali.

La tabella seguente descrive la velocità dei diversi tipi di logica.

Fattori tecnici che influenzano le prestazioni dei trigger

• Hardware locale - La logica dei trigger viene eseguita sull'hardware locale e, pertanto, le specifiche del dispositivo influiscono in modo determinante sulla velocità con cui i trigger vengono completati ed escono dalla coda. Per le specifiche dei dispositivi, consultare Dispositivi consigliati per Tulip Player.
• Dipendenze esterne - Le dipendenze esterne includono la connettività al cloud, la latenza della rete locale e il tempo di risposta di sistemi esterni come i sistemi ERP (Enterprise Resource Planning).
• Dispositivi collegati tramite dispositivi Tulip Edge - Le app Tulip dipendono dalla connettività al cloud, il che può introdurre latenza. Ad esempio, un controller di coppia collegato a un dispositivo edge comunica comunque con Tulip Player tramite i servizi cloud di Tulip. Per comprendere le connessioni dei dispositivi, consultare questi diagrammi di sequenza relativi alle connessioni dei dispositivi tramite driver Tulip.
• Problemi di latenza con le funzioni di connettore - Una risposta lenta da parte di un sistema (ad es. un ERP) tramite una funzione di connettore può causare ritardi nell’app, specialmente se l’app esegue un ciclo su molti record, ciascuno dei quali richiede potenzialmente una chiamata API di due secondi. Per comprendere le connessioni di sistema, consultare questi diagrammi di sequenza relativi alla connessione ai sistemi aziendali.
• Latenza tra l’area produttiva e l’infrastruttura cloud di Tulip - Per ridurre al minimo la latenza, l’istanza di Tulip è situata nella stessa area geografica dell’area produttiva.

Linee guida

Evitare i trigger ad alta frequenza

Dovreste evitare, ove possibile, i trigger ad alta frequenza e utilizzare invece altre funzionalità, come le " Automation".

Potreste anche voler riprogettare l’architettura della vostra applicazione per operare a una frequenza inferiore. Ad esempio:* Generazione di report sui dati meno frequente tramite query e aggregazioni* Per i casi d’uso asincroni, il ciclo può essere eseguito tramite Automazioni* Per i casi d’uso sincroni, i cicli che devono essere eseguiti in modo sequenziale dovrebbero essere gestiti tramite Funzioni

Se è necessario utilizzare un trigger ad alta frequenza, è consigliabile configurarlo in modo che esegua solo operazioni locali (ad esempio, l’aggiornamento di una variabile dell’app). Successivamente, utilizzare un trigger a bassa frequenza per le esecuzioni più lente (ad esempio, l’aggiornamento di un record di tabella).

Se si utilizza un trigger Timer ad alta frequenza per reagire rapidamente al contesto esterno a un’app Tulip, è possibile utilizzare una Tulip Machine di tipo “Event Stream” con trigger di macchina e di dispositivo.

Utilizzo delle API delle tabelle di Tulip

L’utilizzo delle API delle tabelle per leggere o scrivere più volte al secondo può influire sulle prestazioni dell’istanza e causare ritardi nella lettura o nell’archiviazione dei dati. Le raccomandazioni riportate di seguito si applicano a tutti gli script e alle azioni dei trigger che eseguono le API di Tulip su un’istanza di Tulip:

Raccomandazione

• Pianifica l’esecuzione della logica in modo da rispettare i limiti di frequenza delle tabelle di Tulip
• Evitate scritture frequenti sullo stesso record in una tabella (più di 1 al secondo)

Quando le soglie vengono superate, Tulip potrebbe applicare un limite di frequenza e restituire il codice di errore 429. Gli script devono essere progettati per gestire i codici di errore 429 in modo da riprovare dopo un certo ritardo.

Trigger di macchina, dispositivo e timer

I trigger a timer a intervalli brevi (ogni 1-2 secondi) possono sovraccaricare le vostre applicazioni, specialmente quando i trigger a timer includono più chiamate API (ad esempio, scritture in tabella o esecuzioni di funzioni del connettore).

I trigger di macchina rilevano le modifiche degli attributi provenienti dalle apparecchiature collegate ed eseguono la logica di risposta. Quando un machine attributes a invia dati ad alta frequenza o quando vengono monitorati più attributi contemporaneamente, l’esecuzione dei trigger può superare la velocità con cui l’app li elabora. Ciò può causare un calo delle prestazioni.

Raccomandazione

• Limitare le sottoscrizioni di " machine attribute " solo a quelle necessarie per la fase o il flusso di lavoro corrente
• Separare la logica ad alta frequenza dalle operazioni cloud e utilizzare un trigger a frequenza inferiore per gestire le azioni dipendenti dal cloud

Scenario di esempio: un " machine attribute " si aggiorna 4 volte al secondo ed è necessario tenere traccia del conteggio degli aggiornamenti in un record della tabella. Trigger 1 (evento macchina): aggiorna una variabile dell'app con i dati in entrata dalla macchina. Trigger 2 (timer, ogni 10 secondi): scrivi i dati accumulati in un record della tabella

• Si consiglia di utilizzare le automazioni per l'elaborazione asincrona al fine di alleggerire il carico di elaborazione dalla coda dei trigger. Ad esempio, se i dati della macchina devono essere elaborati ma non richiedono un feedback immediato da parte dell'operatore nella sessione dell'app
• Utilizzare solo operazioni veloci nei trigger, come "Leggi/aggiorna variabili dell'app" o "Leggi record della tabella"
• Valutate l’architettura della vostra app e considerate la possibilità di riprogettarla per funzionare a una frequenza inferiore se il vostro caso d’uso richiede il monitoraggio di molti attributi ad alta frequenza. Approcci alternativi includono:
• Aggregare i dati a livello di macchina o di dispositivo edge prima di inviarli a Tulip
• Utilizzare le automazioni per la raccolta e l’elaborazione dei dati
• Ridurre la frequenza di segnalazione a livello della fonte dati
• Valutare l’utilizzo dei driver Tulip Player anziché dei driver ospitati sui dispositivi edge
• Driver Player dello strumento Torque

{{snippet.Hai trovato quello che cercavi?}}