Condividi tramite

Ottimizzazioni generali per BizTalk Server - Parte 1

Per migliorare le prestazioni di 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 il miglioramento delle prestazioni del sistema operativo.

Consigli per la configurazione degli host BizTalk Server

In questa sezione vengono fornite indicazioni per la configurazione degli host BizTalk Server.

Creare diversi host di BizTalk Server e istanze di host separate in base alle loro 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 tra i 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 un adattatore di ricezione in esecuzione in un'istanza host diversa di ricevere messaggi in ingresso. La separazione delle istanze host per funzionalità offre anche i vantaggi seguenti:

    • L'esecuzione di più host BizTalk riduce la contenzione nelle tabelle delle code di host del database MessageBox, poiché a ogni host vengono assegnate tabelle delle code di lavoro nel database MessageBox.

    • Il controllo della velocità viene implementato in BizTalk Server a livello dell'host. In questo modo è possibile impostare diversi parametri di limitazione per ogni host.

    • La sicurezza viene implementata a livello di host; ogni host viene eseguito con un'identità di Windows separata. Ciò consente, ad esempio, di concedere Host_A l'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 alloca il carico di lavoro tra gli host, è consigliabile posizionare le risorse che si adattano insieme nello stesso host.

  • Separa gli adattatori dalle orchestrazioni che hanno priorità diverse per le risorse su host differenti. Questa tecnica supporta il posizionamento degli host che eseguono applicazioni ad alta priorità in computer BizTalk Server dedicati.

Annotazioni

Anche se esistono 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à dell'host BizTalk Server, vedere How to Modify Host Properties (https://go.microsoft.com/fwlink/?LinkID=154359) nella Guida di 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 in questo modo questi motori vengono deviati dal loro lavoro principale di esecuzione dei processi aziendali. BizTalk Server lascia invece i messaggi nel database MessageBox e li contrassegna come necessario per passare al 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 così al minimo l'impatto che il rilevamento ha sugli host dedicati all'elaborazione dei messaggi. Per ottenere 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. "+ 1" è destinato alla ridondanza, nel caso in cui uno dei computer che ospitano il rilevamento non riesca.

L'uso di un host di rilevamento dedicato consente anche 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 BizTalk Server integro. Se l'host BizTalk responsabile dello spostamento dei dati di rilevamento nel gruppo BizTalk viene arrestato, il servizio Di decodifica dei 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 dei dati di rilevamento viene arrestato, gli intercettori di rilevamento continueranno a essere attivati e scriveranno i dati di rilevamento nel database MessageBox. Se i dati non vengono spostati, il database MessageBox diventa gonfio, che influirà sulle prestazioni nel tempo. Anche se le proprietà personalizzate non vengono rilevate o i profili BAM non sono configurati, per impostazione predefinita vengono rilevati alcuni dati, ad esempio la ricezione/l'invio di eventi di pipeline e eventi di orchestrazione. Se non si vuole eseguire il servizio Decodifica dati di rilevamento, disattivare tutto il rilevamento in modo che nessun intercettatore salvi i dati nel database. Per disabilitare il rilevamento globale, vedere Come disattivare il rilevamento globale (https://go.microsoft.com/fwlink/?LinkID=154193) nella Guida di BizTalk Server 2010. Usare la console di amministrazione di BizTalk Server per disabilitare in modo selettivo gli eventi di rilevamento.

    L'host di rilevamento dovrebbe essere eseguito su almeno due computer che eseguono BizTalk Server, per garantire la ridondanza nel caso in cui uno di essi si guasti. Per ottenere 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. "+ 1" è destinato alla ridondanza, nel caso in cui uno dei computer che ospitano il rilevamento non riesca.

    Un'istanza host di rilevamento sposta i dati di rilevamento per database MessageBox specifici, ma non ci saranno mai più istanze host di rilevamento che spostano 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 in un altro computer che esegue BizTalk Server. In questo scenario, l'aggiunta di una quarta istanza host di rilevamento non distribuirà ulteriore lavoro dell'host di rilevamento, ma fornirà un'istanza host di rilevamento aggiuntiva per la tolleranza ai guasti.

    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 clusterre host BizTalk a meno che non sia assolutamente necessario

Anche se BizTalk Server 2010 consente di configurare un host BizTalk come risorsa cluster, è consigliabile prendere in considerazione 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, perché il protocollo FTP non fornisce il blocco dei file. Tuttavia, questo introduce un singolo punto di errore, che trarrebbe vantaggio dal clustering. Gli host che contengono adattatori, come quelli per file, SQL, HTTP o host dedicati esclusivamente all'elaborazione, possono essere internamente bilanciati tra i computer e non traggono vantaggio dal clustering.

Aumentare il numero di connessioni HTTP simultanee 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 RFC IETF per la specifica HTTP 1.1 e, sebbene sia adatta per gli scenari utente, non è ottimizzata per la velocità effettiva elevata. L'impostazione limita efficacemente 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 di 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.

Annotazioni

Non aumentare il valore del parametro maxconnection a tal punto da sovraccaricare il server Web con troppe 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 fornirà buone prestazioni e invio HTTP senza sovraccaricare i server Web di destinazione.

Di seguito è riportato un esempio della configurazione per la proprietà maximum connections:

<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, è possibile specificare HTTP, HTTPS, l'indirizzo IP del sito Web e il numero di porta. 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 di IIS e ASP.NET per i servizi Web, vedere la sezione "impostazioni ASP.NET che possono influire sulle prestazioni dell'adapter HTTP" di Parametri di configurazione che influiscono sulle prestazioni dell'adapter (https://go.microsoft.com/fwlink/?LinkID=154200) nella Guida di BizTalk Server 2010.

Gestire l'uso dei thread ASP.NET o l'esecuzione simultanea di richieste per applicazioni Web che possono ospitare posizioni ricevute in isolamento, 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 in esecuzione simultanea (IIS 7.5 e 7.0 in modalità integrata) per un'applicazione Web ASP.NET che ospita posizioni ricevute isolate, i servizi Web back-end e i 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 Wait Time o ASP.NET Apps v4.0.30319 \Request Execution Time i contatori delle prestazioni sono insolitamente elevati.

    • ASP.NET Apps v2.0.50727\Tempo di Attesa della Richiesta o ASP.NET Apps v2.0.50727\Tempo di Esecuzione della Richiesta i contatori delle prestazioni sono insolitamente alti.

  • Un errore simile al seguente viene generato nel registro applicazioni 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 l'utilizzo dei thread in ASP.NET per applicazioni Web in grado di ospitare punti di ricezione isolati, servizi Web back-end e servizi WCF su IIS 7.5 e IIS 7.0 eseguendo 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'applicazione Web ASP.NET 2.0 e ASP.Net 4, 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" />

Annotazioni

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

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

Gestire il numero di richieste di esecuzione simultanea per ASP.NET applicazioni Web 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 in esecuzione simultanea anziché il numero di thread che eseguono contemporaneamente richieste. Per gli scenari sincroni questo limiterà indirettamente il numero di thread, ma per gli scenari asincroni il numero di richieste e thread sarà probabilmente 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 in esecuzione simultanea può essere modificato rispetto al valore predefinito 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 in esecuzione simultanea:

Impostare il valore maxConcurrentRequestsPerCPU nel Registro di sistema

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

Avvertimento

Usare il registro Editor a proprio rischio. L'uso non corretto 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 della Microsoft Knowledge Base 256986 - Informazioni del Registro di sistema di Windows per utenti avanzati.

  1. Dal menu Start trovare 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 selezionare 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, necessario per supportare l'impostazione dei valori seguenti nel file di configurazione. È disponibile anche la versione completa .

  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>

    Annotazioni

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

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

Gestire il numero di richieste di esecuzione simultanea 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, ovvero un numero molto elevato e pertanto 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.

Avvertimento

Usare il registro Editor a proprio rischio. L'uso non corretto 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 della Microsoft Knowledge Base 256986 - Informazioni del Registro di sistema di Windows per utenti avanzati.

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

  2. Navigare 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 selezionare 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, necessario per supportare l'impostazione dei 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>

    Annotazioni

    Questo valore esegue l'override del valore specificato per maxConcurrentRequestsPerCPU nel Registro di sistema. L'impostazione requestQueueLimit equivale a processModel/requestQueueLimit, ad eccezione dell'impostazione nel file aspnet.config sostituirà l'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ù semplice 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 la fame di thread. Quando si verifica la fame di thread, non sono disponibili thread sufficienti per eseguire il lavoro richiesto che influisce negativamente sulle prestazioni. Allo stesso tempo, è necessario prestare attenzione a evitare di allocare più thread al pool di thread .NET associato a un host rispetto al necessario. L'allocazione di troppi thread al pool di thread .NET associato a un host può aumentare il cambio di 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 di contesto eccessivo, che influirà negativamente sulle prestazioni complessive. Il numero predefinito di thread allocati al pool di thread .NET di un'istanza host BizTalk dipende dalla versione di .NET Framework installata. .NET Framework 4 e .NET Framework 3.5 SP1 hanno aumentato notevolmente le impostazioni predefinite, causando un'allocazione eccessiva di thread nei computer BizTalk Server e un numero eccessivo di conflitti di 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 di .NET, vedere How to Modify .NET CLR Settings (https://go.microsoft.com/fwlink/?LinkID=205344). Le impostazioni del CLR di .NET sono per core della CPU.

Annotazioni

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.

Impostazioni di threading Valore predefinito Valore consigliato
Numero massimo di thread di I/O 250 250
Numero massimo di thread di lavoro 25 100 Importante: l'aumento di questo valore superiore a 100 può influire negativamente sulle prestazioni del computer SQL Server che ospita il database MessageBox di BizTalk Server. Quando si verifica questo problema, SQL Server potrebbe riscontrare una condizione di deadlock. È consigliabile non aumentare questo parametro oltre il valore 100.
Thread Minimi di I/O 25 25
Thread di lavoro minimo 5 25

Annotazioni

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.

Annotazioni

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

Disabilitare il rilevamento a livello di gruppo di BizTalk Server

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. Quando si configura il rilevamento in un ambiente BizTalk Server di produzione, si applicano le considerazioni seguenti:

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

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

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

    2. Nella finestra di dialogo Dashboard delle impostazioni BizTalk, nella pagina Gruppo, 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 il rilevamento del corpo del messaggio solo se necessario. A seconda della velocità effettiva dei messaggi e delle dimensioni dei messaggi, il rilevamento del corpo del messaggio 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 in termini di prestazioni e scalabilità. È pertanto consigliabile tenere traccia solo dei dati strettamente necessari per motivi di debug e sicurezza ed evitare di tenere traccia delle informazioni ridondanti.

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

    • Inizio e fine dell'orchestrazione

    • Invio e ricezione di messaggi

    • Inizio e fine della forma

      L'opzione di tracciamento dell'orchestrazione "Shape start and end" comporta un sovraccarico significativo e non deve essere abilitata in un ambiente di produzione in cui è necessario un alto throughput. Le opzioni di rilevamento dell'orchestrazione sono accessibili nella console di amministrazione di BizTalk nella pagina Rilevamento della finestra di dialogo Proprietà orchestrazione.

    Per altre informazioni sulla configurazione del rilevamento, vedere Configuring Tracking Using the BizTalk Server Administration Console (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 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 pulizia dura e morbida dal valore predefinito 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 di 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 i file su disco durante l'esecuzione di operazioni di mapping complesse.

Installare i Service Pack più recenti

È consigliabile installare i Service Pack più recenti per BizTalk Server e .NET Framework, 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

  • Last updated on