Condividi tramite

Ottimizzazioni generali per BizTalk Server - Parte 1

  • 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.

Configurare MSDTC

Per facilitare le transazioni tra SQL Server e BizTalk Server, è necessario abilitare Microsoft Distributed Transaction Coordinator (MS DTC). Per configurare MSDTC in BizTalk Server, vedere l'argomento Linee guida generali per migliorare le prestazioni del sistema operativo.

Raccomandazioni per la configurazione di host BizTalk Server

In questa sezione vengono fornite raccomandazioni per la configurazione di host BizTalk Server.

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

Seguire queste linee guida per creare più host BizTalk Server e allocare il carico di lavoro in tali host:

  • Creare host separati 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 nei computer che eseguono BizTalk Server in un gruppo BizTalk. L'uso di più host consente 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 a una scheda di ricezione in esecuzione in un'istanza host diversa di ricevere messaggi in ingresso. La separazione delle istanze host in base alle funzionalità offre anche i vantaggi seguenti:

    • L'esecuzione di più host BizTalk riduce la contesa nelle tabelle della coda host del database MessageBox perché ogni host viene assegnato alle proprie 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.

  • Ogni istanza host ha un proprio set di risorse, ad esempio memoria, handle e thread nel pool di thread .NET. Quando si assegna il carico di lavoro tra gli host, è consigliabile inserire le risorse che si ridimensionano insieme nello stesso host.

  • Schede e orchestrazioni separate con priorità diverse per le risorse in host diversi. Questa tecnica consente di posizionare gli host che eseguono applicazioni con priorità elevata su computer dedicati BizTalk Server.

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 (https://go.microsoft.com/fwlink/?LinkID=154359) nella Guida BizTalk Server 2010.

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. Per prestazioni ottimali, deve essere presente 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.

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à rigonfiato, 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 (https://go.microsoft.com/fwlink/?LinkID=154193) nella Guida BizTalk Server 2010. 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 di BizTalk Server 2010:

  • Gestione del servizio bus di eventi BAM (https://go.microsoft.com/fwlink/?LinkID=154194).

  • Creazione di istanze del servizio bus di eventi BAM (https://go.microsoft.com/fwlink/?LinkID=154195).

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

Mentre BizTalk Server 2010 consente di configurare un host BizTalk come risorsa cluster, è consigliabile considerare 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, questo introduce un singolo punto di errore, che potrebbe trarre vantaggio dal clustering. Gli host che contengono schede, ad esempio file, SQL, HTTP o solo host di elaborazione, possono essere internamente bilanciati tra computer e non trarre vantaggio dal clustering.

Aumentare il numero di connessioni simultanee HTTP consentite modificando il valore per il parametro maxconnection

Per impostazione predefinita, le schede HTTP (incluse le schede HTTP basate su WCF) aprono solo due connessioni HTTP simultanee da ogni computer che esegue BizTalk Server a qualsiasi server di destinazione specifico.

Questa impostazione è conforme alla specifica IETF RFC per la specifica HTTP 1.1 e anche se è adatta per gli scenari utente, non è ottimizzata per la velocità effettiva elevata. L'impostazione limita in modo efficace le chiamate HTTP in uscita a ogni server a due invii simultanei da ogni computer che esegue BizTalk Server.

Per aumentare il numero di connessioni simultanee, è possibile modificare il valore per il parametro maxconnection nel file di configurazione BizTalk Server, BTSNTSvc.exe.config (o BTSNTSvc64.exe.config per gli host a 64 bit), in ogni BizTalk Server. È possibile aumentare questo valore per i server specifici chiamati. Come regola generale, il valore per il parametro maxconnection deve essere impostato su 12 * il numero di CPU o core nel computer che ospita l'applicazione Web.

Nota

Non aumentare il valore per il parametro maxconnection a un valore di tale grandi dimensioni chiamato dal server Web con connessioni HTTP. Dopo aver modificato il valore per il parametro maxconnection, eseguire test di stress inviando richieste a ogni server Web di destinazione per determinare un valore per maxconnection che fornisce prestazioni ottimali e http invia senza sovraccaricare i server Web di destinazione.

Di seguito è riportato un esempio di configurazione per la proprietà relativa al numero massimo di connessioni:

<configuration>
  <system.net>
    <connectionManagement>
      <add address="http://www.contoso.com" maxconnection="24" />
      <add address="*" maxconnection="48" />
    </connectionManagement>
  </system.net>
</configuration>

Quando si imposta la proprietà maxconnection, HTTP, HTTPS, l'indirizzo IP del sito Web e il numero di porta può essere specificato. Altri esempi includono:

<add address="http://www.contoso.com" maxconnection="24" />
<add address="http://www.contoso.com:8080" maxconnection="24" />
<add address="http://<IP-address>" maxconnection="24" />

Per altre informazioni sull'ottimizzazione delle impostazioni IIS e ASP.NET per i servizi Web, vedere la sezione "impostazioni ASP.NET che possono influire sulle prestazioni dell'adattatore HTTP" dei parametri di configurazione che influiscono sulle prestazioni dell'adattatore (https://go.microsoft.com/fwlink/?LinkID=154200) in BizTalk Server 2010 Guida.

Gestire ASP.NET utilizzo del thread o eseguire simultaneamente richieste per applicazioni Web che possono ospitare posizioni ricevute isolate, servizi Web back-end e servizi WCF

Il numero di thread di lavoro e I/O (IIS 7.5 e IIS 7.0 in modalità classica) o il numero di richieste contemporaneamente in esecuzione (IIS 7.5 e 7.0 in modalità integrata) per un'applicazione Web ASP.NET che ospita posizioni ricevute isolate, servizi Web back-end e servizi WCF devono essere modificati nelle condizioni seguenti:

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

  • Valore di:

    • ASP.NET Apps v4.0.30319 \Request WaitTime o ASP.NET Apps v4.0.30319 \Request Execution Time counters è insolitamente elevato.

    • ASP.NET Apps v2.0.50727\Request Wait Time o ASP.NET Apps v2.0.50727\Request Execution Time counters è insolitamente elevato.

  • Un errore simile al seguente viene 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: 11/4/2010
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 possono ospitare posizioni ricevute isolate, servizi Web back-end e servizi WCF in IIS 7.5 e IIS 7.0 in esecuzione in modalità classica

Quando il valore autoConfig nel file machine.config di un server IIS 7.5 e IIS 7.0 in esecuzione in modalità classica è impostato su true, ASP.NET 2.0 e ASP.NET 4 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 ASP.NET 2.0 e ASP.Net 4 applicazione Web, aprire il file di machine.config associato e quindi 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 di machine.config per un'applicazione Web ASP.NET 2.0, vedere l'articolo microsoft Knowledge Base 821268 Contesa, prestazioni scarse e deadlock quando si emettono richieste di servizio Web da applicazioni ASP.NET (https://go.microsoft.com/fwlink/?LinkID=144169).

Gestire il numero di richieste simultanee in esecuzione per le applicazioni Web ASP.NET 2.0 che possono ospitare posizioni ricevute isolate, servizi Web back-end e servizi WCF in IIS 7.5 e IIS 7.0 in esecuzione in modalità integrata

Quando ASP.NET 2.0 è ospitato in IIS 7.5 e IIS 7.0 in modalità integrata, l'uso dei thread viene gestito in modo diverso rispetto a IIS 7.5 e IIS 7.0 in modalità classica. Quando ASP.NET 2.0 è ospitato in IIS 7.5 e 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.5 e 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 maxConcurrentRequestsPerCPU. Il valore maxConcurrentRequestsPerCPU può essere specificato nella riqistry o nella sezione config di un file di aspnet.config. Seguire questa procedura per modificare il valore predefinito per maxConcurrentRequestsPerCPU per gestire il numero di richieste contemporaneamente in esecuzione:

Impostare il valore maxConcurrentRequestsPerCPU 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 maxConcurrentRequestsPerCPU e quindi premere INVIO.

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

    4. Chiudere l'editor del Registro di sistema.

Impostare il valore maxConcurrentRequestsPerCPU 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 maxConcurrentRequestsPerCPU 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 .

Per altre informazioni sulla configurazione dell'utilizzo di thread ASP.NET in IIS 7.0, vedere Il blog di Thomas Marquardt su ASP.NET Utilizzo thread in IIS 7.0 (https://go.microsoft.com/fwlink/?LinkId=157518).

Gestire il numero di richieste contemporaneamente in esecuzione per ASP.NET 4 applicazioni Web che possono ospitare posizioni ricevute isolate, servizi Web back-end e servizi WCF in IIS 7.5 e 7.0 in esecuzione in modalità integrata

Con .NET Framework 4, l'impostazione predefinita per maxConcurrentRequestsPerCPU è 5000, che è un numero molto elevato e quindi consentirà l'esecuzione simultanea di numerose richieste asincrone. Per altre informazioni, vedere <elemento applicationPool> (Impostazioni Web).https://go.microsoft.com/fwlink/?LinkID=205339

Per la modalità integrata IIS 7.5 e IIS 7.0, una DWORD denominata MaxConcurrentRequestsPerCPU all'interno di HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0 determina il numero di richieste simultanee per CPU. Per impostazione predefinita, la chiave del Registro di sistema non esiste e il numero di richieste per CPU è limitato a 5000.

Impostare il valore maxConcurrentRequestsPerCPU 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\4.0.30319.0.

  3. Creare la chiave seguendo questa procedura:

    1. Nel menu Modifica selezionare Nuovo e quindi Chiave.

    2. Digitare maxConcurrentRequestsPerCPU e quindi premere INVIO.

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

    4. Chiudere l'editor del Registro di sistema.

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

  1. Scaricare e installare Microsoft .NET Framework 4, che è necessario per soddisfare i valori seguenti nel file di configurazione.

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

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

    I valori nell'esempio seguente sono i valori predefiniti.

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

    Nota

    Questo valore esegue l'override del valore specificato per maxConcurrentRequestsPerCPU 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. Il numero predefinito di thread allocati a un pool di thread .NET dell'istanza dell'host BizTalk dipende dalla versione di .NET Framework installata. .NET Framework 4 e .NET Framework 3.5 SP1 aumentano notevolmente le impostazioni predefinite, che possono causare un'allocazione eccessiva del thread nei computer BizTalk Server e contesa eccessiva del blocco nel database MessageBox.

Usando il dashboard delle impostazioni BizTalk, è possibile modificare il valore predefinito per il numero di thread di Windows disponibili nel pool di thread .NET associato a un'istanza di un host BizTalk. Per altre informazioni su come modificare le impostazioni CLR .NET, vedere Come modificare le impostazioni CLR .NET (https://go.microsoft.com/fwlink/?LinkID=205344). Le impostazioni CLR .NET sono per CPU di base.

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 completata.

Impostazioni di threading Valore predefinito Valore consigliato
Thread I/O massimi 250 250
Thread di lavoro massimi 25 100 Importante: l'aumento di questo valore oltre 100 può influire negativamente sulle prestazioni del computer SQL Server che ospita il database MessageBox di BizTalk Server. Se si verifica questo problema, SQL Server potrebbe rilevare una condizione di blocco critico (deadlock). È consigliabile non aumentare questo parametro oltre a un valore pari a 100.
Thread I/O minimi 25 25
Thread di lavoro minimi 5 25

Nota

I valori consigliati non sono assoluti e possono essere modificati a seconda dell'applicazione BizTalk. Modificare un parametro alla volta e quindi misurare l'impatto sulle prestazioni e sulla stabilità della piattaforma BizTalk prima di apportare modifiche aggiuntive.

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 imposta un valore pari a 400 su un server CPU 4.

Disabilitare BizTalk Server rilevamento a livello di gruppo

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. Le considerazioni seguenti si applicano durante la configurazione del rilevamento in un ambiente di BizTalk Server di produzione:

  • Se il rilevamento non è un requisito aziendale, disabilitare il rilevamento a livello di gruppo per ridurre il sovraccarico e aumentare le prestazioni.

    Per disabilitare BizTalk Server rilevamento a livello di gruppo, seguire questa procedura:

    1. Nella console di amministrazione BizTalk Server espandere BizTalk Server Amministrazione, fare clic con il pulsante destro del mouse su Gruppo BizTalk e quindi scegliere Impostazioni.

    2. Nella finestra di dialogo Dashboard impostazioni BizTalk deselezionare la casella di controllo Abilita rilevamento a livello di gruppo .

    3. Fare clic su OK per applicare le modifiche e uscire dal dashboard delle impostazioni.

  • Usare solo il rilevamento del corpo del messaggio, se necessario. A seconda della velocità effettiva dei messaggi e delle dimensioni dei messaggi, il rilevamento del corpo dei messaggi può causare un sovraccarico significativo. Anche se il rilevamento delle attività BizTalk offre vantaggi evidenti per il debug e il controllo, ha anche notevoli implicazioni di prestazioni e scalabilità. Pertanto, è necessario tenere traccia solo dei dati strettamente necessari per il debug e i motivi di sicurezza ed evitare di tenere traccia delle informazioni ridondanti.

  • Per impostazione predefinita, le opzioni di rilevamento seguenti sono abilitate per le orchestrazioni:

    • Inizio e fine dell'orchestrazione

    • Invio e ricezione di messaggi

    • Inizio e fine della forma

      L'opzione di rilevamento dell'orchestrazione "Inizio forma e fine" comporta un sovraccarico significativo e non deve essere abilitata in un ambiente di produzione in cui è necessaria una velocità effettiva elevata. Le opzioni di rilevamento orchestrazione sono accessibili nella console amministrazione BizTalk nella pagina Rilevamento della finestra di dialogo Proprietà orchestrazione.

    Per altre informazioni sulla configurazione del rilevamento, vedere Configurazione del rilevamento tramite la console di amministrazione di BizTalk Server (https://go.microsoft.com/fwlink/?LinkId=158021).

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 ad alta velocità effettiva, ciò può comportare un'eccessiva compilazione dei dati nel database di rilevamento, che avrà un impatto sulle prestazioni di MessageBox e a sua volta influisce negativamente sulla velocità effettiva di elaborazione dei messaggi.

In scenari con velocità effettiva elevata, ridurre l'intervallo di eliminazione temporanea e duro dall'impostazione predefinita di 7 giorni a 2 giorni. Per altre informazioni sulla configurazione dell'intervallo di eliminazione, vedere How to Configure the DTA Purge and Archive Job (https://go.microsoft.com/fwlink/?LinkID=153814) nella guida BizTalk Server 2010.

Configurare il percorso %temp% per l'account del servizio BizTalk in modo che punti a un disco o a un LUN separato

Questa operazione deve essere eseguita perché BizTalk usa il percorso temporaneo per trasmettere file su disco durante l'esecuzione di operazioni di mapping complesse.

Installare i Service Pack più recenti

I Service Pack più recenti per BizTalk Server e .NET Framework devono essere installati, in quanto contengono correzioni che possono correggere i problemi di prestazioni che potrebbero verificarsi.

Ottimizzazioni delle prestazioni nella documentazione di BizTalk Server

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

Vedere anche

Ottimizzazione delle prestazioni di BizTalk Server