Fase 1: Definizione dell'ambito della valutazione

Questo argomento descrive gli aspetti della fase di ambito di una valutazione delle prestazioni BizTalk Server.

Un errore comune quando si impegna in una valutazione delle prestazioni è quello di sottovalutare l'ambito della valutazione delle prestazioni. Se le risorse e il tempo sufficienti non vengono allocati in anticipo, il team responsabile della valutazione delle prestazioni non sarà in grado di completare tutte le attività necessarie per compilare e testare un ambiente di produzione complesso. Il team che lavora alla valutazione delle prestazioni deve scegliere attentamente le loro battaglie. La maggior parte delle valutazioni delle prestazioni viene eseguita entro un intervallo di tempo molto limitato e quindi il team deve identificare e concentrarsi su uno o due, forse tre al massimo, obiettivi chiave delle prestazioni. L'applicazione da testare deve essere sviluppata specificamente per concentrarsi sugli obiettivi di prestazioni identificati e deve considerare tutte le altre variabili tecnologiche il più possibile. Questo argomento descrive gli aspetti della fase di ambito di una valutazione delle prestazioni BizTalk Server.

Considerazioni prima di iniziare la valutazione delle prestazioni

Prima di eseguire altre operazioni per una valutazione delle prestazioni, è necessario considerare i fattori seguenti. Questi fattori aiuteranno a decidere la direzione generale della fase di ambito e sono un buon punto di partenza per una valutazione delle prestazioni.

Caricamento messaggi

È importante considerare fin dall'inizio come si replica il carico dei messaggi che verrà effettivamente sottoposto al sistema di produzione. Ad esempio, se nell'ambiente di produzione il 20% dei messaggi sarà <di dimensioni pari a 20 KB, il 50% sarà <di dimensioni pari a 100 KB e il 30% rimanente potrebbe essere di dimensioni fino a 1 MB, è importante che venga replicato nel lab.

Sviluppare un breve dettaglio degli scenari da testare

Dopo aver identificato i test case che verranno testati, è importante identificare i componenti principali coinvolti in tali test. Sono inclusi sia i componenti BizTalk Server (ad esempio la messaggistica e le orchestrazioni) che altri componenti, tra cui tecnologie di terze parti, ad esempio MQSeries o SAP. È molto importante essere consapevoli di tutti questi aspetti fin dall'inizio, perché ti aiuterà a valutare la complessità del lab e ti permetterà di pianificare le competenze tecniche necessarie durante l'impegno.

Identificare quali adattatori verranno usati

È fondamentale che il lab di valutazione delle prestazioni usi gli adattatori effettivi che verranno usati nell'ambiente di produzione. Se non si usano gli adattatori effettivi usati nell'ambiente di produzione, si verificano problemi perché le prestazioni di schede diverse variano in modo significativo. Ad esempio, l'adattatore file è uno degli adattatori BizTalk Server più veloci, ma non dispone di alcune delle funzionalità necessarie per alcuni sistemi, in particolare l'adattatore file non fornisce supporto per le transazioni. Il supporto delle transazioni consente di leggere i messaggi e scriverli nel database MessageBox, tutto all'interno del contesto di una transazione MSDTC. Il supporto delle transazioni comporta un sovraccarico. Pertanto, l'uso dell'adattatore file per simulare uno scenario di produzione che richiede il supporto delle transazioni non sarebbe un confronto fattibile. In questo scenario i risultati delle prestazioni sono essenzialmente non validi perché è molto improbabile che riflettano le prestazioni effettive del sistema di produzione.

Stimare il tempo necessario per la valutazione delle prestazioni

Usare le linee guida seguenti per stimare il tempo necessario per la valutazione delle prestazioni:

• Allocare due settimane di tempo di preparazione per la configurazione dell'ambiente di test. Una settimana verrà usata per compilare l'infrastruttura, i componenti software necessari e applicare gli aggiornamenti software. La seconda settimana sarà dedicata alla configurazione dell'ambiente specifico che duplica l'ambiente di produzione BizTalk Server.

• Allocare una settimana aggiuntiva per ogni test case che verrà analizzato durante la valutazione delle prestazioni.

• Allocare una settimana alla fine della valutazione effettiva delle prestazioni per documentare i risultati della valutazione delle prestazioni.

  Pertanto, per una valutazione delle prestazioni tipica con due test case, il tempo stimato per completare la valutazione sarà:

  (due settimane di tempo di preparazione) + (due settimane per la valutazione effettiva delle prestazioni) + (una settimana per documentare i risultati) = cinque settimane totali.

Documentare la valutazione delle prestazioni

Nell'ambito della valutazione delle prestazioni, i dettagli della valutazione devono essere documentati in un riepilogo dell'impegno. Questo documento deve definire chiaramente obiettivi e obiettivi, stakeholder e attività cardine per la valutazione delle prestazioni. Questo documento fungerà da roadmap per la valutazione delle prestazioni, aiuta a garantire che tutti gli stakeholder siano d'accordo sui dettagli sull'impegno e serviranno a garantire che la valutazione delle prestazioni rimanga traccia. Questo documento deve essere aggiornato in tutta la valutazione delle prestazioni e include un riepilogo dei risultati alla conclusione della valutazione delle prestazioni.

Obiettivi e obiettivi

Definire attentamente gli obiettivi di velocità effettiva e latenza : quali criteri di prestazioni si sta tentando di ottimizzare? In genere, una o più delle misure di prestazioni seguenti sono l'obiettivo di una valutazione delle prestazioni BizTalk Server.

• Velocità effettiva : in genere misurata come numero di messaggi per unità di tempo che possono essere elaborati in un intervallo di tempo specificato. Ad esempio, un obiettivo di velocità effettiva può essere definito come la possibilità di elaborare 100 messaggi al secondo per un periodo di 3 ore.

• Latenza : in genere definita come percentuale di tutti i messaggi che possono essere elaborati end-to-end entro un determinato intervallo di tempo, ad esempio:

  • Il 95% di tutti i messaggi deve essere elaborato end-to-end entro due secondi.

  • Il 100% di tutti i messaggi deve essere elaborato end-to-end entro quattro secondi.

• Picchi di carico

• Tempo necessario per completare un batch diX

• Scenari di ripristino floodgate

• Architettura di alto livello, tra cui hardware e software

  Gli obiettivi di prestazioni devono essere misurati in termini di "raggiungere il massimo possibile X dato vincoli hardware e software". Determinare in anticipo come verrà misurato l'obiettivo. Ad esempio, "Velocità effettiva massima sostenibile di X end-to-end misurata dal contatore "XLang/s\orchestrations completed /second".

Le prestazioni desiderate sono raggiungibili?

Quando si valutano le considerazioni sulle prestazioni, è prima necessario determinare se le risorse hardware disponibili saranno sufficienti per soddisfare gli obiettivi di prestazioni. In alcuni casi, le prestazioni desiderate non sono semplicemente possibili senza investimenti aggiuntivi nell'hardware. Non esiste una formula magica che può essere usata per determinare quali prestazioni è o non è possibile, data una configurazione hardware specifica, il numero di fattori che influiscono sulle prestazioni della soluzione, tra cui la complessità delle orchestrazioni, il codice personalizzato usato, il numero di volte in cui i messaggi vengono salvati in modo permanente nel database MessageBox e limitazioni dei sistemi esterni. La tabella seguente fornisce un riepilogo dell'hardware usato per raggiungere obiettivi di prestazioni specifici per determinati scenari.

Scenari hardware di esempio

Dopo aver ritenuto sufficiente l'infrastruttura hardware disponibile per ottenere le prestazioni desiderate, considerare quanto segue quando si definisce un BizTalk Server valutazione delle prestazioni:

• Quali adattatori e/o acceleratori sono necessari?

• Quali sono i requisiti per l'implementazione di orchestrazioni nella soluzione?

• Requisiti di velocità effettiva dei documenti: quali sono i requisiti massimi per la velocità effettiva sostenibile per la soluzione?

• Requisiti di latenza: quanto risponde la soluzione deve essere per gli scenari solicit-response e request-response?

• In che modo la soluzione viene recuperata da periodi di picco di caricamento dei documenti?

• Quali sono i requisiti di disponibilità elevata della soluzione?

• Quali sono i requisiti di rilevamento dei documenti della soluzione?

• Quali sono le caratteristiche delle prestazioni di qualsiasi applicazione dipendente, ad esempio un servizio Web remoto o un altro sistema? Se le applicazioni dipendenti non mantengono il carico richiesto, le prestazioni complessive del sistema verranno ridotte di conseguenza.

Informazioni hardware da considerare durante la fase di ambito

Quando si definisce l'ambito della soluzione, creare un diagramma hardware di alto livello che includa quanto segue:

• Architettura computer (ad esempio x86, x64 e IA64)

• Requisiti della CPU (ad esempio tipo, velocità, numero, core e uso dell'hyperthreading)

• Requisiti della RAM per ogni computer

• Archiviazione su disco locale (tipo, dimensioni, velocità)

• SAN (requisiti di archiviazione: numero di LUNS; Tipo di scheda SAN)

• Schede di rete (numero in ogni computer, 100 megabit al secondo (Mbps) rispetto a 1 gigabit al secondo (1 Gbps).

• Come verranno distribuiti i firewall nella soluzione?

• Verrà usato l'hardware di bilanciamento del carico di rete?

• I computer specifici devono essere raggruppati?

Informazioni software da considerare durante la fase di ambito

Altrettanto importante quanto le informazioni hardware sono lo stack software che verrà usato durante la valutazione delle prestazioni. È necessario assicurarsi di documentare le informazioni seguenti:

• Sistema operativo per ogni computer ( 32 o 64 bit, in cluster o meno).

• Software server da installare in ogni computer.

• Software di virtualizzazione usato.

• Funzionalità software specifiche in genere non installate, ad esempio correzioni di rollup COM+ o correzioni host SQL Server necessarie.

Determinare se le modifiche al codice rientrano nell'ambito della valutazione delle prestazioni

Questo è uno degli aspetti più importanti da determinare durante il processo di definizione dell'ambito. BizTalk Server e i componenti sottostanti usati (SQL Server, Windows, IIS e molti altri) possono essere ottimizzati usando le tecniche di ottimizzazione e le modifiche alla configurazione descritte in questa guida. Tuttavia, se un'applicazione non è stata sviluppata per prestazioni ottimali, può ostacolare questi miglioramenti delle prestazioni. Pertanto, le modifiche al codice devono essere rimosse solo dall'ambito se si è certi che sia stata completata una revisione completa del codice prima che l'applicazione entri nel lab. Se necessario, è possibile accettare che siano consentite solo determinate modifiche, ad esempio la rimozione di punti di persistenza all'interno di orchestrazioni.

Ruoli e responsabilità

Una delle aree più importanti dell'esecuzione di una valutazione delle prestazioni consiste nel garantire che i ruoli e le responsabilità siano chiaramente assegnati. All'inizio della valutazione delle prestazioni devono essere assegnati i seguenti ruoli chiave:

• Lead engagement : il lead di engagement è responsabile del proprietario dell'impegno complessivo end-to-end. Questo ruolo viene in genere eseguito da un consulente senior o architetto. Idealmente questa persona dovrebbe avere esperienza nell'ottimizzazione dei sistemi basati su BizTalk Server. È auspicabile conoscere SQL Server e qualsiasi altra tecnologia, incluse quelle di terze parti. Si prega di notare che non è necessario che il responsabile sia un esperto in tutte le aree, ma hanno bisogno di avere almeno una conoscenza funzionante della tecnologia per poter lavorare con gli specialisti in tali aree e comprendere le ottimizzazioni che stanno applicando.

• Progettazione test : è necessario disporre di un utente dedicato alla progettazione e all'implementazione dei test che verranno eseguiti durante il lab. Ciò comporterà la decisione sul framework di test che verrà usato per creare test, testando ognuno dei test per assicurarsi che soddisfi i requisiti del lab e assicurandosi che i responsabili dell'esecuzione dei test siano consapevoli di come usare il client.

• Proprietario dell'ambiente: la presenza di un ambiente rappresentativo all'interno del lab che riflette in modo accurato l'ambiente di produzione BizTalk Server è fondamentale. La persona che esegue questo ruolo sarà responsabile del controllo di ogni elemento dello stack di software e hardware usato e convalidando che non vi siano differenze significative. Ad esempio, SQL Server 2008 R2 durante l'esecuzione nella piattaforma a 32 bit può indirizzare solo 4 GB di memoria fisica senza usare estensioni di indirizzi fisici (PAE) o estensioni di windowing degli indirizzi (AWE). In SQL Server 2008 R2, è possibile risolvere il problema a 64 bit fino a 1 terabyte di memoria(si tratta della memoria fisica massima corrente supportata da Windows Server 2008 R2). Di conseguenza, una differenza significativa tra il cliente e l'ambiente lab è l'architettura della CPU usata da BizTalk Server e SQL Server. Oltre a questi fattori ovvi, altri fattori meno evidenti, ad esempio i livelli del Service Pack e gli hotfix installati, possono influire sulle prestazioni dell'ambiente.

• Responsabile dell'ambiente di compilazione: dopo aver elaborato una specifica dettagliata per la valutazione delle prestazioni, a un utente deve essere assegnata la responsabilità di creare l'ambiente. Questo includerà lo stack hardware e software. In molti casi un individuo sarà responsabile di questo (spesso è il proprietario dell'ambiente). Tuttavia, in un'azienda di grandi dimensioni, il proprietario dell'ambiente potrebbe dover essere il collegamento tra team diversi, ognuno dei quali può essere responsabile di vari componenti della soluzione. Ad esempio, un team può essere responsabile della compilazione di Windows, un altro per SQL Server e un altro team per BizTalk Server.

• Responsabile della distribuzione: è necessario avere un utente responsabile della corretta distribuzione dell'applicazione in BizTalk Server, che le associazioni corrette siano configurate e che venga applicata qualsiasi configurazione personalizzata. Questo ruolo richiederà una conoscenza approfondita della soluzione e richiederà la conoscenza per creare un pacchetto di un'applicazione e distribuire un'applicazione e quindi verificare che si tratti di uno stato funzionante all'interno dell'ambiente lab.

• Specialisti del prodotto : è importante identificare quali specialisti del prodotto sono necessari per la valutazione delle prestazioni. Le competenze esatte necessarie dipendono dalla progettazione e dallo scopo dell'applicazione BizTalk Server.

  Una delle competenze più comuni richieste dallo specialista del prodotto è una conoscenza approfondita dell'ottimizzazione delle prestazioni SQL Server. Queste competenze sono necessarie per due scopi: in primo luogo, è spesso necessario eseguire SQL Server ottimizzazioni per ottimizzare le prestazioni dei database BizTalk e la seconda, molte soluzioni BizTalk usano database personalizzati. L'uso di database personalizzati può diventare un collo di bottiglia nella soluzione se le ottimizzazioni corrette non vengono applicate all'ambiente SQL Server. Per identificare e applicare le ottimizzazioni del database appropriate, sono in genere necessarie le seguenti SQL Server competenze:

  • Conoscenza approfondita del codice di SQL Server stored procedure, inclusa la possibilità di ottimizzare le stored procedure esistenti.

  • Possibilità di identificare e compilare indici di database mancanti.

  • Possibilità di scrivere script per suddividere i database in più file.

    Nota

    Per altre informazioni sull'applicazione di questa ottimizzazione, vedere Ottimizzazione dei filegroup per database2.

  • Possibilità di identificare i problemi di prestazioni usando i report del dashboard prestazioni di SQL Server 2008 R2.

    Per ogni tecnologia specializzata coinvolta nella valutazione delle prestazioni, è necessario definire un elenco di requisiti come indicato sopra per SQL Server. Ciò garantisce che la risorsa ottenuta abbia aspettative chiare su ciò che sarà necessario. Un'altra tecnologia che richiede spesso conoscenze specializzate durante la valutazione delle prestazioni è IBM Websphere MQ. L'elenco seguente illustra le specifiche dei requisiti per uno specialista di prodotti IBM WebSphere MQ:

  • Esperienza nel monitoraggio, manutenzione e personalizzazione di MQSeries.

  • Esperienza con l'installazione e la migrazione di nuove versioni di MQSeries.

  • Possibilità di analizzare e ottimizzare le prestazioni di MQSeries.

  • Eseguire l'analisi dei problemi MQSeries.

  • Conoscenza dei processi e delle procedure correlati alla sicurezza, all'amministrazione, al ripristino e all'automazione di MQSeries.

• Responsabile della documentazione : l'aggiornamento continuo della documentazione del lab end-to-end nell'intera valutazione delle prestazioni è fondamentale. Il successo complessivo di un impegno del lab non deve essere valutato fino a quando le ottimizzazioni non sono state applicate correttamente nell'ambiente di produzione e il sistema ha ottenuto il livello di prestazioni desiderato. A tale scopo, è essenziale conservare un record dettagliato delle informazioni seguenti:

  • Riepilogo dei risultati generali del lab

  • Problemi irrisolti

  • Problemi risolti

  • Sequenza temporale per il lab

  • Stato del lab

  • Implementazione delle ottimizzazioni per categoria

  • Implementazione delle ottimizzazioni in ordine cronologico (per assicurarsi che possano essere applicate nello stesso ordine nel sistema di produzione)

  • Diagramma dell'architettura generale

  • Dettagli degli scenari da testare

  • Tecnologie di terze parti coinvolte

  • Diagramma hardware del lab

  • Elenco contatti

  • Inventario hardware dettagliato

  • Appendice con risultati completi dettagliati

• Sviluppatore: l'eventuale necessità di uno sviluppatore dipende molto dall'ambito dell'impegno. Se la codebase è stata bloccata e il lab è disponibile per testare l'infrastruttura e le ottimizzazioni della piattaforma, non è necessario che i servizi di uno sviluppatore siano necessari. Questo tipo di scenario può verificarsi quando i test delle prestazioni vengono eseguiti subito prima della data "go-live" del server di produzione. A questo scopo, il codice dovrebbe essere stato bloccato e i test di regressione completi devono essere completati o in corso. Eventuali modifiche al codice introdotte nel lab potrebbero introdurre una regressione e pertanto introdurre rischi per il sistema di produzione. Se sono consentite modifiche al codice, in genere sarà necessario uno sviluppatore. L'elenco seguente rappresenta le competenze in genere richieste da uno sviluppatore impegnato in una valutazione delle prestazioni BizTalk Server:

  • Possibilità di identificare e risolvere i problemi di prestazioni con le orchestrazioni

  • Possibilità di identificare e risolvere i problemi di prestazioni con le pipeline

  • Familiarità con .NET, tra cui:

    • Libreria aziendale

    • Esperienza del profiler F1 in Visual Studio

    • Microsoft Visual Studio 2010 Ultimate o Visual Studio Test Professional 2010

• Test lead : garantire che sia fondamentale ottenere un set accurato, completo e accurato di risultati. Il responsabile del test è responsabile di garantire che le informazioni necessarie vengano acquisite, analizzate in modo appropriato e distribuite in modo appropriato dopo ogni esecuzione del test. È importante considerare come acquisire i dati, in genere i dati di test sono adatti per la presentazione usando un foglio di calcolo di Excel. L'elenco seguente illustra i dati che devono essere acquisiti per ogni test eseguito durante il lab:

  • Numero di esecuzione del test

  • Data

  • Totale messaggi elaborati

  • Messaggi elaborati al secondo

  • Ora di inizio

  • Ora arrestata

  • Durata dei test in minuti

  • Messaggi sospesi/Totale messaggi elaborati: può essere acquisito dalla console di amministrazione BizTalk o misurando i contatori delle prestazioni BizTalk Server usando Monitor prestazioni.

  • Numero di messaggi che hanno avuto esito negativo nell'elaborazione

  • # o messaggio che sono stati elaborati correttamente

  • Testare le risposte del client

  • Durata del processo client, misurata in secondi: in genere questo valore viene misurato quando si implementa una soluzione di messaggistica sincrona con BizTalk Server, in questo caso è importante conoscere il valore per la durata media del client, in quanto questo è in genere rappresentativo della durata media di un utente finale in attesa di una risposta dalla soluzione.

  • Valore massimo della durata del processo client, misurato in secondi

  • Valore minimo della durata del processo client, misurato in secondi

  • BizTalk Server latenza di richiesta/risposta, misurata in secondi

  • Orchestrazioni completate al secondo

  • % dei messaggi elaborati in tempo

  • Valore della variabile TestResultsLocation usata dagli strumenti di test di Visual Studio Team System.

  • Valore della variabile TestResultsLocation usata da BizUnit.

  • Eventuali commenti o raccomandazioni

    Oltre a raccogliere i risultati, il responsabile del test deve assicurarsi che monitori ogni esecuzione del test per verificare se sono presenti tendenze. I miglioramenti delle prestazioni devono essere comunicati al resto del team e devono indicare la quantità di prestazioni migliorata e quale ottimizzazione è stata applicata per ottenere il miglioramento. Alla fine del giorno è importante che il responsabile del test fornisca un riepilogo dei test eseguiti nel lab. Ciò consente agli stakeholder di essere informati dello stato di avanzamento continuo del lab. La tabella seguente illustra come queste informazioni possono essere raggruppate in un messaggio di posta elettronica di aggiornamento di esempio:

  Riepilogo dei risultati dei test

  Stato	Velocità effettiva	Latenza media	%< 2 secondi	Numero di esecuzioni di test	Numero di computer BizTalk Server	Numero di messaggi	Dimensioni medie dei messaggi	Durata
  Aumentare il numero di istanze	140 messaggi al secondo	0,777 secondi	99.3%	2	6	270,000	609 byte	30 minuti
  Ottimale	50 messaggi al secondo	1,12 secondi	99.12%	17	2	360,000	609 byte	2 ore
  Di base	30 messaggi al secondo	1,52 secondi	92.9 %	4	2	36,000	609 byte	20 minuti
  Obiettivi	5 messaggi al secondo	< 2 secondi	90%	-	2	-	-	-

Definire tutti i risultati finali necessari all'inizio della valutazione delle prestazioni

È importante concordare i risultati finali che devono essere applicati prima di intraprendere una valutazione delle prestazioni BizTalk Server. La sezione seguente descrive i risultati finali che devono essere applicati all'inizio della valutazione delle prestazioni.

• Applicazione da testare: l'applicazione completa che verrà usata durante la valutazione delle prestazioni deve essere disponibile. È importante che l'applicazione sia in uno stato completamente funzionante prima di iniziare la valutazione delle prestazioni, altrimenti si rischia di perdere tempo prezioso per i test del lab.

• Pianificazione della compilazione e della distribuzione automatizzata: prima di intraprendere la valutazione delle prestazioni, è necessario sviluppare un processo di compilazione e distribuzione automatizzato per testare la soluzione BizTalk Server. L'automazione del processo di compilazione per un'applicazione consente di eseguire un processo di compilazione quotidiano continuo, che può quindi essere accompagnato da un set di test di convalida della compilazione (BVT) che testano i flussi funzionali attraverso il sistema. In questo modo è possibile rilevare i problemi funzionali e di compilazione più rapidi e più semplici durante tutto il ciclo di vita dello sviluppo. All'interno del lab, ciò significa che, se sono necessarie modifiche al codice, è possibile verificare rapidamente che la soluzione aggiornata funzioni senza problemi. La compilazione manuale, la distribuzione e la configurazione di un'applicazione per un lab per le prestazioni possono essere un'attività noiosa e soggetta a errori. È quindi consigliabile usare una tecnica di automazione per eseguire le attività di compilazione e distribuzione seguenti:

  • Ottenere il codice più recente dal controllo del codice sorgente.

  • Compilare la soluzione completa.

  • Distribuire la soluzione nell'ambiente.

  • Creare applicazioni BizTalk.

  • Aggiungere BizTalk Server risorse, ad esempio .dll file e associazioni alle applicazioni BizTalk.

  • Importare il file di associazione per creare porte e associarsi alle orchestrazioni.

  • Esportare le applicazioni BizTalk come pacchetto di Microsoft® Windows® Installer in modo che possa essere distribuito nell'ambiente di test o di produzione.

  Nota

  Per altre informazioni sull'implementazione di un processo di compilazione automatizzato, vedereAutomazione del processo di compilazione

  MSBuild è stato introdotto con .NET Framework 2.0 per consentire agli sviluppatori di automatizzare attività come quelle descritte in precedenza. Diverse attività MSBuild specifiche di BizTalk Server sono incluse nella libreria Attività SDC, disponibile per il download da https://go.microsoft.com/fwlink/?LinkId=119288.

• Dati di test da usare durante la valutazione delle prestazioni: i dati di test usati hanno una notevole influenza sull'efficacia complessiva e sul successo di una valutazione delle prestazioni. Si consideri lo scenario in cui un'applicazione BizTalk Server usa la messaggistica, l'orchestrazione e il motore regole. Il motore regole viene chiamato dall'interno di un componente della pipeline sul lato ricezione per determinare quale orchestrazione verrà usata per elaborare il messaggio; e viene chiamato anche dall'interno dell'orchestrazione in vari punti per determinare il flusso. Il motore regole implementa la memorizzazione nella cache in modo che l'esecuzione dei criteri delle regole sia ottimizzata. Pertanto, se un singolo messaggio viene usato come dati di test durante la valutazione delle prestazioni, i risultati dei test possono essere asimmetrici (a causa della memorizzazione nella cache) e si possono ottenere risultati che non possono essere replicati nell'ambiente di produzione.

  Idealmente, i dati di test usati durante la valutazione delle prestazioni devono essere dati di produzione effettivi o un subset di dati di produzione. I dati di test devono anche simulare il carico e il modello di traffico che verranno trasmessi attraverso il sistema di produzione. Quando si definiscono i requisiti per i dati di test, considerare i fattori seguenti:

  • Numero di messaggi che verranno trasmessi attraverso il sistema in un determinato periodo : questo viene in genere espresso come messaggi al secondo o messaggi all'ora.

  • Tipi di messaggi : i messaggi sono file flat, XML o binari?

  • Distribuzione dei messaggi : quale percentuale sarà il file flat, quale percentuale di ogni tipo di messaggio XML verrà usata?

  • Requisiti di elaborazione del carico di picco : in molti scenari un interscambio di grandi dimensioni può essere elaborato durante le ore non di punta. Ad esempio, una grande quantità di pagamenti può essere registrata nei sistemi di una banca a mezzanotte. In questo caso, assicurarsi di poter eseguire la replica durante il test.

  • Endpoint usati per ricevere/inviare messaggi : in molti ambienti sono configurati percorsi di ricezione separati per ricevere diversi tipi di messaggi. Ad esempio, i messaggi di file flat possono essere ricevuti utilizzando l'adattatore File o l'adapter MQSeries può essere usato per ricevere messaggi XML. Anche se tutti i messaggi possono essere elaborati dalle stesse orchestrazioni, avranno punti di ingresso diversi nel sistema. Ognuna di queste diverse posizioni di ricezione può essere ospitata in un host separato; in effetti questa operazione migliorerà spesso le prestazioni complessive del sistema.

    La tabella seguente fornisce un esempio delle informazioni che devono essere acquisite durante la determinazione delle specifiche dei dati di test:

  Specifica dei dati di test di esempio

L'inserimento delle informazioni in una tabella consente di eseguire diverse operazioni. Prima di tutto, rende più semplice per gli stakeholder concordare i presupposti fatti sui dati di test. In secondo luogo, fornisce informazioni che possono essere usate per decidere le potenziali ottimizzazioni per la valutazione delle prestazioni. Nella tabella precedente, ad esempio, è possibile notare che tutti i percorsi di ricezione usati per elaborare tutti i tipi di dati diversi sono ospitati nell'host BizTalk ReceiveHost. Ciò significa che ogni istanza di questo host sarà responsabile dell'elaborazione di diversi tipi e dimensioni dei dati (ad esempio, dati PDF xml e binari non compressi). Dato che ogni istanza host è una singola istanza del processo di BizTalk Server (BTSNTSVC.EXE), questo potrebbe diventare un collo di bottiglia di elaborazione. Pertanto, in questo scenario un'ottimizzazione immediatamente ovvia per l'ambiente consiste nel testare il miglioramento delle prestazioni della separazione di ogni posizione di ricezione in un singolo host. L'accesso alle informazioni sui dati di test in un formato tabulare di riepilogo semplifica il misuratore di semplici ottimizzazioni, ad esempio questa.

• Pianificazione dei test di carico automatizzati e generazione del carico : dopo aver stabilito il profilo dei dati di test per la valutazione delle prestazioni, è importante considerare come eseguire test di carico all'interno dell'ambiente. Per BizTalk Server test di carico 2010 è stato usato Visual Studio 2010. Per altre informazioni su come facilitare i test di carico con Visual Studio 2010, vedere Uso di Visual Studio per facilitare i test automatizzati.

Vedere anche

Fasi di un processo di valutazione delle prestazioni