Scenari di test per misurare la velocità effettiva massima sostenibile del rilevamento DTA

Per illustrare come funziona tutto ciò in pratica e presentare una tecnica semplice per misurare la velocità effettiva massima sostenibile (MST, Maximum Sustainable Throughput) per il rilevamento, verrà descritto uno scenario di test in cui è stata misurata la velocità effettiva massima sostenibile del rilevamento. Non solo verranno illustrate le tecniche utilizzate, ma sarà possibile utilizzare i dati presentati come punto di partenza per valutare le prestazioni di rilevamento di altri sistemi.

Importante

Le informazioni contenute in questo argomento rappresentano le conoscenze attuali di Microsoft sulle problematiche trattate alla data di pubblicazione. Poiché le condizioni di mercato e tecnologie sono in costante mutamento, Microsoft non garantisce l'accuratezza di tutte le informazioni presentate dopo la data di pubblicazione.

Topologia e configurazione dello scenario di test

Nella figura seguente vengono illustrate la topologia e la configurazione dello scenario di test. È una compilazione scalabile con quattro server di database MessageBox, un server di database BizTalkDTADb dedicato e un totale di sette server che eseguono BizTalk Server. Si noti che il server BAM illustrato nella figura non è stato utilizzato per questo scenario di test.

Velocità effettiva sostenibile di BizTalkDTADb

Specifica hardware (BizTalk Server)

• CPU: Dual 3 GHz (Cache: L2: 512 KB/L3: 1 MB)

• Memoria: 2 GB di RAM

• HDD: 2 X 32 GB/15 K

  Specifica hardware (SQL Server)

• CPU: Quad 2 GHz (L2: 512 KB/L3: 1 MB)

• Memoria: 4 GB di RAM

• HDD: 2 X 32 GB/15 K + SAN

  Nella figura seguente viene fornita una panoramica sull'architettura dello scenario di test, in cui

• TP = Punto di traccia, un punto in cui alcuni elementi vengono rilevati, ad esempio eventi o proprietà del messaggio.

• MB = Corpo del messaggio, un punto in cui viene rilevato un corpo del messaggio.

  L'architettura della soluzione seguente mostra una configurazione di rilevamento con tre componenti di configurazione principali:

• Rilevamento DTA predefinito. Tutti i punti di traccia dell'evento nella figura sono attiva per impostazione predefinita quando viene installato BizTalk Server.

• Proprietà del messaggio. Il punto di rilevamento associato al componente disassembler (DA) nella pipeline in ingresso rappresenta il rilevamento di 10 proprietà del messaggio in ingresso. Per altre informazioni su come promuovere le proprietà per il rilevamento, vedere Promozione delle proprietà.

• Corpo del messaggio. I due punti corpo messaggio (MB) della figura rappresentano i punti in cui vengono rilevati i corpi dei messaggi. Per altre informazioni su come configurare il rilevamento del corpo dei messaggi, vedere Gestire e tenere traccia degli artefatti bizTalk.

  Architettura dello scenario di test

  

Tecniche di test

L'adapter FILE è stato utilizzato sia per la ricezione che per la trasmissione. Per recapitare messaggi nella condivisione di file in ingresso, è stato utilizzato lo strumento di generazione del carico, LoadGen 2007. Lo strumento LoadGen è stato configurato per recapitare file a una specifica velocità, in modo da poter variare il carico durante la ricerca del livello MST di rilevamento. Per altre informazioni sullo strumento LoadGen, vedere Uso dello strumento LoadGen di Microsoft BizTalk 2007.

Per i test è stata presupposta la necessità di mantenimento dei dati di 24 ore nel database BizTalkDTADb. In altre parole, tutti i dati precedenti a 24 ore sono stati eliminati dal database. Il processo SQL di archiviazione ed eliminazione è progettato per l'eliminazione dei soli dati archiviati, in modo che durante l'esecuzione non vengano persi dati.

Per sottoporre il sistema a un test completo con il requisito indicato, era necessario eseguire il carico per minimo 25 ore, in modo da includere almeno un ciclo di archiviazione ed eliminazione. È stato scelta un'esecuzione di 48 ore, per monitorare il sistema per 24 ore dopo la prima archiviazione ed essere sicuri che il carico fosse sostenibile. Le prime 24 ore erano necessarie per accumulare dati sufficientemente vecchi da essere archiviati (ogni 24 ore), per simulare uno stato stazionario. Il sistema è stato monitorato per le successive 24 ore, per stabilire se tutti i processi (ad esempio, TDDS, archiviazione ed eliminazione) fossero in grado di sostenere la velocità effettiva.

In base alle informazioni acquisite sul comportamento di rilevamento si è compreso che, per determinare la sostenibilità, devono essere monitorati in genere solo pochi indicatori di prestazioni chiave (KPI), ovvero:

• Tempo di inattività del disco fisico per il file di dati del database BizTalkDTADb. Se il tempo di inattività del disco fisico si avvicina a 0, è possibile evincere con sufficiente certezza che il database BizTalkDTADb è stato saturato dal flusso di dati rilevati, dall'attività di archiviazione e/o dall'attività di eliminazione.

• Profondità della tabella trackingdata. Se la tabella trackingdata inizia a crescere in modo progressivo, ovvero continua a crescere senza limiti, è possibile evincere con certezza che, alla velocità effettiva corrente, TDDS non è in grado di inserire dati nel database BizTalkDTADb con una velocità sufficiente a sostenere il carico.

• Profondità dello spool. Sono diversi i fattori che possono causare la crescita dello spooler. Una delle situazioni che possono provocare la crescita dello spooler si verifica se il processo SQL che copia i corpi dei messaggi rilevati dal database MessageBox al database BizTalkDTADb è in ritardo. Poiché i messaggi da rilevare non possono essere rimossi dal database MessageBox (mediante i processi di pulitura di MessageBox) fino a quando non vengono correttamente copiati nel database BizTalkDTADb, se il processo di copia è in ritardo, le dimensioni dello spooler aumentano.

  Per la gran parte dei sistemi, il monitoraggio di questi tre soli indicatori di prestazioni in condizioni di carico fornisce informazioni sufficienti a determinare se il carico sia o meno sostenibile.

  Indicatori di prestazioni chiave con carico sostenibile

  

  Utilizzando lo scenario di esempio, con un carico di 20 messaggi ricevuti al secondo, sono stati acquisiti valori degli indicatori di prestazioni chiave per 48 ore, come illustrato nel grafico Perfmon generato. Si notino nel grafico le tendenze seguenti che indicano la sostenibilità:

• Profondità BizTalkDTADbdata (linee nere) . Con i tre database MessageBox di pubblicazione, è possibile notare che, anche dopo la prima archiviazione di 24 ore, la profondità della tabella trackingdata si stabilizza e non continua a crescere.

• Profondità della bobina (linee blu). La profondità dello spooler è molto stabile durante tutta l'esecuzione e indica quindi che, anche con il consumo di risorse dell'attività di archiviazione ed eliminazione, i messaggi rilevati, di 10 kilobyte ciascuno, vengono copiati nel database BizTalkDTADb senza ritardi.

• File di dati del database BizTalkDTADb Tempo di inattività disco fisico (riga rossa). Per le prime 24 ore precedenti all'esecuzione del processo di archiviazione ed eliminazione, il database BizTalkDTADb database ha accumulato sempre più dati producendo sempre più I/O su disco, man mano che i dati venivano inseriti da TDDS. Ciò è leggibile come una chiara e continua diminuzione del tempo di inattività del disco fisico.

  A 24 ore nell'esecuzione, viene osservato un calo chiaro del tempo di inattività di I/O, che coincide con la prima volta che l'archivio e l'eliminazione hanno lavoro da eseguire. Dopo il primo archivio, l'eliminazione deve eseguire ogni minuto per eliminare i dati precedenti a 24 ore (ricordare che nel sistema è ancora in corso il caricamento), che comporta un tempo di inattività quasi zero.

  Un punto chiave da sottolineare qui è che, dopo l'esecuzione della prima archiviazione, ovvero dopo che il sistema ha superato il primo periodo di "mantenimento dei dati del database BizTalkDTADb attivati", il tempo di inattività del disco si approssima allo zero quando il sistema ha raggiunto o quasi la velocità effettiva massima sostenibile. Questo accade perché il collo di bottiglia del database BizTalkDTADb è quasi sempre la velocità del sottosistema di I/O del disco.

  In molti casi può essere utile misurare la velocità effettiva massima sostenibile disattivando il rilevamento, come base per il sistema. Nel caso in esame, ad esempio, la velocità effettiva massima sostenibile con il rilevamento disattivato è di 290 messaggi al secondo, che supera di gran lunga la velocità effettiva massima sostenibile del sistema con il rilevamento attivato e le funzionalità e il periodo di mantenimento dei dati DTA prima indicati. Questo vuol dire che il sistema con il rilevamento attivato è significativamente sottoutilizzato. In altre parole, è inutile creare un sistema capace di gestire 290 messaggi al secondo quando il rilevamento degli elementi da rilevare supporta una velocità effettiva massima sostenibile di soli 20 messaggi al secondo. Per dirla diversamente, presupponendo che l'hardware del database BizTalkDTADb non cambi, per ottenere una velocità effettiva di 20 messaggi al secondo, sono necessari molti meno server BizTalk e del database MessageBox di quelli disponibili nello scenario illustrato.

Ricerca della velocità effettiva massima sostenibile

Dopo aver esaminato l'aspetto degli indicatori di prestazioni chiave (KPI) per un sistema in esecuzione alla velocità effettiva massima sostenibile, verrà illustrato come si è giunti alla velocità effettiva massima sostenibile di 20 messaggi al secondo per lo scenario di esempio. Si tratta di una semplice "ricerca binaria" iterativa, come indicato di seguito:

• Selezionare un punto di partenza. A meno che non si abbia già esperienza con i test delle prestazioni su BizTalk Server, sarà necessario usufruire delle informazioni disponibili su ciò che è stato ottenuto in altri sistemi.

  In questo argomento, ad esempio, sono stati indicati l'hardware, la configurazione e l'architettura della soluzione per lo scenario di esempio. Utilizzando queste indicazioni, il tipo di rilevamento attivato (impostazione predefinita + 10 proprietà + corpi dei messaggi di 10 KB) e la velocità effettiva massima sostenibile ottenuta (20 messaggi al secondo) con un periodo di mantenimento dei dati DTA di 24 ore, stabilire un confronto con la propria configurazione e le proprie esigenze.

  Così facendo dovrebbe essere almeno possibile valutare se la velocità effettiva massima sostenibile per la soluzione sarà più alta o più bassa di quella ottenuta nello scenario di esempio. Vari case study tecnici potrebbero essere disponibili anche per il quale è possibile confrontare il sistema.

• Eseguire il sistema sotto il carico MST stimato e monitorare l'indicatore KPI. In genere, iniziando con valori alti della velocità effettiva massima sostenibile prevista si può ridurre il tempo necessario a individuare la velocità effettiva massima sostenibile. Iniziando alti, si porta l'indicatore KPI alla saturazione (in particolare dell'I/O del disco) in meno tempo di quello richiesto per scoprire che si è al di sotto della velocità effettiva massima sostenibile (ovvero almeno un intero intervallo di tempo di mantenimento dei dati).

• Perfezionare la stima e la ripetizione MST. Osservando i risultati ottenuti, ridefinire la stima della velocità effettiva massima sostenibile e ripetere il test utilizzando la nuova stima.

Vedere anche

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