Comprendere il comportamento delle prestazioni del monitoraggio DTA

I fattori principali che determinano la velocità effettiva massima sostenibile (MST) per il rilevamento DTA sono:

• Velocità di trasmissione dei messaggi desiderata, ovvero messaggi ricevuti per unità di tempo, per il sistema.

• Quantità di dati rilevati per ogni messaggio.

• Per quanto tempo i dati risiedono nel database BizTalkDTADb prima di essere eliminati, ovvero la finestra di conservazione dei dati.

• Indica se i dati di BizTalkDTADb vengono archiviati e eliminati. L'archiviazione è facoltativa, ma l'eliminazione deve essere eseguita periodicamente.

  C'è una cosa che tutti questi fattori hanno in comune: la velocità con cui il DTA può accettare ed elaborare (archiviare e ripulire) i dati.

Impatto della velocità di inserimento ed elaborazione di BizTalkDTADb sul sistema

Si esaminerà ora il percorso dei dati di rilevamento descritto in Misurazione della velocità effettiva massima di rilevamento sostenibile e si valuterà l'impatto dell'inserimento e dell'elaborazione di BizTalkDTADb sui vari componenti del sistema.

A partire dalle tabelle trackingdata e spooling, è possibile immaginare che, se i processi che spostano dati da queste tabelle al database BizTalkDTADb non sono in grado di inserire dati nel database BizTalkDTADb almeno quanto il runtime sta inserendo nei dati di rilevamento e nelle tabelle di spooling, le tabelle spool e trackingdata inizieranno a creare un backlog. Questo non è necessariamente un problema a breve termine, purché si sappia che la velocità effettiva del messaggio verrà ridotta per consentire all'arretrato di esaurirsi completamente. Tuttavia, purché i dati siano ancora presenti nelle tabelle spool o trackingdata, non saranno disponibili nel database BizTalkDTADb per l'esecuzione di query tramite le query di tracciamento sulla pagina Group Hub o in qualsiasi altro strumento. Pertanto, non sarà utile per la risoluzione dei problemi. Pertanto, tutti i periodi di backlog previsti devono essere sufficientemente brevi che le informazioni rilevate siano ancora disponibili in modo tempestivo in caso di problemi che devono essere analizzate usando i dati BizTalkDTADb.

Dai test sappiamo che non sono i processi che spostano i dati di rilevamento nel database BizTalkDTADb (ovvero TDDS e TrackedMessages_Copy_BizTalkMsgBoxDb) a determinare se si accumula un backlog, ma la velocità del database BizTalkDTADb nell'accettare l'input. In genere, si tratta del file di dati del database BizTalkDTADb associato a I/O. In altre parole, è la velocità dell'unità su cui risiede il file di dati del database BizTalkDTADb che determinerà la velocità complessiva del DTA.

Impatto della quantità di dati in BizTalkDTADb sulla velocità di I/O

Un altro fattore chiave correlato alla velocità di I/O è la quantità di dati nel database BizTalkDTADb: man mano che la quantità di dati rilevati nel database BizTalkDTADb aumenta, la velocità di input e elaborazione del database BizTalkDTADb diminuisce poiché sono presenti semplicemente più dati da ordinare man mano che vengono inseriti nuovi dati e ciò influisce sulla quantità di I/O necessaria per ogni inserimento.

In questo caso, l'archiviazione e la pulitura entrano in gioco, poiché sono questi processi che impediscono al database BizTalkDTADb di crescere troppo per essere gestito. L'idea di base consiste nel assicurarsi che le dimensioni del database BizTalkDTADb vengano mantenute al di sotto del livello in cui iniziano a eseguire il backup nelle tabelle spool e trackingdata. Tuttavia, i processi di eliminazione e archiviazione implementati nel processo SQL DTA Purge and Archive (BizTalkDTADb) richiedono anche risorse (CPU, memoria e soprattutto I/O) dal server di database BizTalkDTADb, che deve essere preso in considerazione quando si misura MST con il rilevamento.

Vedere anche

Misurazione della capacità massima sostenibile di tracciamento
Scenari di test per la misurazione dell'MST nel monitoraggio DTA
Suggerimenti e consigli per trovare il rilevamento MST di DTA
Linee guida per il ridimensionamento del database di rilevamento