Condividi tramite

Linee guida per evitare colli di bottiglia

  • Articolo

Mentre le impostazioni predefinite in BizTalk Server offrono prestazioni ottimali per molte configurazioni hardware e software, in alcuni scenari può essere utile modificare le impostazioni o la configurazione della distribuzione. Quando si configura BizTalk Server, prendere in considerazione le linee guida per le prestazioni seguenti:

  • Per impedire la contesa di risorse, isolare la ricezione, l'orchestrazione e la trasmissione su host separati. Per ridurre ulteriormente il rischio di contese, isolare il servizio di rilevamento da altri host.

  • Se l'elaborazione della CPU su BizTalk Server costituisce un collo di bottiglia, scalare in verticale BizTalk Server includendo CPU aggiuntive o eseguendo l'aggiornamento a CPU più veloci.

Linee guida per SQL Server

Considerare le linee guida sulle prestazioni seguenti durante la configurazione di Microsoft SQL Server con BizTalk Server:

  • BizTalk Server database devono essere configurati per l'esecuzione in un'istanza di SQL Server dedicata ogni volta che è possibile. BizTalk Server è un'applicazione a elevato utilizzo di database, quindi la separazione dei computer di BizTalk Server e dei computer SQL Server che ospitano i database BizTalk Server migliorano le prestazioni e devono essere considerate una procedura consigliata in una produzione BizTalk Server ambiente.

  • Se possibile, utilizzare un sottosistema di dischi veloce con SQL Server. Utilizzare la tecnologia RAID5/10 (Redundant Array of Independent Disks type 5) o SAN (Storage Area Network) con alimentazione di backup.

  • Utilizzare il processo di ripristino di emergenza di SQL Server per eseguire regolarmente il backup dei database. Il servizio BizTalk Server è in ripristinare automaticamente il normale funzionamento in seguito ad errori nella connessione a SQL Server.

  • Isolare ogni MessageBox in un server diverso dal database di rilevamento BizTalk (BizTalkDTADb). Per distribuzioni più piccole, se sono disponibili risorse CPU, può essere sufficiente isolare ogni MessageBox in un disco fisico diverso dal database BizTalkDTADb.

  • Il MessageBox primario può costituire il collo di bottiglia a causa della saturazione del processore CPU o della latenza da operazioni su disco (lunghezza media della coda del disco). Se il collo di bottiglia è causato dall'elaborazione della CPU, aggiungere processori CPU al MessageBox primario. In caso contrario, provare a disabilitare la pubblicazione sul MessageBox master. In questo modo il MessageBox master potrà gestire in modo più efficiente il routing dei messaggi ad altri database MessageBox.

  • Se il collo di bottiglia è costituito dalle operazioni del disco, spostare il database BizTalkDTADb in un computer SQL Server dedicato e/o in un disco dedicato. Se l'elaborazione della CPU e le operazioni del disco nel MessageBox primario non costituiscono il collo di bottiglia, è possibile creare nuovi database MessageBox nello stesso computer SQL Server per usufruire dell'hardware esistente.

  • Per isolare i file registro di transazioni e di dati per i database MessageBox e BizTalkDTADb in dischi fisici diversi, attenersi alle procedure consigliate per SQL Server.

  • Allocare spazio di archiviazione sufficiente per i dati e i file di registro, in caso contrario SQL Server utilizzerà automaticamente tutto lo spazio disponibile sui dischi in cui sono conservati i file registro. Le dimensioni iniziali dei file di registro dipenderà dai requisiti specifici dello scenario. Eseguire una stima delle dimensioni medie dei file nella distribuzione in base ai risultati del test ed espandere lo spazio di archiviazione prima di implementare la soluzione.

  • Allocare spazio di archiviazione sufficiente per i database con utilizzo elevato dei dischi, ad esempio i database MessageBox, di rilevamento e Monitoraggio attività di business (BAM). Se la soluzione si avvale del protocollo di messaggistica di BizTalk Framework, allocare spazio di archiviazione sufficiente per il database di configurazione BizTalk (BizTalkMgmtDb).

  • In base alle esigenze aziendali [periodo di mantenimento dati] e al volume dei dati elaborati nello scenario specifico, configurare i processi Archive/Purge nel database di rilevamento in modo che il database BizTalkDTADb non raggiunga dimensioni eccessive. L'aumento delle dimensioni di questo database può infatti incidere sulle prestazioni (specialmente quando un database BizTalkDTADb supporta più MessageBox) poiché il raggiungimento della capacità massima del database impone un limite alla velocità di inserimento dei dati.

  • Scalare in verticale i server che ospitano i database MessageBox e BizTalkDTADb se costituiscono il collo di bottiglia. È possibile scalare in verticale l'hardware aggiungendo CPU, aggiungendo memoria, eseguendo l'aggiornamento a CPU più veloci o utilizzando dischi dedicati di velocità elevata.