Condividi tramite

Ottimizzazioni generali per BizTalk Server - Parte 2

  • Articolo

Per aumentare le prestazioni BizTalk Server, è possibile usare le raccomandazioni seguenti. Le ottimizzazioni elencate in questo argomento vengono applicate dopo l'installazione e la configurazione di BizTalk Server.

Creare più host di BizTalk Server e istanze host separate per funzionalità

Gli host separati devono essere creati per l'invio, la ricezione, l'elaborazione e la funzionalità di rilevamento. La creazione di più host BizTalk offre flessibilità durante la configurazione del carico di lavoro nel gruppo BizTalk ed è il mezzo principale per distribuire l'elaborazione tra i server BizTalk in un gruppo BizTalk. Più host consentono anche di arrestare un host senza influire sugli altri host. Ad esempio, è possibile interrompere l'invio di messaggi per consentire loro di accodarsi nel database Messagebox, consentendo comunque la ricezione in ingresso dei messaggi. La separazione delle istanze host in base alle funzionalità offre anche i vantaggi seguenti:

  • Ogni istanza host ha un proprio set di risorse, ad esempio memoria, handle e thread nel pool di thread .NET.

  • Più host BizTalk ridurranno anche la contesa nelle tabelle della coda host del database Messagebox perché ogni host viene assegnato ai propri tabelle della coda di lavoro nel database Messagebox.

  • La limitazione viene implementata in BizTalk Server a livello di host. In questo modo è possibile impostare diverse caratteristiche di limitazione per ogni host.

  • La sicurezza viene implementata a livello di host; ogni host viene eseguito in un'identità di Windows discreta. Ciò consente, ad esempio, di concedere Host_A accesso a FileShare_B, senza consentire ad altri host di accedere alla condivisione file.

Nota

Sebbene siano disponibili vantaggi per la creazione di istanze host aggiuntive, esistono anche potenziali svantaggi se vengono create troppe istanze host. Ogni istanza host è un servizio Windows (BTSNTSvc.exe), che genera un carico aggiuntivo sul database MessageBox e utilizza risorse computer, ad esempio CPU, memoria, thread.

Per altre informazioni sulla modifica delle proprietà host BizTalk Server, vedere "Come modificare le proprietà host" nella guida BizTalk Server in https://go.microsoft.com/fwlink/?LinkId=101588.

Configurare un host di rilevamento dedicato

BizTalk Server è ottimizzato per la velocità effettiva, quindi i motori di orchestrazione e messaggistica principali non spostano effettivamente i messaggi direttamente nei database Di rilevamento BizTalk o BAM, in quanto ciò disverte questi motori dal proprio lavoro primario di esecuzione dei processi aziendali. Invece, BizTalk Server lascia i messaggi nel database MessageBox e li contrassegna come richiesta di uno spostamento nel database di rilevamento BizTalk. Un processo in background (l'host di rilevamento) sposta quindi i messaggi nei database Di rilevamento BizTalk e BAM. Poiché il rilevamento è un'operazione a elevato utilizzo di risorse, deve essere creato un host separato dedicato al rilevamento, riducendo al minimo l'impatto che il rilevamento ha sugli host dedicati all'elaborazione dei messaggi.

L'uso di un host di rilevamento dedicato consente inoltre di arrestare altri host BizTalk senza interferire con il rilevamento di BizTalk Server. Lo spostamento dei dati di rilevamento dal database Messagebox è fondamentale per un sistema di BizTalk Server integro. Se l'host BizTalk responsabile dello spostamento dei dati di rilevamento nel gruppo BizTalk viene arrestato, il servizio Decode dati di rilevamento non verrà eseguito. L'impatto di questa operazione è il seguente:

  • I dati di rilevamento HAT non verranno spostati dal database Messagebox al database di rilevamento BizTalk.

  • I dati di rilevamento BAM non verranno spostati dal database Messagebox al database di importazione primaria BAM.

  • Poiché i dati non vengono spostati, non possono essere eliminati dal database Messagebox.

  • Quando il servizio Di decodifica dati di rilevamento viene arrestato, gli intercettori di rilevamento vengono comunque attivati e scrivono i dati di rilevamento nel database Messagebox. Se i dati non vengono spostati, il database Messagebox verrà gonfiato, che influisce sulle prestazioni nel tempo. Anche se le proprietà personalizzate non vengono rilevate o i profili BAM non vengono configurati, per impostazione predefinita alcuni dati vengono rilevati (ad esempio la ricezione/invio di eventi di ricezione/invio di eventi di orchestrazione). Se non si vuole eseguire il servizio Di decodifica dati di rilevamento, disattivare tutto il rilevamento in modo che nessun intercettatore salva i dati nel database. Per disabilitare il rilevamento globale, vedere "Come disattivare il rilevamento globale" nella guida BizTalk Server in https://go.microsoft.com/fwlink/?LinkId=101589. Usare la console di amministrazione di BizTalk Server per disabilitare in modo selettivo gli eventi di rilevamento.

    L'host di rilevamento deve essere eseguito su almeno due computer che eseguono BizTalk Server (per la ridondanza in caso di errore). Per prestazioni ottimali, è necessario avere almeno un'istanza host di rilevamento per ogni database Messagebox. Il numero effettivo di istanze host di rilevamento deve essere (N + 1), dove N = il numero di database Messagebox. Il valore "+ 1" è destinato alla ridondanza, nel caso in cui uno dei computer che ospitano il rilevamento non riesce.

    Un'istanza host di rilevamento sposta i dati di rilevamento per database Messagebox specifici, ma non saranno mai presenti più di un'istanza host di rilevamento che sposta i dati per un database Messagebox specifico. Ad esempio, se sono presenti tre database Messagebox e solo due istanze host di rilevamento, una delle istanze host deve spostare i dati per due dei database Messagebox. L'aggiunta di una terza istanza host di rilevamento distribuisce il lavoro dell'host di rilevamento a un altro computer che esegue BizTalk Server. In questo scenario, l'aggiunta di un quarto istanza host di rilevamento non distribuisce alcun altro lavoro host di rilevamento, ma fornisce un'istanza host di rilevamento aggiuntiva per la tolleranza di errore.

    Per altre informazioni sul servizio bus di eventi BAM, vedere gli argomenti seguenti nella guida BizTalk Server:

  • "Gestione del servizio bus di eventi BAM" in https://go.microsoft.com/fwlink/?LinkId=101590.

  • "Creazione di istanze del servizio bus di eventi BAM" all'indirizzo https://go.microsoft.com/fwlink/?LinkId=101591.

Gestire ASP.NET utilizzo del thread o eseguire simultaneamente richieste per le applicazioni Web che ospitano orchestrazioni pubblicate come servizio Web o WCF

Il numero di thread di lavoro e I/O (IIS 6.0 e IIS 7.0 in modalità classica) o il numero di richieste simultanee in esecuzione (modalità integrata IIS 7.0) per un'applicazione Web ASP.NET che ospita un'orchestrazione pubblicata come servizio Web deve essere modificata in base alle condizioni seguenti:

  • L'utilizzo della CPU non è un collo di bottiglia nel server Web di hosting.

  • Il valore dei contatori delle prestazioni ASP.NET Apps v2.0.50727\Request Wait Time o ASP.NET Apps v2.0.50727\Request Execution Times è insolitamente elevato.

  • Errore simile al seguente generato nel log dell'applicazione del computer che ospita l'applicazione Web:

    Event Type: Warning
Event Source: W3SVC Event Category: None
Event ID: 1013
Date: 6/4/2009
Time: 1:03:47 PM
User: N/A
Computer: <ComputerName>
Description: A process serving application pool 'DefaultAppPool' exceeded time limits during shut down. The process id was '<xxxx>'

Gestire ASP.NET utilizzo del thread per le applicazioni Web che ospitano orchestrazioni in IIS 6.0 e in IIS 7.0 in esecuzione in modalità classica

Quando il valore autoConfig nel file machine.config di un server IIS 6.0 o un server IIS 7.0 in esecuzione in modalità classica è impostato su true, ASP.NET 2.0 gestisce il numero di thread di lavoro e thread di I/O allocati a qualsiasi processo di lavoro IIS associato:

<processModel autoConfig="true" />

Per modificare manualmente il numero di thread di lavoro e I/O per un'applicazione Web ASP.NET 2.0, aprire il file di machine.config associato e immettere nuovi valori per i parametri maxWorkerThreads e maxIoThreads :

<!-- <processModel autoConfig="true" /> -->
    <processModel maxWorkerThreads="200" maxIoThreads="200" />

Nota

Questi valori sono solo per indicazioni; assicurarsi di testare le modifiche apportate a questi parametri.

Per altre informazioni sui parametri di ottimizzazione nel file machine.config per un'applicazione Web ASP.NET 2.0, vedere l'articolo di Microsoft Knowledge Base 821268 "Contesa, prestazioni scarse e deadlock quando si effettuano richieste di servizio Web da applicazioni ASP.NET" (https://go.microsoft.com/fwlink/?LinkID=66483).

Gestire il numero di richieste simultanee in esecuzione per le applicazioni Web che ospitano orchestrazioni in IIS 7.0 in esecuzione in modalità integrata

Quando ASP.NET 2.0 è ospitato in IIS 7.0 in modalità integrata, l'uso dei thread viene gestito in modo diverso rispetto a IIS 6.0 o in IIS 7.0 in modalità classica. Quando ASP.NET 2.0 è ospitato in IIS 7.0 in modalità integrata, ASP.NET 2.0 limita il numero di richieste contemporaneamente in esecuzione anziché il numero di thread che eseguono simultaneamente le richieste. Per gli scenari sincroni, questo limiterà indirettamente il numero di thread, ma per gli scenari asincroni il numero di richieste e thread probabilmente sarà molto diverso. Quando si esegue ASP.NET 2.0 in IIS 7.0 in modalità integrata, i parametri maxWorkerThreads e maxIoThreads nel file machine.config non vengono usati per gestire il numero di thread in esecuzione. Al contrario, il numero di richieste contemporaneamente in esecuzione può essere modificato dal valore predefinito di 12 per CPU modificando il valore specificato per maxConcurrentThreadsPerCPU. Il valore maxConcurrentThreadsPerCPU può essere specificato nella riqistry o nella sezione config di un file aspnet.config. Seguire questa procedura per modificare il valore predefinito per maxConcurrentThreadsPerCPU per gestire il numero di richieste contemporaneamente in esecuzione:

Impostare il valore maxConcurrentThreadsPerCPU nel Registro di sistema

Questa impostazione è globale e non può essere modificata per singoli pool di applicazioni o applicazioni.

Avviso

L'uso dell'editor del Registro di sistema è di sola responsabilità dell'utente. L'uso errato potrebbe causare problemi che richiedono di reinstallare il sistema operativo. Per altre informazioni su come eseguire il backup, il ripristino e la modifica del Registro di sistema, vedere l'articolo di Microsoft Knowledge Base 256986 - Informazioni sul Registro di sistema di Windows per gli utenti avanzati.

  1. Dal menu Start individuare e avviare il prompt Esegui , immettere regedit.exee quindi selezionare OK per avviare l'editor del Registro di sistema.

  2. Passare a HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0

  3. Creare la chiave seguendo questa procedura:

    1. Nel menu Modifica selezionare Nuovo e quindi Chiave.

    2. Digitare maxConcurrentThreadsPerCPU e quindi premere INVIO.

    3. Nella chiave maxConcurrentThreadsPerCPU creare una voce DWORD con il nuovo valore per maxConcurrentThreadsPerCPU.

    4. Chiudere l'editor del Registro di sistema.

Impostare il valore maxConcurrentThreadsPerCPU per un pool di applicazioni nella sezione config di un file aspnet.config

  1. Scaricare e installare Microsoft .NET Framework 3.5 Service Pack 1, che è necessario per soddisfare i valori seguenti nel file di configurazione. La versione completa è disponibile anche.

  2. Aprire il file aspnet.config per il pool di applicazioni.

  3. Immettere i nuovi valori per i parametri maxConcurrentRequestsPerCPU e requestQueueLimit .

    <system.web>
    <applicationPool maxConcurrentRequestsPerCPU="12" requestQueueLimit="5000"/>
</system.web>

    Nota

    Questo valore esegue l'override del valore specificato per maxConcurrentThreadsPerCPU nel Registro di sistema. L'impostazione requestQueueLimit è uguale a processModel/requestQueueLimit, ad eccezione dell'impostazione nel file aspnet.config eseguirà l'override dell'impostazione nel file machine.config .

Definire i valori del thread di hosting CLR per le istanze host BizTalk

Poiché un thread di Windows è l'unità eseguibile più basilare disponibile per un processo di Windows, è importante allocare un numero sufficiente di thread al pool di thread .NET associato a un'istanza di un host BizTalk, per evitare l'esaurimento dei thread. Quando si verifica la starvazione del thread, non sono disponibili thread sufficienti per eseguire il lavoro richiesto che influisce negativamente sulle prestazioni. È ugualmente importante evitare di allocare più thread del necessario al pool di thread .NET associato a un host. Un'allocazione eccessiva di thread può infatti aumentare le attività di scambio del contesto, Il cambio di contesto si verifica quando il kernel di Windows passa dall'esecuzione di un thread a un thread diverso, che comporta un costo delle prestazioni. L'allocazione eccessiva del thread può causare un cambio eccessivo di contesto, che influisce negativamente sulle prestazioni complessive.

È possibile modificare il numero di thread di Windows disponibili nel pool di thread .NET associato a un'istanza di un host BizTalk creando i valori della chiave CLR Hosting appropriati nel Registro di sistema del server BizTalk Server.

Avviso

L'uso errato di Editor del Registro di sistema può causare problemi e richiedere la reinstallazione del sistema operativo. L'uso dell'editor del Registro di sistema è a rischio e pericolo dell'utente. Per altre informazioni su come eseguire il backup, il ripristino e la modifica del Registro di sistema, vedere l'articolo della Microsoft Knowledge Base "Descrizione del Registro di sistema di Microsoft Windows" all'indirizzo https://go.microsoft.com/fwlink/?LinkId=62729.

Nota

I thread di lavoro vengono usati per gestire gli elementi di lavoro in coda e i thread di I/O sono thread di callback dedicati associati a una porta di completamento di I/O per gestire una richiesta di I/O asincrona completata.

Per modificare il numero di thread disponibili nel pool di thread .NET associato a ogni istanza di un host BizTalk, attenersi alla seguente procedura:

  1. Arrestare l'istanza dell'host BizTalk.

  2. Fare clic su Start, scegliere Esegui, digitare regedit.exe, quindi fare clic su OK per avviare l'editor del Registro di sistema. Passare a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$hostname dove nome host è il nome dell'host associato all'istanza host.

    Nota

    Se è stata aggiornata l'installazione di BizTalk Server 2006 da BizTalk Server 2004, questa chiave del Registro di sistema può essere rappresentata come guidHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc in cui guid è un GUID univoco per ogni istanza di un host BizTalk Server.

  3. Individuare la chiave di hosting CLR . Se questa chiave non esiste, creare la chiave seguendo questa procedura:

    1. Scegliere Nuovo dal menu Modifica e quindi fare clic su Chiave.

    2. Digitare CLR Hosting e quindi premere INVIO.

  4. Nella chiave di hosting CLR creare le voci DWORD seguenti con i valori indicati.

    Voce DWORD Valore predefinito Valore consigliato
    MaxIOThreads 20 100
    N. maxthreaddi lavoro 25 100 Importante: l'aumento di questo valore oltre 100 può avere un effetto negativo sulle prestazioni del computer SQL Server che ospita il database MessageBox BizTalk Server. Se si verifica questo problema, SQL Server potrebbe rilevare una condizione di blocco critico (deadlock). È consigliabile che questo parametro non venga aumentato oltre il valore 100.
    MinIOThreads 1 25
    MinWorkerThreads 1 25

    Nota

    Questi valori consigliati saranno sufficienti per la maggior parte degli scenari, ma potrebbe essere necessario aumentare a seconda del numero di gestori di adapter o orchestrazioni in esecuzione in ogni istanza host.

    Nota

    Questi valori vengono moltiplicati in modo implicito per il numero di processori nel server. Ad esempio, l'impostazione della voce MaxWorkerThreads su un valore pari a 100 imposterebbe in modo efficace un valore pari a 400 in un server CPU 4.

  5. Chiudere l'editor del Registro di sistema.

  6. Riavviare l'istanza dell'host BizTalk.

Disabilitare il rilevamento per orchestrazioni, porte di trasmissione, porte di ricezione e pipeline quando il rilevamento non è necessario

Il rilevamento comporta un sovraccarico delle prestazioni all'interno di BizTalk Server perché i dati devono essere scritti nel database MessageBox e quindi spostati in modo asincrono nel database di rilevamento BizTalk. Se il rilevamento non è un requisito aziendale, disabilitare il rilevamento per ridurre il sovraccarico e aumentare le prestazioni. Per altre informazioni sulla configurazione del rilevamento, vedere "Configuring Tracking Using the BizTalk Server Administration Console" (Configurazione del rilevamento tramite la console di amministrazione di BizTalk Server) nella Guida di BizTalk Server all'indirizzo https://go.microsoft.com/fwlink/?LinkID=106742.

Ridurre il periodo di eliminazione per il processo di eliminazione e archiviazione DTA da 7 giorni a 2 giorni in scenari con velocità effettiva elevata

Per impostazione predefinita, l'intervallo di eliminazione per i dati di rilevamento in BizTalk Server è impostato su 7 giorni. In uno scenario con velocità effettiva elevata, ciò può comportare un'eccessiva compilazione di dati nel database di rilevamento, che alla fine influirà sulle prestazioni di MessageBox e a sua volta influisce negativamente sulla velocità effettiva di elaborazione dei messaggi.

Negli scenari con velocità effettiva elevata, ridurre l'intervallo di eliminazione flessibile e rigido dal valore predefinito di 7 giorni a 2 giorni. Per altre informazioni sulla configurazione dell'intervallo di eliminazione, vedere "Come configurare il processo di eliminazione e archiviazione DTA" nella Guida di BizTalk Server all'indirizzo https://go.microsoft.com/fwlink/?LinkID=104908.

Installare i Service Pack più recenti

È necessario installare i Service Pack più recenti per BizTalk Server e .NET Framework, in quanto contengono correzioni che possono risolvere i problemi di prestazioni che possono verificarsi.

Non raggruppare gli host BizTalk a meno che non sia assolutamente necessario

Anche se BizTalk Server 2006 e le versioni successive di BizTalk Server consentono di configurare un host BizTalk come risorsa cluster, è consigliabile eseguire questa operazione solo se è necessario fornire disponibilità elevata a una risorsa che non può essere ospitata in più computer BizTalk. Ad esempio, le porte che usano l'adattatore FTP devono risiedere solo in un'istanza host, poiché il protocollo FTP non fornisce il blocco dei file, tuttavia, introduce un singolo punto di errore che trarrà vantaggio dal clustering. Gli host che contengono adattatori, ad esempio file, SQL, HTTP o solo host di elaborazione, possono essere internamente bilanciati tra computer e non traggono vantaggio dal clustering.

Ottimizzazioni delle prestazioni nella documentazione di BizTalk Server

Applicare le raccomandazioni seguenti dalla documentazione di BizTalk Server in base alle esigenze: