Con la continua maturazione del mercato dell'integrazione, la richiesta di supportare ed elaborare flussi di dati e processi sempre più complessi è costante. Quando le applicazioni elaborano dati di grandi dimensioni, spesso esauriscono le risorse e diventano poco reattive, lasciando gli utenti confusi e insoddisfatti. La valutazione delle risorse e l'avviso agli utenti con messaggi appropriati sono alcuni dei fattori più importanti di un software ideale. Nella versione Winter 2016 di SnapLogic Elastic Integration Platform, abbiamo introdotto il concetto di pipeline queuing, che consente agli utenti di definire le soglie per i loro Snaplex e, quando le soglie vengono raggiunte, ogni ulteriore richiesta viene messa in coda fino alla disponibilità delle risorse successive.
Come si impostano le soglie per gli Snaplex?
Le pipeline SnapLogic vengono eseguite in un contenitore chiamato Snaplex. Le pipeline sono costituite da Snap e ogni Snap consuma memoria in uno Snaplex. Una volta consumata tutta la memoria in uno Snaplex, questo viene sovraccaricato e raggiunge la sua soglia.
Poiché gli snap consumano la maggior parte della memoria di Snaplex, diventano un fattore importante nel determinare la soglia di Snaplex. Gli utenti possono definire la soglia di Snaplex definendo il numero di snap che può elaborare in un determinato momento o l'utilizzo complessivo della memoria. Una volta raggiunta la soglia, Snaplex non elabora alcuna richiesta di pipeline finché le risorse non vengono liberate e rese nuovamente disponibili. Tutte le pipeline rifiutate sono contrassegnate come in coda nella dashboard di SnapLogic per avvisare gli utenti che i loro Snaplex sono sovraccarichi.
Di seguito sono riportati i valori che definiscono le soglie di Snaplex. Si noti che il termine "slot" si riferisce al numero di snap. Spiegherò ciascuno di essi in dettaglio più avanti in questo blog.
- Slot massimi
- Slot riservato %
- Memoria massima %
Slot massimi: Il numero massimo di snap che ogni nodo di uno Snaplex può elaborare in un determinato momento. Vediamo di approfondire i dettagli con esempi pertinenti. I due esempi che ho creato sono:
- Le soglie di Snaplex non sono soddisfatte e accetta la richiesta di pipeline
- Snaplex raggiunge le sue soglie e le richieste di pipeline successive vengono messe in coda.
Nei miei esempi, ho ipotizzato che ci sia un certo numero di pipeline già in esecuzione su Snaplex. Ogni Snap della pipeline consuma uno slot nella memoria. Oltre a questi, ci sono thread attivi che eseguono operazioni di base su Snaplex e che consumano anch'essi la memoria dello Snaplex. Ho considerato sia gli snap che i thread attivi nella categoria degli snap consumati.
Di seguito è riportata la distribuzione della memoria:
- Slot massimi: 1000
- Slot consumati (thread attivi + pipeline in esecuzione): 500
- Slot disponibili (slot massimi + Snaps consumati): 500
Esempio 1: Snaplex non ha raggiunto le sue soglie e accetta le richieste di pipeline.
In questo esempio, creo una pipeline con, ad esempio, 300 snap e la pianifico per l'esecuzione contro questo Snaplex creando un'attività. Quando si pianifica l'esecuzione di questo task, lo Snaplex controlla le risorse disponibili, che in questo caso sono 500. Poiché ci sono 500 slot disponibili, lo Snaplex accetta la richiesta e la elabora. Tuttavia, qualsiasi altra richiesta effettuata non sarà accettata e verrà messa in coda. I dettagli verranno approfonditi nel prossimo esempio.
Esempio 2: Snaplex raggiunge il valore di soglia e le pipeline vengono accodate.
In questo esempio, ho creato una pipeline di grandi dimensioni con 800 snap e ne ho programmato l'esecuzione. Quando questa richiesta arriva a Snaplex, questo controlla gli slot disponibili, che in questo caso sono 500. Ovviamente, la richiesta è molto più grande del numero di slot che Snaplex può allocare, quindi la rifiuta e la spinge in una coda. Ovviamente, la richiesta è molto più grande del numero di slot che Snaplex può allocare, quindi la rifiuta e la mette in coda. Una volta completata l'elaborazione delle pipeline esistenti, Snaplex rende disponibili le sue risorse ed elabora la prossima richiesta in coda. Ecco una visualizzazione delle pipeline in coda nella Dashboard:
Slot riservato %: La percentuale degli slot massimi assegnati per l'esecuzione manuale delle pipeline; questi slot sono riservati solo per l'esecuzione manuale delle pipeline. Quando le pipeline programmate consumano tutti gli slot disponibili, gli slot riservati assicurano che le pipeline possano ancora essere eseguite manualmente.
- Slot massimi: 1000
- Slot riservato %: 10 = 100
- Slot consumati: 900
- Slot disponibili (slot massimi = slot riservati % + slot consumati): 0
Consideriamo lo stesso esempio di prima e supponiamo che tutti gli slot disponibili siano stati consumati. Qualsiasi altra pipeline pianificata verrà messa in coda, poiché gli slot sono tutti occupati. Tuttavia, poiché agli slot riservati viene assegnato un valore, posso ancora eseguire pipeline da SnapLogic Designer che non contengano più di 100 snap. Tuttavia, se eseguo pipeline con più di 100 snap, queste verranno rifiutate e messe in coda e all'utente verrà visualizzato un messaggio di errore (mostrato sotto):
Percentuale di memoria: Un altro fattore importante per misurare la soglia di Snaplex è la memoria di Snaplex. Impostando la percentuale di memoria, ad esempio, al 75%, le richieste di pipeline vengono accettate finché non viene consumato il 75% della memoria di Snaplex. Una volta raggiunta questa soglia, tutte le altre richieste vengono messe in coda ed elaborate in seguito, quando la memoria diventa disponibile.
Sintesi
In sintesi, le soglie di Snaplex sono definite dall'utente e quando uno Snaplex raggiunge la sua soglia, le richieste di pipeline vengono rifiutate e segnate come in coda nella Dashboard. Per evitare il sovraccarico di Snaplex, gli utenti possono regolare le attività programmate o aggiungere altri nodi ai loro Snaplex.
