Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
In questo argomento vengono fornite indicazioni per la selezione dell'adattatore WCF appropriato o del tipo di associazione e indicazioni per l'applicazione di varie opzioni di configurazione dell'adattatore WCF.
Considerazioni sulla scelta dell'adattatore WCF da usare o sul tipo di associazione WCF-Custom/WCF-CustomIsolated da usare
Non usare la sicurezza a livello di messaggio se non è strettamente necessaria perché aumenta le dimensioni dei messaggi. Ciò a sua volta può ridurre al minimo la velocità effettiva complessiva della soluzione.
Quando si sceglie quale adattatore WCF usare o quale tipo di associazione WCF-Custom/WCF-CustomIsolated da usare, prendere in considerazione attentamente eventuali requisiti dell'applicazione, ad esempio compatibilità, prestazioni, piattaforma di hosting, sicurezza e trasporti supportati. Le linee guida elencate di seguito sono applicabili a WCF in generale e non sono specifiche di BizTalk Server:
BasicHttpBinding deve essere usato se il servizio WCF deve supportare client legacy, ad esempio servizi Web Web WebSphere o applicazioni .NET 1.1 che prevedono un servizio Web ASMX. Poiché BasicHttpBinding non implementa alcuna sicurezza per impostazione predefinita, se è necessaria la sicurezza del messaggio o del trasporto, è necessario configurarla in modo esplicito su questa associazione. Usare BasicHttpBinding per esporre gli endpoint in grado di comunicare con servizi Web basati su ASMX e client e altri servizi conformi alla WS-I Profilo basic 1.1. Quando si configura la sicurezza del trasporto, l'impostazione predefinita BasicHttpBinding non usa credenziali come un servizio Web ASMX classico. BasicHttpBinding consente di ospitare il servizio WCF in IIS 7.5 o IIS 7.0.
WsHttpBinding deve essere usato se il servizio WCF verrà chiamato dai client WCF tramite Internet. WsHttpBinding è una buona scelta per gli scenari Internet in cui non è necessario supportare i client legacy che prevedono un servizio Web ASMX e WsHttpBinding consente di ospitare il servizio WCF in IIS 7.5 o IIS 7.0. Se è necessario supportare i client legacy, prendere in considerazione l'uso di BasicHttpBinding. WsHttpBinding deve essere usato quando è necessario esporre percorsi di ricezione WCF o adottare porte di trasmissione che supportano protocolli WS-* come WS-Security o WS-AtomicTransactions.
NetTcpBinding è un'ottima scelta se è necessario supportare i client all'interno della intranet. NetTcpBinding è una buona scelta per gli scenari Intranet se le prestazioni del trasporto sono importanti per l'utente e se è accettabile ospitare il servizio in un servizio Windows anziché in IIS. Usa questo binding quando vuoi fornire un contesto di associazione sicuro e affidabile per la comunicazione multipiattaforma .NET-to-.NET. Si noti che NetTcpBinding deve essere ospitato in un servizio Windows o in IIS 7.5/7.0.
NetNamedPipeBinding deve essere usato se è necessario supportare i client WCF nello stesso computer del servizio. Questa associazione fornisce un ambiente di associazione sicuro e affidabile per la comunicazione tra processi, stesso computer. Usare questa associazione quando si vuole usare il protocollo NamedPipe. Si noti che NetNamedPipeBinding deve essere ospitato in un servizio Windows o in IIS 7.5/7.0.
NetMsmqBinding deve essere usato se è necessario supportare l'accodamento disconnesso. L'accodamento viene fornito tramite Accodamento di messaggi (noto anche come MSMQ) come trasporto, che consente il supporto per operazioni disconnesse, isolamento degli errori e bilanciamento del carico. È possibile usare NetMsmqBinding quando il client e il servizio non devono essere online contemporaneamente. È anche possibile gestire un numero qualsiasi di messaggi in arrivo usando il livellamento del carico. La coda di messaggi supporta l'isolamento dei guasti, permettendo ai messaggi di fallire senza influire sull'elaborazione di altri messaggi. Si noti che NetMsmqBinding deve essere ospitato in un servizio Windows o in IIS 7.5/7.0.
WsDualHttpBinding deve essere usato se è necessario supportare un servizio duplex. Un servizio duplex è un servizio che utilizza schemi di messaggi duplex, consentendo così a un servizio di comunicare nuovamente con il client tramite un callback. Si noti che WsDualHttpBinding deve essere ospitato in un servizio Windows o in IIS 7.5/7.0.
Confronto tra binding WCF
Le associazioni forniscono un meccanismo per la configurazione degli stack di canali. Un'associazione crea un processo per creare uno stack di canali usando un canale di trasporto, un codificatore di messaggi e un set di canali di protocollo. Windows Communication Foundation viene fornito con numerose associazioni predefinite preconfigurate per gestire gli scenari di comunicazione più comuni.
| Nome della Classe di Binding | Trasporto | Codifica dei messaggi | Modalità di sicurezza | Messaggistica affidabile | Flusso di transazione (disabilitato per impostazione predefinita) |
|---|---|---|---|---|---|
| BasicHttpBinding | Protocollo HTTP | Testo | Nessuno | Non supportato | Non supportato |
| WSHttpBinding | Protocollo HTTP | Testo | Messaggio | Disabilitato | WS-AtomicTransactions |
| NetTcpBinding | TCP | Binario | Trasporto | Disabilitato | OleTransactions |
| NetNamedPipesBinding | Named Pipes | Binario | Trasporto | Non supportato | OleTransactions |
| NetMsmqBinding | MSMQ | Binario | Messaggio | Non supportato | Non supportato |
| CustomBinding | Decidi tu | Decidi tu | Decidi tu | Decidi tu | Decidi tu |
È possibile selezionare un vincolo specifico in funzione delle esigenze di comunicazione. Per esempio:
BasicHttpBinding è progettato per l'interoperabilità con semplici servizi Web. BasicHttpBinding usa HTTP per il trasporto e il testo per la codifica dei messaggi.
WSHttpBinding è progettato per l'interoperabilità con servizi Web più avanzati che potrebbero sfruttare protocolli WS-* diversi. WSHttpBinding usa anche HTTP per il trasporto e il testo per la codifica dei messaggi.
NetTcpBinding e NetNamedPipeBinding sono progettati per garantire una comunicazione performante ed efficiente con altre applicazioni WCF tra macchine diverse o sulla stessa macchina.
Se è necessaria la massima flessibilità usando uno o più canali di protocollo personalizzati in fase di esecuzione, è possibile usare CustomBinding che consente di decidere quali elementi di associazione compongono l'associazione.
Annotazioni
Le associazioni hanno caratteristiche diverse in termini di tempo di risposta e velocità effettiva. Pertanto, il consiglio generale per migliorare le prestazioni consiste nell'usare NetTcpBindind e NetNamesPipeBinding, quando possibile.
Usare il trasporto TCP e la codifica dei messaggi binari per ottimizzare la velocità effettiva dell'adattatore WCF e ridurre al minimo la latenza dell'adapter WCF
Usare l'adattatore WCF-NetTcp quando possibile per ottimizzare la velocità effettiva. L'adattatore WCF-NetTcp usa il protocollo di trasporto TCP/IP e la codifica dei messaggi binari, che insieme offrono prestazioni migliori rispetto ad altri adattatori WCF-*.
In alternativa, è possibile configurare il WCF-Custom (o l'adattatore WCF-CustomIsolated per le località di ricezione) con un tipo di configurazione customBinding. Aggiungere quindi l'estensione di binding binaryMessageEncoding per implementare la codifica dei messaggi binari e l'estensione di binding tcpTransport per trasportare i messaggi con il protocollo TCP/IP. Questo approccio è molto flessibile perché consente di selezionare e configurare solo gli elementi di associazione necessari e di creare canali personalizzati per estendere il comportamento predefinito del motore di messaggistica BizTalk. Se si implementa l'adattatore WCF-Custom con il tipo di associazione customBinding , specificare questi valori per i parametri di configurazione dell'estensione di associazione per ottimizzare la velocità effettiva e ridurre al minimo la latenza.
Valori di configurazione della porta di trasmissione:
| Impostazione | Valore predefinito | Valore consigliato |
|---|---|---|
| TcpTransportBindingElement.ConnectionPoolSettings.maxOutboundConnectionsPerEndpoint : ottiene o imposta il numero massimo di connessioni in uscita per ogni endpoint memorizzato nella cache nel pool di connessioni. Questo limita il numero di connessioni memorizzate nella cache per ogni endpoint remoto univoco. Se questo valore viene superato avendo più connessioni client attive, il servizio potrebbe non rispondere al client e questo valore deve essere regolato in modo da contenere il numero massimo di connessioni previste memorizzate nella cache per ogni endpoint remoto univoco. Per altre informazioni su questa proprietà, vedere TcpConnectionPoolSettings.MaxOutboundConnectionsPerEndpoint Property (https://go.microsoft.com/fwlink/?LinkId=157737) su MSDN. | 10 | Prova >= 20 |
Valori di configurazione della porta di ricezione:
| Impostazione | Valore predefinito per .NET Framework 4 | Valore consigliato per .NET Framework 4 | Valore predefinito per .NET Framework 3.5 | Valore consigliato per .NET Framework 3.5 |
|---|---|---|---|---|
| TcpTransportBindingElement.MaxPendingAccepts : ottiene o imposta il numero massimo di operazioni di accettazione asincrone in sospeso disponibili per l'elaborazione delle connessioni in ingresso al servizio. Per gli scenari con livelli elevati di iniziazioni di connessione simultanee, questo valore può risultare inadeguato e deve essere regolato insieme alla proprietà MaxPendingConnections per gestire livelli più elevati di tentativi di connessione client simultanei. Non deve essere necessario impostare questa proprietà su un valore maggiore del numero di processori presenti nel computer che ospita il servizio. Per altre informazioni su questa proprietà, vedere ConnectionOrientedTransportBindingElement.MaxPendingAccepts Property (https://go.microsoft.com/fwlink/?LinkId=157738) su MSDN. | 1 | 2*ProcessorCount | 1 | Prova >= 20 |
| TcpTransportBindingElement.MaxPendingConnections : ottiene o imposta il numero massimo di connessioni in attesa di invio nel servizio. Questo limita il numero di connessioni client simultanee in attesa di invio. Se questo valore è troppo basso, i tentativi di connessione client potrebbero essere rifiutati dal servizio. Se è troppo elevato, il servizio potrebbe risultare lento o non risponde ai client durante periodi di carico elevati. Questa proprietà deve essere impostata su un valore che consente l'esecuzione del servizio con capacità completa e non superiore. Quando un livello superiore nello stack chiama AcceptDispatch, tale connessione viene rimossa dalla coda di connessioni in attesa dell'invio. Per altre informazioni su questa proprietà, vedere Proprietà ConnectionOrientedTransportBindingElement.MaxPendingConnections (https://go.microsoft.com/fwlink/?LinkId=157735) su MSDN. | 10 | 16*ProcessorCount | 10 | Prova >= 20 |
| TcpTransportBindingElement.ListenBacklog : ottiene o imposta il numero massimo di richieste di connessione in coda che possono essere in sospeso. ListenBacklog è una proprietà del socket che descrive il numero di richieste di accettazione in sospeso che devono essere accodate. Assicurarsi che il numero massimo di connessioni simultanee non superi la coda del socket sottostante. Per altre informazioni su questa proprietà, vedere Proprietà TcpTransportBindingElement.ListenBacklog (https://go.microsoft.com/fwlink/?LinkId=157734) su MSDN. | 10 | 16*ConteggioProcessore | 10 | Prova con >= 20 |
Aggiungere il comportamento del servizio ServiceThrottlingBehavior a un punto di ricezione WCF-Custom o WCF-CustomIsolated e usare le impostazioni seguenti:
Annotazioni
Prima che qualsiasi elemento del comportamento del servizio ServiceThrottlingBehavior possa essere modificato, è necessario innanzitutto aggiungere l'estensione del comportamento serviceThrottling alla scheda Comportamenti della finestra di dialogo Proprietà trasporto WCF-Custom* . Per aggiungere serviceThrottling all'elenco Comportamenti, selezionare la scheda Comportamenti della finestra di dialogo Proprietà trasporto WCF-Custom* , fare clic con il pulsante destro del mouse su ServiceBehavior in Comportamento, scegliere Aggiungi estensione, selezionare serviceThrottling e quindi fare clic su OK. Fare quindi clic per selezionare le proprietà disponibili in ServiceThrottlingElement e modificare il valore per le proprietà in base alle esigenze.
| Impostazione | Valore predefinito per .NET Framework 4 | Valore consigliato per .NET Framework 4 | Valore predefinito per .NET Framework 3.5 | Valore consigliato per .Net Framework 3.5 |
|---|---|---|---|---|
| ServiceThrottlingBehavior.MaxConcurrentCalls : ottiene o imposta un valore che specifica il numero massimo di messaggi elaborati attivamente in un ServiceHost. La proprietà MaxConcurrentCalls specifica il numero massimo di messaggi che elaborano attivamente in un oggetto ServiceHost . Ogni canale può avere un messaggio in sospeso che non viene conteggiato rispetto al valore di MaxConcurrentCalls fino a quando WCF non inizia a elaborarlo. Per altre informazioni su questa proprietà, vedere ServiceThrottlingBehavior.MaxConcurrentCalls (https://go.microsoft.com/fwlink/?LinkId=157838) su MSDN. Il valore predefinito per la proprietà MaxConcurrentCalls degli adattatori di ricezione BizTalk WCF-Custom e WCF-CustomIsolated è 16 per CPU. Nota: Gli adapter di ricezione WCF di BizTalk Server diversi dalla WCF-Custom e WCF-CustomIsolated adapter espongono una proprietà Chiamate simultanee massime nella scheda Binding della finestra di dialogo Proprietà trasporto WCF-* per configurare questo comportamento. Il valore predefinito del comportamento Numero massimo di chiamate simultanee è 200. | 16*ProcessorCount | 16*ProcessorCount (conteggio processori) | - 16 per gli adattatori di ricezione BizTalk WCF-Custom e WCF-CustomIsolated. - 200 per gli altri adattatori di ricezione WCF. |
- Provare >= 200 per gli adattatori di ricezione WCF-Custom e WCF-CustomIsolated. - Provare > 200 per la proprietà Numero massimo di chiamate simultanee nella scheda Binding della finestra di dialogo Proprietà trasporto WCF-* per gli adattatori di ricezione WCF di BizTalk Server diversi dall'adapter di ricezione WCF-Custom e WCF-CustomIsolated. |
| ServiceThrottlingBehavior.maxConcurrentInstances : ottiene o imposta un valore che specifica il numero massimo di oggetti InstanceContext nel servizio che possono essere eseguiti contemporaneamente. La proprietà MaxConcurrentInstances specifica il numero massimo di oggetti InstanceContext nel servizio. È importante tenere presente la relazione tra la proprietà MaxConcurrentInstances e la proprietà InstanceContextMode . Se InstanceContextMode è PerSession, il valore risultante corrisponde al numero totale di sessioni. Se InstanceContextMode è PerCall, il valore risultante corrisponde al numero di chiamate simultanee. Se un messaggio arriva mentre esiste già il numero massimo di oggetti InstanceContext , il messaggio viene mantenuto fino alla chiusura di un oggetto InstanceContext . Per altre informazioni su questa proprietà, vedere La proprietà ServiceThrottlingBehavior.MaxConcurrentInstances (https://go.microsoft.com/fwlink/?LinkId=157897) su MSDN. Il valore predefinito per la proprietà WCF-Custom e WCF-CustomIsolated receive adapter MaxConcurrentInstances è 116 per CPU. Nota: Poiché i percorsi di ricezione WCF vengono implementati come istanze della classe BizTalkServiceInstance contenuta nell'assembly Microsoft.BizTalk.Adapter.Wcf.Runtime.dll e poiché questa classe è contrassegnata come ServiceBehavior(InstanceContextMode=InstanceContextMode.Single, ConcurrencyMode=ConcurrencyMode.Multiple). tutte le richieste in ingresso vengono gestite dallo stesso oggetto singleton e questo parametro viene ignorato. Pertanto, l'impostazione della proprietà maxConcurrentInstances in determinate posizioni di ricezione WCF-Custom non ha alcun effetto, poiché il numero di istanze attive è sempre uguale a 1. | 116*ProcessorCount | 116*ProcessorCount | 26 | Prova >= 200 |
| ServiceThrottlingBehavior.MaxConcurrentSessions : la proprietà MaxConcurrentSessions ottiene o imposta il numero massimo di sessioni che un oggetto ServiceHost può accettare contemporaneamente. È importante comprendere che le sessioni in questo caso non sono limitate solo ai canali che supportano sessioni affidabili. Ogni oggetto listener può avere una sessione in sospeso per ciascun canale che non viene conteggiata rispetto al valore di MaxConcurrentSessions fino a quando WCF non accetta la sessione di canale e inizia l'elaborazione dei messaggi della sessione di canale. Questa proprietà è più utile negli scenari che usano sessioni. Quando questa proprietà è impostata su un valore minore del numero di thread client, le richieste provenienti da più client possono essere accodate nella stessa connessione socket. Le richieste dal client che non ha creato una sessione con il servizio verranno bloccate. Rimarranno bloccati fino a quando il servizio non chiude la sessione con gli altri client, se il numero di sessioni aperte nel servizio ha raggiunto il valore specificato per MaxConcurrentSessions. Le richieste client non gestite vengono quindi timeout e il servizio chiude la sessione. Per evitare questa situazione, prendere in considerazione l'esecuzione dei thread client da domini applicazione diversi in modo che i messaggi di richiesta vengano accettati da connessioni socket diverse. Per altre informazioni su questa proprietà, vedere Proprietà ServiceThrottlingBehavior.MaxConcurrentSessions (https://go.microsoft.com/fwlink/?LinkId=157864) su MSDN. | 100*ConteggioProcessori | 100*ConteggioProcessori | 10 | Prova >= 200 |
Quando si modificano le impostazioni di configurazione delle porte, applicare le modifiche in modo metodico; modificare ogni parametro singolarmente e testare gli effetti della modifica sulle prestazioni e sulla stabilità complessiva. Come sempre, il valore appropriato da applicare dipende dallo scenario specifico: se un valore è impostato su un valore troppo basso, la scalabilità può essere ridotta; mentre se un valore è impostato troppo alto, il requisito dell'applicazione può superare la capacità delle risorse fisiche nel computer. Inoltre, poiché queste proprietà sono correlate, devono essere impostate in modo coerente e coerente. Per altre informazioni sull'uso di ServiceThrottlingBehavior per controllare le prestazioni del servizio WCF, vedere Uso di ServiceThrottlingBehavior per controllare le prestazioni del servizio WCF (https://go.microsoft.com/fwlink/?LinkId=157908) su MSDN.