Condividi tramite

Informazioni sulle prestazioni sostenibili

  • Articolo

Durante la pianificazione e la valutazione della sostenibilità del sistema è fondamentale pensare in termini di sostenibilità a lungo termine. Di seguito sono riportate le considerazioni principali da tenere presente in relazione alla sostenibilità:

  • Profili di carico e obiettivi prestazioni: non è possibile avere troppi dettagli quando si tratta di profili di caricamento e obiettivi di prestazioni. Il test e la certificazione del livello di preparazione saranno basati sulla capacità di gestione a lungo termine di questi carichi.

  • Altre attività e processi che competono per le risorse del server: non si tratta solo del caricamento del messaggio. Sui server vengono eseguiti altri processi e attività che hanno effetto sulle prestazioni, quali manutenzione di database ed esecuzione di query sul database MessageBox.

  • Interruzioni del sistema pianificate e non pianificate: eventi e backlog del messaggio di floodgate possono modificare il profilo di carico effettivo.

    Quando si prevede di creare sistemi sostenibili e di eseguirne la certificazione tramite test, assicurarsi di prendere in considerazione e valutare questi fattori.

Verifica della sostenibilità delle prestazioni

Quando si parla di prestazioni per BizTalk Server, si definiscono prestazioni massime sostenibili come indicato di seguito:

  • Massimo carico del traffico di messaggi che un sistema è in grado di gestire per un tempo illimitato in un ambiente di produzione.

    Oltre a questo aspetto, che potrebbe sembrare piuttosto semplice, esistono tuttavia numerosi fattori che è necessario prendere in considerazione quando si valuta la capacità di una soluzione, eseguita su uno specifico insieme di componenti hardware, di supportare i carichi che occorre gestire quotidianamente dopo l'introduzione della soluzione nell'ambiente di produzione.

    Prima che la soluzione passi alla fase di produzione, per valutare se tale soluzione sia in grado di gestire il carico massimo del traffico di messaggi per un periodo d tempo illimitato, prendere in considerazione i fattori seguenti:

  • Obiettivi di prestazioni e profili in termini di latenza/velocità effettiva desiderati.

  • Altri processi in esecuzione sugli stessi componenti hardware, tra cui:

    • Normale monitoraggio e risoluzione dei problemi

    • Operazioni di manutenzione dei database, quali distribuzione dei registri, backup, eliminazione, manutenzione degli indici e aggiornamenti delle statistiche.

    • Altre applicazioni

  • Interruzioni del sistema pianificate e non pianificate, quali:

    • Disattivazione dei siti dei partner che impedisce la trasmissione o la ricezione dei messaggi.

    • Tempi di inattività per le regolari operazioni di manutenzione del sistema.

Conoscenza degli obiettivi in termini di prestazioni

Prima di poter valutare la sostenibilità della soluzione, è necessario disporre di una conoscenza approfondita dei carichi di produzione previsti. È impossibile valutarne l'idoneità senza un obiettivo ben riconosciuto. Un insieme di obiettivi di prestazione ben formulato è essenziale per il controllo delle strategie relative a verifica e certificazione del sistema. È opportuno che gli obiettivi prefissati in termini di prestazioni prevedano gli elementi seguenti:

  • Curva per la definizione delle prestazioni come funzioni temporali. Queste funzioni possono presentare diversi gradi di complessità, da estremamente semplici a molto complesse.

  • Requisiti in termini di prestazioni associati alle funzioni delle prestazioni.

  • Distribuzione di dimensioni e tipi di file.

Esempio 1

  • ogni giorno, i messaggi si accumulano e da 0 messaggi al secondo alle ore 8:00 è possibile che arrivare a 80 messaggi al secondo a mezzogiorno e di nuovo a 0 messaggi al secondo alle 21:00, un processo che potrebbe essere rappresentato tramite una curva a campana.

  • il sistema non presenta requisiti di latenza specifici per ciascun messaggio, ma deve essere in grado di elaborare il carico corrente più tutto il carico di messaggi del giorno precedente, ad esempio in caso di interruzione del sistema di 24 ore, senza presentare ritardi.

  • Esistono tre tipi di documento: Sales Basket, Back Order e Stock Request. Le dimensioni dei documenti Sales Basket sono comprese tra 2 e 10 kilobyte e costituiscono il 75% del numero di messaggi in un determinato momento. Le dimensioni dei documenti Back Order e Stock Request sono sempre pari a 1 kilobyte e costituiscono rispettivamente il 10% e il 15% del numero di messaggi in un dato momento.

Esempio 2

  • ogni notte a mezzanotte viene ricevuto un batch di 500.000 messaggi per l'elaborazione.

  • l'elaborazione di tutti i messaggi del batch deve essere completata entro 8 ore.

  • tutti i messaggi sono dello stesso tipo e le relative dimensioni sono distribuite uniformemente in un intervallo che va da 10 a 50 kilobyte compreso. Il batch inoltre contiene sempre 10 messaggi di tipo catalogo ciascuno dei quali presenta dimensioni pari a 10 MB e, ai fini dell'elaborazione, è necessario suddividerli in singole voci di catalogo.

Esempio 3

  • 4.000 addetti al servizio di assistenza clienti accedono al sistema interattivo ogni mattina alle 8:00 e ciascuno di essi esegue, in media, 4 richieste al minuto fino all'orario di chiusura alle ore 17:00, 7 giorni a settimana.

  • tutte le richieste devono restituire risultati in meno di 2 secondi.

  • tutte le richieste sono dello stesso tipo e le relative dimensioni sono distribuite uniformemente in un intervallo che va da 500 a 1000 byte compreso.

Requisiti in termini di prestazioni associati alle funzioni delle prestazioni

Continuando con gli esempi precedenti:

  • Esempio 1 (continuato): il sistema non ha requisiti di latenza specifici per ogni messaggio, ma deve essere in grado di elaborare questo carico, oltre a tutto il carico del messaggio del giorno precedente (ad esempio, in caso di interruzione del sistema di 24 ore) senza venire dietro.

  • Esempio 2 (continuato): tutti i messaggi nel batch devono essere elaborati per il completamento in 8 ore.

  • Esempio 3 (continua): tutte le richieste devono restituire risultati in meno di 2 secondi.

Distribuzione di dimensioni e tipi di file

  • Esempio 1 (continua): sono disponibili tre tipi di documento: Sales Basket, Back Order e Stock Request. Le dimensioni dei documenti Sales Basket sono comprese tra 2 e 10 kilobyte e costituiscono il 75% del numero di messaggi in un determinato momento. Le dimensioni dei documenti Back Order e Stock Request sono sempre pari a 1 kilobyte e costituiscono rispettivamente il 10% e il 15% del numero di messaggi in un dato momento.

  • Esempio 2 (continua): tutti i messaggi sono dello stesso tipo e vengono distribuiti in modo uniforme tra 10 e 50 Kilobyte, inclusivi. Il batch inoltre contiene sempre 10 messaggi di tipo catalogo ciascuno dei quali presenta dimensioni pari a 10 MB e, ai fini dell'elaborazione, è necessario suddividerli in singole voci di catalogo.

  • Esempio 3 (continuo): tutte le richieste sono lo stesso tipo e vengono distribuite uniformemente tra 500 e 1000 byte di dimensioni, inclusive.

Altri processi

Oltre ai profili di carico che passano direttamente attraverso il motore BizTalk, altri processi si contendono le risorse sullo stesso hardware. Questi processi determinano una riduzione delle capacità globali in termini di prestazioni sostenibili del sistema. La manutenzione dei database rappresenta probabilmente l'esempio più comune di questo tipo di processo.

Ogni database, di piccole o grandi dimensioni, richiede operazioni di manutenzione periodiche, quali distribuzione dei registri, backup, archiviazione ed eliminazione. Il monitoraggio e la risoluzione dei problemi sono altri esempi di operazioni che è necessario prendere in considerazione durante la definizione e la certificazione della sostenibilità del sistema. L'esecuzione di una query sul database MessageBox (tramite la pagina Hub gruppo della Console di amministrazione) per verificare il numero di messaggi di un determinato tipo che sono stati sospesi nelle ultime 24 ore richiede, ad esempio, risorse del server SQL Server che potrebbero essere altrimenti utilizzate per l'elaborazione dei messaggi.

Di seguito è riportato un elenco di attività che in genere avranno l'effetto più effettivo sulla sostenibilità complessiva in BizTalk Server:

  • Log Shipping e Backup. Nell'ambito della maggior parte dei piani di ripristino di emergenza che coinvolgono SQL Server, è necessario eseguire periodicamente il log shipping e il backup per tutti i database del gruppo di BizTalk Server. Per altre informazioni, vedere Backup e ripristino di database BizTalk Server. Vedere anche Log Shipping.

  • Archiviazione ed eliminazione dei dati di rilevamento. Oltre al piano di log shipping e backup complessivo, il database BizTalk Tracking (BizTalkDTADb) ha un proprio regime di archiviazione ed eliminazione; per altre informazioni, vedere Archiviazione ed eliminazione del database di rilevamento BizTalk. La velocità di archiviazione ed eliminazione dei dati dal database di rilevamento BizTalk è particolarmente importante in quanto l'archiviazione e l'eliminazione del database di rilevamento BizTalk rappresenta in genere un collo di bottiglia quando si utilizza il rilevamento.

  • Query di sistema. L'utilizzo di API o dell'interfaccia utente della Console di amministrazione BizTalk Server per eseguire vari tipi di query sul sistema avrà effetto sulla sostenibilità delle prestazioni.

  • Manutenzione di MessageBox. Esistono diversi processi SQL che fanno parte della funzionalità principale di BizTalk Server che gestiscono il database MessageBox eliminando messaggi e istanze che hanno completato l'elaborazione. Come parte del motore di base, la velocità di completamento di questi processi rappresenta un fattore chiave nella valutazione della sostenibilità. Per altre informazioni su questi processi e sul relativo ruolo, vedere Gestione di BizTalk Server1.

  • Attività di distribuzione della soluzione. Quando si distribuiscono, associano e avviano nuove applicazioni o nuove versioni di applicazioni esistenti, viene applicato un carico aggiuntivo a BizTalk, quale la creazione di nuove sottoscrizioni nei database MessageBox. Una volta distribuite le applicazioni, i messaggi in fase di elaborazione competono per l'utilizzo delle risorse e, pertanto, influiscono sulle prestazioni delle applicazioni esistenti.

    Per ognuna di queste aree, è necessario chiedere: Qual è la raccomandazione per ridurre al minimo l'impatto di queste attività? stabilendo ad esempio se sia opportuno pianificare la relativa esecuzione in un orario differente.

Interruzioni pianificate e non pianificate

Gli effetti delle interruzioni sulle prestazioni del sistema variano a seconda del sistema interessato dall'interruzione. Di seguito sono tuttavia riportate le conseguenze più comuni:

  • Eventi di inondazione. Quando i sistemi restano inattivi per un lungo periodo di tempo, i messaggi possono accumularsi e arrivare tutti contemporaneamente per l'elaborazione quando i sistemi sono di nuovo operativi. Se ad esempio un'applicazione in esecuzione su BizTalk riceve messaggi tramite MSMQ e tale applicazione resta inattiva per un determinato periodo di tempo, i messaggi si accumuleranno nelle code in attesa di essere prelevati. Quando l'applicazione viene avviata di nuovo, è come se i messaggi accumulati arrivassero tutti insieme contemporaneamente.

  • Backlog del messaggio. Quando i sistemi a cui vengono inviati i messaggi sono inattivi, viene eseguito in genere un ciclo di ripetizione dei tentativi che prevede l'utilizzo di risorse aggiuntive. Dopo la conclusione di questo ciclo, i messaggi vengono in genere sospesi. I sistemi inattivi vengono riportati in linea e successivamente si verifica un tipo di evento di sovraccarico in seguito al quale è possibile ripristinare e/o inviare un numero elevato di messaggi.

    Durante la progettazione e la certificazione di un sistema è necessario naturalmente prendere in considerazione tutte le interruzioni pianificate, come le operazioni di manutenzione pianificate a intervalli regolari. È inoltre consigliabile prendere in considerazione un'analisi delle interruzioni non pianificate e dei relativi effetti.

    L'identificazione dei tipi di interruzioni che possono verificarsi, la relativa classificazione in base al livello di rischio stimato (ottenuto dalla moltiplicazione della probabilità per il livello di gravità) e la stima della durata e dell'effetto, ad esempio eventi di sovraccarico, volume di messaggi sospesi, backlog e così via, delle interruzioni a rischio più elevato indicheranno la capacità del sistema desiderata in caso di eventuali interruzioni. Qualsiasi sistema asincrono basato su messaggistica, ad esempio BizTalk Server, deve essere progettato elaborando "headroom" sufficiente per gestire interruzioni pianificate e non pianificate.

Vedere anche

Persistenza e durabilità del motore
Suggerimenti per la pianificazione dei progetti per fase
Misurazione della velocità effettiva massima sostenibile del motore
Misurazione della velocità effettiva massima di rilevamento sostenibile
Scalabilità delle soluzioni
Identificazione dei colli di bottiglia delle prestazioni
Prestazioni e capacità del motore