Suggerimenti per individuare la velocità effettiva massima sostenibile del rilevamento DTA

Per definizione, la velocità effettiva massima sostenibile (MST, Maximum Sustainable Throughput) è un parametro di riferimento che consente di misurare in modo riproducibile le prestazioni del sistema mediante un carico costante. Di seguito vengono riportate le situazioni in cui risulta particolarmente utile conoscere l'MTS.

1. Quando è necessaria la latenza più bassa dal sistema. In caso di superamento dell'MST, nel sistema si genera un backlog, che introduce un aumento di latenza per i messaggi. Anche se solo temporaneo, il backlog ha un effetto immediato e deleterio sulla latenza. Conoscendo l'MST del sistema, si potrà definire la velocità effettiva massima assoluta che è possibile raggiungere prima che la latenza di elaborazione di singoli messaggi aumenti considerevolmente (ad esempio, passando da secondi a minuti a seconda della configurazione).

2. Quando si confronta con altri sistemi. Ad esempio, se si desidera convalidare il raggiungimento dell'MST previsto rispetto a un altro sistema (ad esempio, lo scenario di questo argomento, un case study o un altro sistema presente nell'ambiente), la misurazione dell'MST con un input costante offre uno standard riproducibile e senza ambiguità per eseguire tale confronto.

   Ovviamente, la misurazione dell'MST può risultare dispendiosa in termini di tempo. Prima di impegnarsi in una lunga procedura di misurazione, è pertanto consigliabile valutarne i vantaggi. Nella maggior parte dei sistemi di produzione, l'input non è costante come quello misurato dall'MST, ma si verifica piuttosto un carico variabile nel tempo. È questo profilo di carico che è necessario alla fine verificare per certificare un sistema prima della produzione. Fortunatamente, per valutare la sostenibilità del profilo di carico di produzione è possibile utilizzare la stessa tecnica utilizzata per misurare l'MST. È sufficiente eseguire il profilo di carico abbastanza a lungo da includere uno o più intervalli di tempo di mantenimento dei dati del database BizTalkDTADb e osservare gli indicatori di prestazioni chiave (KPI).

   È importante avviare l'esecuzione dei test, per l'MST o per i profili di carico, con un database BizTalkDTADb vuoto. I dati memorizzati in questo database sono soggetti a limiti temporali e, se non vengono riacquisiti come nuovi per ogni test, si possono ottenere risultati distorti. A seconda dell'intervallo di mantenimento dei dati, il tempo necessario per individuare l'MST può aumentare notevolmente. Per limitare il problema, la regolazione immediata del carico durante l'esecuzione dei test può risultare utile per un azzeramento più rapido secondo l'MST.

   Ad esempio, se è trascorso il primo intervallo di mantenimento dei dati e gli indicatori KPI segnalano la disponibilità di spazio per una velocità effettiva più elevata (ad esempio, il tempo di inattività del disco è ancora al di sopra di zero), è possibile aumentare il carico in modo incrementale e osservarne l'effetto. Una volta definita in questo modo la stima dell'MST, tuttavia, al fine di convalidarla, è importante eseguire un test a partire da un database BizTalkDTADb vuoto.

Raccomandazioni

L'architettura del sistema di rilevamento in BizTalk Server è in grado di tenere traccia di un'ampia gamma di informazioni e deve essere gestita e monitorata con attenzione. I fattori che influiscono maggiormente sulle prestazioni del sistema, come indicato dall'MST, sono i seguenti:

• La velocità effettiva desiderata per il sistema

• Il volume delle informazioni rilevate per ogni istanza di messaggio e di servizio presente nel sistema. Tale volume determinerà la velocità di aumento del database BizTalkDTADb e infine la frequenza con cui il database deve essere ripulito per evitare ritardi.

• Tempo per cui si desidera mantenere i dati nel database BizTalkDTADb, ovvero l'intervallo di mantenimento dei dati. Più esteso è l'intervallo, più aumenterà il database BizTalkDTADb influendo quindi sulla velocità effettiva.

• Archiviazione ed eliminazione dei dati del database BizTalkDTADb o semplice pulitura per mantenere le dimensioni del database BizTalDTADb.

  Il processo di individuazione della velocità effettiva massima sostenibile per il rilevamento in BizTalk Server prevede tre indicatori chiave delle prestazioni:

• Tempo di inattività del disco fisico per il sottosistema del disco del file di dati DTADb

• Profondità dello spooler

• Profondità di BizTalkDTADbdata.

  Per individuare l'MST del sistema o convalidare la velocità effettiva del profilo di produzione, monitorare questi tre indicatori ricercando:

• La profondità stabile della tabella trackingdata e dello spooler

• Il tempo di inattività fisica del disco del file di dati del database BizTalkDTADb è quasi, ma non stabilmente, zero.

  L'utilizzo delle funzionalità di rilevamento DTA implica un impatto sulle prestazioni. Il rilevamento predefinito potrebbe tenere traccia di più informazioni rispetto a quanto necessario una volta introdotta la soluzione nell'ambiente di produzione, ma consente di semplificare le operazioni di sviluppo, verifica iniziale e debug fornendo ampie informazioni per la risoluzione dei problemi. È pertanto consigliabile mantenere il rilevamento predefinito durante le fasi di sviluppo e verifica iniziale. Quando una soluzione distribuita in BizTalk è stabile e pronta per la certificazione di produzione, comprese le verifiche delle prestazioni, è consigliabile esaminare attentamente la quantità di informazioni di cui è necessario tenere traccia in produzione e la quantità di tempo per cui è necessario mantenerle nel database BizTalDTADb ed eseguire le regolazioni di conseguenza.

  Ad esempio, se non è necessario tenere traccia dei corpi dei messaggi ai fini del non-ripudio o della risoluzione dei problemi, non attivare il rilevamento dei corpi dei messaggi. Per illustrare questo punto, nello scenario di esempio descritto in Scenari di test per la misurazione dell'MST del rilevamento DTA, quando il componente di rilevamento del corpo del messaggio della configurazione di rilevamento è stato eliminato, l'MST è stato raddoppiato a 40 messaggi al secondo.

  Tenere inoltre presente che anche quando si verificano problemi, in molti casi (ma non in tutti), i messaggi vengono sospesi nel database MessageBox da dove possono essere recuperati ed esaminati senza bisogno di rilevamento dei corpi dei messaggi.

  Sostenibilità del carico applicato nel sistema:

• Può il sistema sostenere all'infinito il profilo di carico di produzione, anche con normali attività di manutenzione?

• Che cosa succede se si verifica un evento per cui il sistema deve sostenere un backlog, ad esempio un'interruzione pianificata o imprevista del database BizTalkDTADb?

  È consigliabile definire obiettivi basati sugli scenari peggiori ed eseguire le verifiche secondo tali obiettivi. Ad esempio, se si prevede un ciclo periodico di attività di manutenzione pianificata in cui il database BizTalkDTADb non sarà in linea, emulare questa interruzione durante un test per valutare la capacità di recupero del sistema dal backlog risultante.

Vedere anche

Misurazione della velocità effettiva massima di rilevamento sostenibile
Informazioni sul comportamento delle prestazioni di rilevamento DTA
Scenari di test per misurare la velocità effettiva massima sostenibile del rilevamento DTA
Indicazioni per la definizione delle dimensioni del database di rilevamento