Stimare i requisiti di prestazioni e capacità per Servizi di integrazione applicativa Microsoft in SharePoint Server 2010

 

Si applica a: SharePoint Server 2010

Ultima modifica dell'argomento: 2016-11-30

**Riepilogo:**In questo articolo sono incluse informazioni sulle prestazioni e sulla pianificazione e viene illustrato l'impatto dell'utilizzo di Servizi di integrazione applicativa in Microsoft SharePoint Server 2010.

Per ulteriori informazioni su Servizi di integrazione applicativa, vedere Panoramica di Servizi di integrazione applicativa (SharePoint Server 2010).

Contenuto dell'argomento:

• Glossario

• Caratteristiche della farm di testing

• Risultati dei test

• Suggerimenti

Glossario

Nell'elenco seguente vengono definiti i termini relativi a Servizi di integrazione applicativa utilizzati in questo documento.

Termine	Definizione
Associazione	Un'associazione consente di collegare tipi di contenuto esterno correlati. I clienti possono ad esempio essere associati ai relativi ordini di vendita. Le associazioni vengono utilizzate insieme alle web part.
Elemento esterno	Istanza di un tipo di contenuto esterno.
Elenco esterno	Elenco di elementi di un tipo di contenuto esterno.
Sistema esterno	Origine dati supportata che può essere modellata da Servizi di integrazione applicativa, ad esempio un database, un servizio Web o un assembly .NET Framework personalizzato.
Pagina del profilo	In una pagina del profilo vengono visualizzati i dati per un elemento di un tipo di contenuto esterno.
Servizio di archiviazione sicura	Servizio condiviso che consente di archiviare in modo sicuro insiemi di credenziali per le origini dati esterne e di associare tali insiemi a identità di persona o di gruppo.
Web part	Componente riutilizzabile di un sito di SharePoint tramite cui vengono visualizzate informazioni recuperate da più origini dati.

Caratteristiche della farm di testing

In questa sezione vengono definiti gli scenari di test e viene descritto il processo di test utilizzato per ogni scenario. Per informazioni dettagliate, ad esempio i risultati dei test e i parametri specifici, vedere la sezione dedicata ai risultati dei test più avanti in questo articolo.

Nome test	Descrizione test
Elenco esterno	Rendering di un elenco esterno tipico. Modifica delle caratteristiche dell'elenco esterno (numero di elementi, dimensioni degli elementi e così via) per verificare l'effetto sulla velocità effettiva e sulla latenza.
Pagina del profilo	Rendering di una pagina del profilo tipica. Modifica delle caratteristiche della pagina del profilo (numero di elementi per associazione, dimensioni degli elementi e così via) per verificare l'effetto sulla velocità effettiva e sulla latenza.

Set di dati

La capacità e le prestazioni degli elenchi esterni e delle pagine del profilo dipendono in larga misura dal volume di dati elaborato. Per gli elenchi esterni, la quantità di dati elaborata è determinata da tre variabili: il numero di elementi nell'elenco esterno, il numero di colonne per elemento e le dimensioni di ogni elemento. Nella tabella seguente sono descritti gli elenchi esterni rappresentativi utilizzati per il testing.

Elenco esterno	Piccole dimensioni	Medie dimensioni	Grandi dimensioni
Numero di elementi	500	2.000	4.000
Numero di colonne per elemento	25	25	25
Dimensioni elemento	2 KB	4 KB	8 KB

Per le pagine del profilo, la quantità di dati elaborata dipende dal numero e dalla complessità delle associazioni utilizzate. Un'associazione consente di collegare tipi di contenuto esterno correlati in un sistema. Una pagina del profilo può contenere più associazioni e ogni associazione può includere numerosi elementi. Nella tabella seguente sono descritte le pagine del profilo rappresentative utilizzate per il testing.

Pagina del profilo	Piccole dimensioni	Medie dimensioni	Grandi dimensioni
Numero di associazioni	2	2	10
Numero di elementi per associazione	100	500	2.500
Dimensioni elemento	4 KB	4 KB	4 KB

Carico di lavoro

Tramite i test è stato misurato l'effetto della velocità effettiva e della latenza nelle pagine del profilo e negli elenchi esterni. I test sono stati progettati per aiutare gli sviluppatori a valutare in che modo la velocità effettiva e la latenza rispondono alle modifiche apportate alle variabili seguenti:

• Numero di server Web front-end.

• Numero di elementi nell'elenco esterno.

• Dimensioni dell'elenco esterno.

• Numero di elementi per associazione.

• Metodo di autenticazione (modalità pass-through o autenticazione del servizio di archiviazione sicura).

• Origine dati esterna (servizio Web Windows Communication Foundation (WCF) o database di SQL Server).

• Carico nel server Web front-end misurato come utilizzo della CPU.

I valori specifici della capacità e delle prestazioni elencati in questo articolo sono diversi da quelli degli ambienti reali. I valori presentati hanno lo scopo di offrire un punto di partenza per la progettazione di un ambiente con scalabilità appropriata. Dopo aver completato una progettazione iniziale del sistema, testare la configurazione per determinare se il sistema sarà in grado di supportare i fattori specifici del proprio ambiente.

Definizione di area verde e di area rossa

Per ogni configurazione, sono stati eseguiti due test per determinare un'area verde, ovvero la velocità effettiva consigliata che può essere supportata, e un'area rossa, ovvero la velocità effettiva massima che può essere tollerata per un breve intervallo di tempo ma che è consigliabile evitare.

Per determinare i carichi utente dell'area verde e dell'area rossa, è stato innanzitutto eseguito un test in diversi passaggi, che è stato arrestato quando sono state soddisfatte le condizioni seguenti:

• Per l'area verde, tutti i server Web front-end nella farm presentano un utilizzo della CPU del 40-50% in modo coerente. Questo risultato viene ottenuto aumentando il carico utente utilizzato e definendo tempi interazione utente nei test, pertanto ogni test può avere un carico utente diverso.

• Per l'area rossa, tutti i server Web front-end nella farm presentano un utilizzo della CPU del 90-99% in modo coerente. Questo risultato viene ottenuto aumentando il carico utente utilizzato nei test, pertanto ogni test può avere un carico utente diverso.

Hardware, impostazioni e topologia

In questa sezione vengono descritti l'hardware, le impostazioni e le topologie utilizzati nel test.

Hardware di laboratorio

Per offrire informazioni dettagliate sui risultati dei test, sono state utilizzate diverse configurazioni di farm per i test. Le configurazioni di farm includono da uno a quattro server Web e un solo computer server di database in cui viene eseguito il software di database Microsoft SQL Server 2008.

Nella tabella seguente sono elencati i componenti hardware specifici utilizzati per i test.

	Server Web front-end	Server applicazioni	Server di database	Sistema esterno
Processori	2 processori a 2,33 GHz (4 core)	2 processori a 2,33 GHz (4 core)	4 processori a 3,2 GHz (4 core)	4 processori a 3,2 GHz (4 core)
RAM	8 GB	8 GB	32 GB	32 GB
Sistema operativo	Windows Server 2008 R1 (x64)	Windows Server 2008 R1 (x64)	Windows Server 2008 R1 (x64)	Windows Server 2008 R1 (x64)
Numero di schede di rete	2	2	2	2
Velocità delle schede di rete	1 GB	1 GB	1 GB	1 GB
Autenticazione	NTLM	NTLM	NTLM	NTLM
Versione software	SharePoint Server 2010 (versione non definitiva)	SharePoint Server 2010 (versione non definitiva)	SQL Server 2008	SQL Server 2008

Per i test sono stati utilizzati due sistemi esterni: un database e un servizio Web WCF. I sistemi esterni sono stati ospitati in un computer fisico distinto (informazioni dettagliate disponibili nella tabella relativa all'hardware). Nell'elenco seguente vengono descritti i due sistemi esterni:

• Servizio Web WCF Servizio Web WCF che restituisce dati in memoria memorizzati nella cache. I dati vengono archiviati in modo efficiente in una tabella hash e restituiti immediatamente dopo essere stati chiamati da Servizi di integrazione applicativa. I dati sono costituiti da 8000 righe da 25 campi ognuna, di tipi .NET diversi.

• Database Tabella con 25 colonne, tipi di dati diversi e 8000 righe. La tabella si trova in un database distinto ospitato in SQL Server 2008.

Topologia

La CPU e la memoria nel server Web front-end rappresentano importanti fattori limitanti per la velocità effettiva. Per i modelli di autenticazione di Servizi di integrazione applicativa che richiedono chiamate al servizio di archiviazione sicura, è anche necessario prendere in considerazione la CPU nel server applicazioni.

La topologia è stata diversificata aggiungendo ulteriori server Web front-end.

Topologia di pianificazione della capacità di Servizi di integrazione applicativa

Risultati dei test

Nelle sezioni seguenti sono illustrati i risultati dei test di Servizi di integrazione applicativa in SharePoint Server 2010. Per ogni gruppo di test, vengono modificate solo determinate variabili specifiche, per illustrare l'effetto progressivo sulle prestazioni della farm.

Nei grafici dei test viene utilizzata la legenda seguente per descrivere il set di dati:

Sistema esterno, Tipo di test, [Autenticazione], [Numero di associazioni], Dimensioni elemento, Numero di elementi, Carico CPU

Elemento	Descrizione
Sistema esterno	Origine dati esterna: WCF (servizio Web WCF) o DB (database).
Tipo di test	Tipo di test: EL (External List, elenco esterno) o PP (Profile Page, pagina del profilo).
Autenticazione	Metodo di autenticazione: SSS (viene utilizzata una modalità di autenticazione del servizio di archiviazione sicura, ad esempio WindowsCredentials). Se non è specificato SSS, durante i test è stata utilizzata la modalità pass-through.
Numero di associazioni	Numero di associazioni nella pagina del profilo (ad esempio 2A). Questo elemento si applica solo ai test della pagina del profilo.
Dimensioni elemento	Dimensioni dell'elemento (in KB).
Numero di elementi	Numero di elementi nell'elenco esterno o numero di elementi per associazione.
Carico CPU	Carico CPU: RZ (Red Zone, area rossa) se l'utilizzo della CPU del server Web front-end supera il 90% oppure GZ (Green Zone, area verde) se l'utilizzo della CPU del server Web front-end è compreso tra il 40% e il 50%.

Tutti i test relativi all'area rossa descritti in questo articolo sono stati effettuati senza un tempo interazione utente, ovvero un ritardo naturale tra operazioni consecutive. In un ambiente reale, ogni operazione è seguita da un ritardo dovuto al tempo necessario all'utente per eseguire il passaggio successivo dell'attività. Durante i test relativi all'area rossa, invece, ogni operazione è seguita immediatamente da quella successiva, provocando un carico continuo sulla farm. Questo carico comporta conflitti tra database e altri fattori che possono avere un effetto negativo sulle prestazioni.

Effetto del numero di server Web front-end sulla latenza

Nei grafici seguenti sono illustrati i risultati dei test relativi all'effetto del numero di server Web front-end sulla latenza. I risultati dei test sono distribuiti in più grafici per semplificare il confronto delle variabili correlate.

Grafico 1:

Nel grafico seguente sono illustrati i risultati dei test relativi agli elenchi esterni. Il grafico può essere utilizzato per confrontare l'effetto del sistema esterno (database o servizio Web WCF) e del carico della CPU (area rossa o area verde) sulle prestazioni.

Grafico 1: Effetto del numero di server Web front-end sulla latenza

Nell'elenco seguente viene descritto il set di dati utilizzato:

• WCF,EL,4k,500,RZ: elenco esterno con 500 elementi, 4 KB di dati per elemento, sistema esterno costituito da un servizio Web WCF e utilizzo della CPU del server Web front-end superiore al 90%.

• WCF,EL,4k,500,GZ: elenco esterno con 500 elementi, 4 KB di dati per elemento, sistema esterno costituito da un servizio Web WCF e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• DB,EL,4k,500,GZ: elenco esterno con 500 elementi, 4 KB di dati per elemento, sistema esterno costituito da un database e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

Grafico 2:

Nel grafico seguente sono illustrati i risultati dei test relativi alle pagine del profilo. Il grafico può essere utilizzato per confrontare l'effetto del sistema esterno (database o servizio Web WCF) e del carico della CPU (area rossa o area verde) sulle prestazioni.

Grafico 2: Effetto del numero di server Web front-end sulla latenza

Come illustrato nel grafico 1 e nel grafico 2, il tempo medio di risposta delle pagine rimane quasi uguale per gli scenari relativi all'area verde e all'area rossa, nonostante l'aggiunta di ulteriori utenti e server Web front-end. Durante i test è stato aumentato il carico utente per mantenere tutti i server Web front-end nell'intervallo di attività della CPU necessario. Vi è comunque un miglioramento delle prestazioni in quanto, con l'aumento del numero di server Web front-end nella farm, SharePoint Server è in grado di servire un numero maggiore di utenti con la stessa velocità. Vi è un miglioramento notevole, approssimativamente di cinque volte, per i case dell'area verde rispetto a quelli dell'area rossa. È pertanto consigliabile mantenere l'utilizzo della CPU del server Web front-end nell'intervallo compreso tra il 40% e il 50%.

Nell'elenco seguente viene descritto il set di dati utilizzato:

• WCF,PP,2A,100,RZ: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un servizio Web WCF e utilizzo della CPU del server Web front-end superiore al 90%.

• DB,PP,2A,100,RZ: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un database e utilizzo della CPU del server Web front-end superiore al 90%.

• WCF,PP,2A,100,GZ: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un servizio Web WCF e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• DB,PP,2A,100,GZ: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un database e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

Grafico 3:

Nel grafico seguente sono illustrati i risultati dei test relativi all'area rossa. I dati analoghi vengono appaiati, in modo che l'unica variabile sia costituita dall'autenticazione utilizzata. Questi dati possono essere utilizzati per determinare se l'utilizzo del servizio di archiviazione sicura influisce sulle prestazioni.

Nota

I test sono stati eseguiti utilizzando un ambiente lab. La modalità pass-through è stata utilizzata solo per il confronto. Questi test non implicano la necessità di utilizzare la modalità pass-through per l'autenticazione.

Grafico 3: Effetto del numero di server Web front-end sulla latenza

Negli scenari relativi all'area rossa, il servizio di archiviazione sicura non sembra comportare un sovraccarico considerevole in relazione al tempo medio di risposta delle pagine. Questo risultato può essere attribuito al fatto che il sovraccarico del servizio di archiviazione sicura è oscurato da un fattore più importante, ovvero il carico utente elevato. Nella maggior parte dei casi, i risultati sono simili sia in caso di utilizzo che di non utilizzo del servizio di archiviazione sicura.

Tenere inoltre presente che il servizio di archiviazione sicura ha un effetto minimo sui server applicazioni.

Nell'elenco seguente viene descritto il set di dati utilizzato:

• WCF,EL,4k,500,RZ: elenco esterno con 500 elementi, 4 KB di dati per elemento, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione pass-through e utilizzo della CPU del server Web front-end superiore al 90%.

• WCF,EL,SSS,4k,500,RZ: elenco esterno con 500 elementi, 4 KB di dati per elemento, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end superiore al 90%.

• WCF,PP,2A,100,RZ: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione pass-through e utilizzo della CPU del server Web front-end superiore al 90%.

• WCF,PP,SSS,2A,100,RZ: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end superiore al 90%.

• DB,EL,SSS,4k,500,RZ: elenco esterno con 500 elementi, 4 KB di dati per elemento, sistema esterno costituito da un database, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end superiore al 90%.

• DB,PP,2A,100,RZ: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un database, modalità di autenticazione pass-through e utilizzo della CPU del server Web front-end superiore al 90%.

Grafico 4:

Nel grafico seguente sono illustrati i risultati dei test relativi all'area verde. I dati analoghi vengono appaiati, in modo che l'unica variabile sia costituita dall'autenticazione utilizzata. Il set di dati simile può essere utilizzato per determinare se l'utilizzo del servizio di archiviazione sicura influisce sulle prestazioni.

Nota

I test sono stati eseguiti utilizzando un ambiente lab. La modalità pass-through è stata utilizzata solo per il confronto. Questi test non implicano la necessità di utilizzare la modalità pass-through per l'autenticazione.

Grafico 4: Effetto del numero di server Web front-end sulla latenza

Il sovraccarico associato con il servizio di archiviazione sicura diventa più evidente per le pagine del profilo durante scenari di carico tipici. Per le pagine del profilo si verifica un piccolo aumento del tempo medio di risposta delle pagine, di circa 20 millisecondi.

Nell'elenco seguente viene descritto il set di dati utilizzato:

• WCF,EL,4k,500,GZ: elenco esterno con 500 elementi, 4 KB di dati per elemento, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione pass-through e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• WCF,EL,SSS,4k,500,GZ: elenco esterno con 500 elementi, 4 KB di dati per elemento, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• WCF,PP,2A,100,GZ: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione pass-through e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• WCF,PP,SSS,2A,100,GZ: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• DB,EL,4k,500,GZ: elenco esterno con 500 elementi, 4 KB di dati per elemento, sistema esterno costituito da un database, modalità di autenticazione pass-through e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• DB,EL,SSS,4k,500,GZ: elenco esterno con 500 elementi, 4 KB di dati per elemento, sistema esterno costituito da un database, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• DB,PP,2A,100,GZ: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un database, modalità di autenticazione pass-through e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• DB,PP,SSS,2A,100,GZ: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un database, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

Effetto del numero di server Web front-end sulla velocità effettiva

Grafico 1:

Nel grafico seguente sono illustrati i risultati dei test relativi agli elenchi esterni in relazione al numero di richieste al secondo (RPS, request per second). Il grafico può essere utilizzato per confrontare l'effetto del carico della CPU (area rossa o area verde) sulle prestazioni.

Grafico 1: Effetto del numero di server Web front-end sulla velocità effettiva

Nell'elenco seguente viene descritto il set di dati utilizzato:

• WCF,EL,4k,500,RZ,RPS: elenco esterno con 500 elementi, 4 KB di dati per elemento, sistema esterno costituito da un servizio Web WCF e utilizzo della CPU del server Web front-end superiore al 90%.

• WCF,EL,4k,500,GZ,RPS: elenco esterno con 500 elementi, 4 KB di dati per elemento, sistema esterno costituito da un servizio Web WCF e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

Grafico 2:

Nel grafico seguente sono illustrati i risultati dei test relativi alle pagine del profilo in relazione al numero di richieste al secondo (RPS, request per second). Il grafico può essere utilizzato per confrontare l'effetto del sistema esterno (database o servizio Web WCF) e del carico della CPU (area rossa o area verde) sulle prestazioni.

Grafico 2: Effetto del numero di server Web front-end sulla velocità effettiva

Come illustrato nel grafico 1 e nel grafico 2, il numero di richieste al secondo aumenta in modo lineare fino all'aggiunta del terzo server Web front-end. Dopodiché, la tendenza diventa logaritmica o sublineare. Sebbene l'aggiunta di ulteriori server Web front-end alla farm comporti maggiori vantaggi, comporta anche un valore minore rispetto al costo. In particolare, l'aggiunta di un quarto server Web front-end offre un vantaggio piuttosto piccolo.

Nell'elenco seguente viene descritto il set di dati utilizzato:

• WCF,PP,2A,100,RZ,RPS: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un servizio Web WCF e utilizzo della CPU del server Web front-end superiore al 90%.

• DB,PP,2A,100,RZ,RPS: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un database e utilizzo della CPU del server Web front-end superiore al 90%.

• WCF,PP,2A,100,GZ,RPS: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un servizio Web WCF e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• DB,PP,2A,100,GZ,RPS: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un database e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

Grafico 3:

Nel grafico seguente sono illustrati i risultati dei test relativi all'area rossa in relazione al numero di richieste al secondo (RPS, request per second). I dati analoghi vengono appaiati, in modo che l'unica variabile sia costituita dall'autenticazione utilizzata. I risultati possono essere utilizzati per determinare se l'utilizzo del servizio di archiviazione sicura influisce sulle prestazioni.

Nota

I test sono stati eseguiti utilizzando un ambiente lab. La modalità pass-through è stata utilizzata solo per il confronto. Questi test non implicano la necessità di utilizzare la modalità pass-through per l'autenticazione.

Grafico 3: Effetto del numero di server Web front-end sulla velocità effettiva

Nell'elenco seguente viene descritto il set di dati utilizzato:

• WCF,EL,4k,500,RZ,RPS: elenco esterno con 500 elementi, 4 KB di dati per elemento, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione pass-through e utilizzo della CPU del server Web front-end superiore al 90%.

• WCF,EL,SSS,4k,500,RZ,RPS: elenco esterno con 500 elementi, 4 KB di dati per elemento, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end superiore al 90%.

• WCF,PP,2A,100,RZ,RPS: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione pass-through e utilizzo della CPU del server Web front-end superiore al 90%.

• WCF,PP,SSS,2A,100,RZ,RPS: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end superiore al 90%.

• DB,EL,4k,500,RZ,RPS: elenco esterno con 500 elementi, 4 KB di dati per elemento, sistema esterno costituito da un database, modalità di autenticazione pass-through e utilizzo della CPU del server Web front-end superiore al 90%.

• DB,EL,SSS,4k,500,RZ,RPS: elenco esterno con 500 elementi, 4 KB di dati per elemento, sistema esterno costituito da un database, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end superiore al 90%.

• DB,PP,2A,100,RZ;RPS: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un database, modalità di autenticazione pass-through e utilizzo della CPU del server Web front-end superiore al 90%.

• DB,PP,SSS,2A,100,RZ,RPS: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un database, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end superiore al 90%.

Grafico 4:

Nel grafico seguente sono illustrati i risultati dei test relativi all'area verde in relazione al numero di richieste al secondo (RPS, request per second). I dati analoghi vengono appaiati, in modo che l'unica variabile sia costituita dall'autenticazione utilizzata. I risultati possono essere utilizzati per determinare se l'utilizzo del servizio di archiviazione sicura influisce sulle prestazioni.

Nota

I test sono stati eseguiti utilizzando un ambiente lab. La modalità pass-through è stata utilizzata solo per il confronto. Questi test non implicano la necessità di utilizzare la modalità pass-through per l'autenticazione.

Grafico 4: Effetto del numero di server Web front-end sulla velocità effettiva

Come illustrato nel grafico 3 e nel grafico 4, il sovraccarico del servizio di archiviazione sicura comporta, in alcuni casi, valori inferiori relativi al numero di richieste al secondo. La tendenza logaritmica lineare è tuttavia simile e nella maggior parte dei casi la differenza nel numero di richieste al secondo in caso di utilizzo o in caso di non utilizzo del servizio di archiviazione sicura è minima.

Nell'elenco seguente viene descritto il set di dati utilizzato:

• WCF,EL,4k,500,GZ,RPS: elenco esterno con 500 elementi, 4 KB di dati per elemento, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione pass-through e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• WCF,EL,SSS,4k,500,GZ,RPS: elenco esterno con 500 elementi, 4 KB di dati per elemento, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• WCF,PP,2A,100,GZ,RPS: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione pass-through e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• WCF,PP,SSS,2A,100,GZ,RPS: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• DB,EL,4k,500,GZ,RPS: elenco esterno con 500 elementi, 4 KB di dati per elemento, sistema esterno costituito da un database, modalità di autenticazione pass-through e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• DB,EL,SSS,4k,500,GZ,RPS: elenco esterno con 500 elementi, 4 KB di dati per elemento, sistema esterno costituito da un database, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• DB,PP,2A,100,GZ,RPS: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un database, modalità di autenticazione pass-through e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• DB,PP,SSS,2A,GZ,RPS: pagina del profilo con 2 associazioni, 100 elementi per associazione, sistema esterno costituito da un database, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

Effetto delle dimensioni degli elementi sulla latenza

Nel grafico seguente sono illustrati i risultati dei test relativi all'effetto delle dimensioni degli elementi esterni sulla latenza. Nei test sono state aumentate le dimensioni degli elementi dell'elenco esterno ed è stato misurato l'effetto sulla latenza.

Effetto delle dimensioni degli elementi sulla latenza

Nell'elenco seguente viene descritto il set di dati utilizzato:

• WCF,EL,500,RZ: elenco esterno con 500 elementi, sistema esterno costituito da un servizio Web WCF e utilizzo della CPU del server Web front-end superiore al 90%.

• WCF,EL,SSS,500,RZ: elenco esterno con 500 elementi, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end superiore al 90%.

• WCF,EL,500,GZ: elenco esterno con 500 elementi, sistema esterno costituito da un servizio Web WCF e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• WCF,EL,SSS,500,GZ: elenco esterno con 500 elementi, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

Effetto delle dimensioni degli elementi sulla velocità effettiva

Nel grafico seguente sono illustrati i risultati dei test relativi all'effetto delle dimensioni degli elementi esterni sulla velocità effettiva, misurata in numero di richieste al secondo (RPS, request per second). Nei test sono state aumentate le dimensioni degli elementi dell'elenco esterno ed è stato misurato l'effetto sulla velocità effettiva.

Effetto delle dimensioni degli elementi sulla velocità effettiva

Le prestazioni in termini di richieste al secondo scendono sempre al di sotto di un indicatore lineare con l'aumentare delle dimensioni degli elementi. Condizioni di carichi elevati comportano un numero maggiore di richieste al secondo. Come illustrato nei risultati dei test precedenti, tuttavia, le condizioni di carichi elevati possono anche provocare un aumento dei tempi di risposta delle pagine.

Nell'elenco seguente viene descritto il set di dati utilizzato:

• WCF,EL,500,RZ: elenco esterno con 500 elementi, sistema esterno costituito da un servizio Web WCF e utilizzo della CPU del server Web front-end superiore al 90%.

• WCF,EL,SSS,500,RZ: elenco esterno con 500 elementi, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end superiore al 90%.

• WCF,EL,500,GZ: elenco esterno con 500 elementi, sistema esterno costituito da un servizio Web WCF e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• WCF,EL,SSS,500,GZ: elenco esterno con 500 elementi, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

Effetto del numero di elementi sulla latenza

Nel grafico seguente sono illustrati i risultati dei test relativi all'effetto del numero di elementi sulla latenza. Nei test è stato aumentato il numero di elementi dell'elenco esterno ed è stato misurato il tempo necessario per il rendering della pagina.

Effetto del numero di elementi sulla latenza

Nell'elenco seguente viene descritto il set di dati utilizzato:

• WCF,EL,4k,RZ: elenco esterno con un numero variabile di elementi, 4 KB di dati per elemento, sistema esterno costituito da un servizio Web WCF e utilizzo della CPU del server Web front-end superiore al 90%.

• WCF,EL,SSS,4k,RZ: elenco esterno con un numero variabile di elementi, 4 KB di dati per elemento, sistema esterno costituito da un servizio WCF, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end superiore al 90%.

• DB,EL,4k,RZ: elenco esterno con un numero variabile di elementi, 4 KB di dati per elemento, sistema esterno costituito da un database e utilizzo della CPU del server Web front-end superiore al 90%.

• DB,EL,SSS,4k,RZ: elenco esterno con un numero variabile di elementi, 4 KB di dati per elemento, sistema esterno costituito da un database, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end superiore al 90%.

• WCF,EL,4k,GZ: elenco esterno con un numero variabile di elementi, 4 KB di dati per elemento, sistema esterno costituito da un servizio Web WCF e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• WCF,EL,SSS,4k,GZ: elenco esterno con un numero variabile di elementi, 4 KB di dati per elemento, sistema esterno costituito da un servizio WCF, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• DB,EL,4k,GZ: elenco esterno con un numero variabile di elementi, 4 KB di dati per elemento, sistema esterno costituito da un database e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• DB,EL,SSS,4k,GZ: elenco esterno con un numero variabile di elementi, 4 KB di dati per elemento, sistema esterno costituito da un database, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

Effetto del numero di elementi sulla velocità effettiva

Nel grafico seguente sono illustrati i risultati dei test relativi all'effetto del numero di elementi sulla velocità effettiva, misurata in numero di richieste al secondo (RPS, request per second). Nei test è stato aumentato il numero di elementi dell'elenco esterno ed è stato misurato l'effetto sulla velocità effettiva.

Effetto del numero di elementi sulla velocità effettiva

Come illustrato in questo grafico, il numero di richieste al secondo diminuisce in modo quasi lineare con l'aumentare del numero di elementi. Rispetto ai test precedenti relativi all'effetto delle dimensioni degli elementi, l'aumento del numero di elementi sembra influenzare maggiormente le prestazioni, rispetto all'aumento delle dimensioni degli elementi.

Nell'elenco seguente viene descritto il set di dati utilizzato:

• WCF,EL,4k,RZ,RPS: elenco esterno con un numero variabile di elementi, 4 KB di dati per elemento, sistema esterno costituito da un servizio Web WCF e utilizzo della CPU del server Web front-end superiore al 90%.

• WCF,EL,SSS,4k,RZ,RPS: elenco esterno con un numero variabile di elementi, 4 KB di dati per elemento, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end superiore al 90%.

• DB,EL,4k,RZ,RPS: elenco esterno con un numero variabile di elementi, 4 KB di dati per elemento, sistema esterno costituito da un database e utilizzo della CPU del server Web front-end superiore al 90%.

• DB,EL,SSS,4k,RZ,RPS: elenco esterno con un numero variabile di elementi, 4 KB di dati per elemento, sistema esterno costituito da un database, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end superiore al 90%.

• WCF,EL,4k,GZ,RPS: elenco esterno con un numero variabile di elementi, 4 KB di dati per elemento, sistema esterno costituito da un servizio Web WCF e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• WCF,EL,SSS,4k,GZ,RPS: elenco esterno con un numero variabile di elementi, 4 KB di dati per elemento, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• DB,EL,4k,GZ,RPS: elenco esterno con un numero variabile di elementi, 4 KB di dati per elemento, sistema esterno costituito da un database e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• DB,EL,SSS,4k,GZ,RPS: elenco esterno con un numero variabile di elementi, 4 KB di dati per elemento, sistema esterno costituito da un database, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

Effetto del numero di elementi per associazione sulla latenza

Nel grafico seguente sono illustrati i risultati dei test relativi all'effetto del numero di elementi di un'associazione sulla latenza. Nei test è stato aumentato il numero di elementi di un'associazione ed è stato misurato il tempo necessario per il rendering della pagina.

Effetto del numero di elementi per associazione sulla latenza

Nell'elenco seguente viene descritto il set di dati utilizzato:

• WCF,PP,2A,RZ: pagina del profilo con 2 associazioni, sistema esterno costituito da un servizio Web WCF e utilizzo della CPU del server Web front-end superiore al 90%.

• WCF,PP,SSS,2A,RZ: pagina del profilo con 2 associazioni, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end superiore al 90%.

• DB,PP,2A,GZ: pagina del profilo con 2 associazioni, sistema esterno costituito da un database e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• DB,PP,SSS,2A,GZ: pagina del profilo con 2 associazioni, sistema esterno costituito da un database, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

Effetto del numero di elementi per associazione sulla velocità effettiva

Nel grafico seguente sono illustrati i risultati dei test relativi all'effetto del numero di elementi di un'associazione sulla velocità effettiva, misurata in numero di richieste al secondo (RPS, request per second). Nei test è stato aumentato il numero di elementi di un'associazione ed è stato misurato l'effetto sulla velocità effettiva.

Effetto del numero di elementi per associazione sulla velocità effettiva

Nell'elenco seguente viene descritto il set di dati utilizzato:

• WCF,PP,2A,RZ: pagina del profilo con 2 associazioni, sistema esterno costituito da un servizio Web WCF e utilizzo della CPU del server Web front-end superiore al 90%.

• WCF,PP,SSS,2A,RZ: pagina del profilo con 2 associazioni, sistema esterno costituito da un servizio Web WCF, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end superiore al 90%.

• DB,PP,2A,GZ: pagina del profilo con 2 associazioni, sistema esterno costituito da un database e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

• DB,PP,SSS,2A,GZ: pagina del profilo con 2 associazioni, sistema esterno costituito da un database, modalità di autenticazione del servizio di archiviazione sicura (ad esempio WindowsCredentials) e utilizzo della CPU del server Web front-end compreso tra il 40% e il 50%.

Suggerimenti

In questa sezione vengono forniti suggerimenti generali sulle prestazioni e sulla capacità che consentono di determinare le caratteristiche di capacità e prestazioni della topologia iniziale creata in modo da decidere se sarà necessario applicare la scalabilità orizzontale o verticale a tale topologia.

Consigli per i componenti hardware

Per informazioni specifiche sui requisiti di sistema minimi e consigliati, vedere Requisiti hardware e software (SharePoint Server 2010) ().

Nota

I requisiti di memoria per i server Web e i server di database dipendono dalle dimensioni della farm, dal numero di utenti simultanei e dalla complessità delle caratteristiche e delle pagine della farm. I consigli relativi alla memoria nella tabella seguente possono essere sufficienti per una farm di piccole dimensioni o utilizzata in modo poco intensivo. È tuttavia necessario monitorare attentamente l'utilizzo della memoria per determinare se è necessario aggiungerne ulteriore.

Consigli relativi alle prestazioni di Servizi di integrazione applicativa

In questa sezione vengono forniti consigli relativi alle prestazioni per l'utilizzo di elenchi esterni e pagine del profilo, nonché consigli generali relativi alle prestazioni per Servizi di integrazione applicativa.

Consigli relativi agli elenchi esterni

Nella tabella seguente viene descritto come vengono spostati i dati dal sistema esterno in un elenco esterno.

Carico	Processo	Rendering
Tramite Servizi di integrazione applicativa Microsoft viene eseguita una query sul sistema esterno e i dati restituiti vengono caricati in SharePoint Server.	Vengono eseguite ulteriori operazioni di elaborazione (ordinamento, filtro, raggruppamento) sui dati caricati.	Viene eseguito il rendering degli elementi nella pagina dall'elenco esterno.

In Servizi di integrazione applicativa Microsoft non è disponibile una cache in memoria per gli elementi esterni. Le operazioni di caricamento, elaborazione e rendering dei dati devono essere eseguite ogni volta che un elenco esterno viene aggiornato. Molti di questi consigli sono pertanto finalizzati a limitare la quantità di dati da elaborare.

Di seguito sono elencati i consigli relativi agli elenchi esterni:

• Limitare il più possibile il numero di elementi da elaborare limitando il numero di righe restituite dal sistema esterno. Questo fattore è fondamentale per le prestazioni degli elenchi esterni. È consigliabile mantenere il numero di righe restituite tra 100 e 500. Le righe restituite dal sistema esterno non devono essere più di 2000. È possibile utilizzare filtri per limitare il numero di elementi restituiti dal sistema esterno. Per ulteriori informazioni sui filtri, vedere Procedura: Creare un tipo di contenuto esterno basato su una tabella di SQL Server (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=192184&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

• Il rendering di un elenco comporta un utilizzo intensivo della CPU nel server Web front-end e nel server applicazioni. Il numero di elementi di cui viene eseguito il rendering è diverso dal numero totale di elementi caricati ed elaborati. Il numero di elementi di cui viene eseguito il rendering dipende dalla configurazione della visualizzazione dell'elenco esterno. Considerare l'esperienza utente globale e il numero di elementi che possono essere visualizzati comodamente su uno schermo e mantenere su un livello ragionevole il numero di elementi di cui viene eseguito il rendering in una pagina. È consigliabile mantenere questo numero intorno ai 30 elementi per pagina (impostazione predefinita).

• Mantenere su un livello ragionevole il numero di colonne in un elenco esterno. Un numero elevato di colonne può influire sulle prestazioni nonché comportare un'esperienza utente poco soddisfacente (numero di colonne troppo elevato per essere comodamente visualizzato sullo schermo).

• Non includere colonne di grandi dimensioni (in particolare stringhe) nelle visualizzazioni elenco. Le colonne di dimensioni maggiori di 1 KB non devono essere incluse in una visualizzazione elenco. Il tipo di contenuto esterno può comunque includere colonne di grandi dimensioni, che devono tuttavia essere visualizzate solo nella visualizzazione a elementi singoli.

• Quando si progetta un elenco esterno, configurare la visualizzazione predefinita in base a quella che si ritiene sia la preferita dagli utenti. La modifica dell'ordinamento o del filtro in una visualizzazione richiede il caricamento, l'elaborazione e il rendering dei dati.

Consigli relativi alla pagina del profilo

• Il numero di associazioni è un fattore fondamentale per le prestazioni delle pagine del profilo. Per garantire prestazioni ottimali, è consigliabile limitare il numero di associazioni a non più di 2.

• Con un numero maggiore di elementi per associazione è possibile prevedere prestazioni minori, sia per quanto riguarda la velocità effettiva che la latenza.

Consigli generali relativi a Servizi di integrazione applicativa

• È stato riscontrato un miglioramento notevole, approssimativamente di cinque volte, nelle prestazioni per quanto riguarda l'effetto del numero di server Web front-end sulla latenza e nei case dell'area verde rispetto a quelli dell'area rossa. È consigliabile mantenere l'utilizzo della CPU del server Web front-end nell'intervallo compreso tra il 40% e il 50%.

• Il numero di elementi sembra avere un effetto sulle prestazioni maggiore rispetto alle dimensioni degli elementi. Se si controlla l'origine dati esterna, per ottenere risultati migliori mantenere elevate le dimensioni degli elementi e basso il numero di elementi. Prendere ad esempio in considerazione l'idea di aggregare dati di grandi dimensioni in un singolo elemento anziché suddividere i dati in numerosi elementi.

• Anche i livelli di registrazione diagnostica per Servizi di integrazione applicativa Microsoft possono rappresentare un fattore importante per la latenza e la velocità effettiva percepite dagli utenti. Mantenere i livelli di registrazione al minimo consentito in base alle esigenze aziendali per un utilizzo regolare. Impostare temporaneamente un livello di dettaglio maggiore per la registrazione solo quando è necessario un monitoraggio più approfondito.

• Le prestazioni del sistema esterno giocano un ruolo importante per le prestazioni di Servizi di integrazione applicativa. Considerare la latenza e la velocità effettiva del sistema esterno quando si pianificano la capacità e le prestazioni.

Topologie con scalabilità verticale e orizzontale

È possibile stimare le prestazioni della topologia di partenza confrontando la propria topologia con quelle descritte in Pianificare la disponibilità (SharePoint Server 2010) (https://go.microsoft.com/fwlink/?linkid=189518&clcid=0x410). In questo modo, sarà possibile determinare in modo rapido se, per soddisfare gli obiettivi di prestazioni e capacità, è necessaria scalabilità orizzontale o verticale per la topologia.

Per aumentare la capacità e le prestazioni di una delle topologie di partenza, è possibile implementare la scalabilità verticale aumentando la capacità dei computer server esistenti oppure implementare la scalabilità orizzontale aggiungendo ulteriori server alla topologia. In questa sezione vengono descritte le caratteristiche di prestazioni generali di diverse topologie con scalabilità orizzontale. Le topologie di esempio rappresentano le modalità comuni seguenti di implementazione della scalabilità orizzontale.

• Per consentire un carico utente maggiore, aggiungere computer server Web.

• Per consentire un carico di dati maggiore, aggiungere capacità al ruolo del server di database aumentando la capacità di un singolo server (in cluster o con mirroring), eseguendo l'aggiornamento a un server a 64 bit oppure aggiungendo server in cluster o con mirroring.

• Mantenere un rapporto di non più di otto computer server Web (in cluster o con mirroring) a un computer server di database (in cluster o con mirroring). Anche se dai test è emerso un rapporto ottimale specifico tra server Web e server di database per ogni scenario, la distribuzione di hardware più robusto, in particolare per il server di database, può consentire risultati migliori nell'ambiente.

Stima degli obiettivi di velocità effettiva

Molti fattori possono influire sulla velocità effettiva, tra cui i seguenti:

• Numero di utenti

• Tipo, complessità e frequenza delle operazioni utente

• Numero di postback in un'operazione

• Prestazioni delle connessioni dati

Ognuno di questi fattori può avere un effetto significativo sulla velocità effettiva della farm. Considerare con attenzione ognuno di questi fattori quando si pianifica la distribuzione.

È possibile distribuire e configurare SharePoint Server 2010 in diversi modi. Non esiste pertanto una soluzione semplice per stimare il numero di utenti che possono essere supportati da un determinato numero di server. È necessario eseguire test nel proprio ambiente prima di distribuire SharePoint Server 2010 in un ambiente di produzione.

Ottimizzazioni

Colli di bottiglia comuni e relative cause

Durante i test delle prestazioni si sono manifestati diversi colli di bottiglia comuni. Un collo di bottiglia è una condizione in cui viene raggiunto il limite di capacità di un singolo componente di una farm. Questa situazione comporta una situazione di stasi o una diminuzione della velocità effettiva della farm.

Nella tabella seguente sono elencati alcuni colli di bottiglia comuni con le relative cause e le possibili soluzioni.

Risoluzione dei problemi di prestazioni e scalabilità

Collo di bottiglia	Causa	Soluzione
Conflitti tra database (blocchi)	I blocchi di database impediscono a più utenti di apportare modifiche in conflitto a un set di dati. Quando un set di dati viene bloccato da un utente o da un processo, nessun altro utente o processo può modificare tale set fino a quando il primo utente o processo non avrà completato la modifica dei dati e rilasciato il blocco.	Per contribuire alla riduzione dell'incidenza dei blocchi di database, eseguire le operazioni seguenti: Distribuire i moduli inviati in più raccolte documenti. Implementare la scalabilità verticale nel server di database. Ottimizzare il disco rigido del server di database per la lettura/scrittura. Sono disponibili metodi per aggirare il sistema di blocco del database in SQL Server 2005, ad esempio il parametro NOLOCK. L'utilizzo di questo metodo non è tuttavia consigliato né supportato, in quanto può danneggiare i dati.
I/O del disco del server di database	Quando il numero di richieste di I/O per un disco rigido supera la capacità di I/O del disco, le richieste vengono accodate. Di conseguenza, il tempo necessario per completare ogni richiesta aumenta.	La distribuzione di file di dati in più unità fisiche consente l'I/O parallelo. Nel blog I/O del disco e allocazione di SharePoint (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=129557&clcid=0x410) (le informazioni potrebbero essere in lingua inglese) sono disponibili numerose informazioni utili sulla risoluzione dei problemi relativi all'I/O del disco.
Utilizzo della CPU dei server Web	Quando un server Web è sovraccarico di richieste utente, l'utilizzo medio della CPU si avvicina al 100%. Il server Web non riesce pertanto a rispondere rapidamente alle richieste e può provocare timeout e messaggi di errore nei computer client.	Per risolvere questo problema, è possibile procedere in due modi. È possibile aggiungere altri server Web alla farm per distribuire il carico utente oppure implementare la scalabilità verticale per uno o più server Web aggiungendo processori più veloci. Per ulteriori informazioni, vedere Pianificare la disponibilità (SharePoint Server 2010) (https://go.microsoft.com/fwlink/?linkid=189518&clcid=0x410).

Monitoraggio delle prestazioni

Per determinare quando è necessario implementare la scalabilità verticale o orizzontale per il sistema, utilizzare i contatori delle prestazioni per monitorare l'integrità del sistema. Utilizzare le informazioni riportate nelle tabelle seguenti per stabilire quali contatori delle prestazioni monitorare e a quale processo applicarli.

Server Web

Nella tabella seguente sono indicati i contatori delle prestazioni e i processi da monitorare per i server Web della farm.

Contatore delle prestazioni	Oggetto a cui si applica	Note
Tempo processore	Totale	Indica la percentuale del tempo trascorso in cui il thread corrente ha utilizzato il processore per eseguire istruzioni.
Utilizzo memoria	Pool di applicazioni	Indica l'utilizzo medio della memoria di sistema per il pool di applicazioni. È necessario determinare il pool di applicazioni corretto da monitorare. È consigliabile determinare il picco di utilizzo della memoria per una determinata applicazione Web e assegnare tale numero più 10 al pool di applicazioni associato.

Server di database

Nella tabella seguente sono indicati i contatori delle prestazioni e i processi da monitorare per i server di database della farm.

Contatore delle prestazioni	Oggetto a cui si applica	Note
Lunghezza media coda dischi	Disco rigido contenente SharedServices.mdf	Valori medi superiori a 1,5 per asse indicano che i tempi di scrittura per tale disco rigido non sono sufficienti.
Tempo processore	Processo di SQL Server	Valori medi superiori all'80% indicano che la capacità del processore nel server di database non è sufficiente.
Tempo processore	Totale	Indica la percentuale del tempo trascorso in cui il thread corrente ha utilizzato il processore per eseguire istruzioni.
Utilizzo memoria	Totale	Indica l'utilizzo medio della memoria di sistema.

See Also

Other Resources

Centro risorse: Servizi di integrazione applicativa in SharePoint Server 2010 (le informazioni potrebbero essere in lingua inglese)