Stimare i requisiti di prestazioni e capacità per la gestione del contenuto Web in SharePoint Server 2010

 

Si applica a: SharePoint Server 2010

Ultima modifica dell'argomento: 2016-11-30

In questo articolo sono disponibili istruzioni e informazioni sulla gestione della capacità per i siti di Microsoft SharePoint Server 2010 in cui è attivata l'infrastruttura di pubblicazione. Tale documento riguarda specificamente SharePoint Server 2010 e le informazioni in esso contenute non sono valide per SharePoint Foundation.

In questo articolo vengono illustrati gli scenari seguenti:

• Un sito di pubblicazione Internet, ovvero un sito di presenza aziendale

  Questo tipo di sito viene pubblicato in Internet e consente agli utenti Internet anonimi di trovare informazioni relative a una società. I siti come questi includono informazioni personalizzate e distintive dell'azienda e il contenuto è rigidamente controllato.

• Un sito di pubblicazione Intranet, ovvero un sito di news interno

  Questo tipo di sito viene pubblicato internamente in un'organizzazione e viene utilizzato principalmente per condividere informazioni con gli utenti autenticati all'interno dell'organizzazione. Le informazioni del sito possono essere gestite rigidamente oppure per alcune aree la gestione può essere più flessibile.

• Un wiki aziendale, ovvero un archivio di conoscenze

  Un wiki aziendale è un sito costituito da un'unica farm che si espande organicamente man mano che i collaboratori creano nuove pagine e le collegano ad altre pagine che potrebbero esistere già o non esistere ancora. I wiki aziendali in genere vengono pubblicati internamente in un'organizzazione. Tale sito consente agli utenti di una società o di un'organizzazione di acquisire e condividere conoscenze mediante una soluzione integrata e potenziata dall''ambiente SharePoint.

Dopo avere letto questo documento, si comprenderanno i concetti seguenti:

• La metrica chiave (velocità effettiva) da ottimizzare per supportare numerose operazioni di lettura

• Diversi possibili colli di bottiglia che influiscono su una distribuzione di SharePoint Server 2010 per la gestione del contenuto Web

• L'importanza della cache di output per l'ottimizzazione della velocità effettiva

• L'effetto delle operazioni di scrittura sull'esperienza di lettura degli utenti finali

Contenuto dell'articolo:

• Informazioni preliminari

• Dettagli e approccio dei test

• Distribuzioni della gestione del contenuto Web

• Elementi da ottimizzare

• Risultati dei test e suggerimenti

• Informazioni sugli autori

Informazioni preliminari

Prima di leggere questo documento, verificare di avere compreso i concetti chiave alla base della gestione della capacità di SharePoint Server 2010. Nelle sezioni seguenti verrà descritto l'approccio consigliato per la gestione della capacità offrendo il contesto per un utilizzo efficace delle informazioni presentate.

Per ulteriori informazioni sui concetti relativi alle prestazioni e alla capacità utili per comprendere il contesto dei dati di questo articolo, vedere i documenti seguenti:

• Gestione della capacità e dimensionamento per SharePoint Server 2010

• Case study tecnici su prestazioni e capacità (SharePoint Server 2010)

Dettagli e approccio dei test

In ogni test le variabili che potrebbero essere presenti nel mondo reale sono state estratte in modo da visualizzare suggerimenti specifici. È quindi molto importante testare e monitorare l'ambiente di cui si dispone per verificare che la scalabilità sia stata implementata correttamente per far fronte al volume di richieste previsto. Per ulteriori informazioni sui concetti relativi alla gestione della capacità, vedere Panoramica del dimensionamento e della gestione della capacità per SharePoint Server 2010.

In questo articolo vengono illustrate le prestazioni con Caratteristiche raccolta siti, Infrastruttura di pubblicazione SharePoint Server e cache di output. Tali funzionalità sono disponibili solo quando Infrastruttura di pubblicazione SharePoint Server è attivata. Per impostazione predefinita, tale funzionalità è attivata nei portali di pubblicazione.

Set di dati

I test sono stati eseguiti utilizzando un set di dati con caratteristiche analoghe a quelle delle effettive distribuzioni della gestione del contenuto Web. Benché il carico fosse costante, sono state richieste pagine diverse. Nella tabella seguente viene descritto il set di dati utilizzato per questi test.

Set di dati

Oggetto	Sito di pubblicazione
Dimensioni del database del contenuto	2,63 GB
Numero di database del contenuto	1
Numero di raccolte siti	1
Numero di applicazioni Web	1
Numero di siti	50
Numero di pagine	20.000 pagine, divise in 20 cartelle con 1.000 pagine ognuna
Composizione delle pagine	Pagine di articoli in formato HTML di base, con riferimenti a due immagini
Dimensioni delle pagine	42 KB non compressi; 12 KB compressi
Immagini	3.000 con dimensioni da 30 KB a 1,3 MB ognuna

È consigliabile configurare Internet Information Services (IIS) in modo che i file vengano sempre compressi (ignorando l'impostazione predefinita che prevede la compressione dinamica dei file). Quando è attivata la compressione dinamica, IIS comprime le pagine finché l'utilizzo della CPU non raggiunge una determinata soglia, dopodiché smette di comprimere le pagine finché l'utilizzo non scende di nuovo al di sotto della soglia. I test descritti in questo articolo sono stati eseguiti con la compressione sempre attivata.

Per questo set di dati di testing sono state utilizzate solo le funzionalità predefinite di SharePoint Server 2010 fornite con il prodotto. Nel sito reale saranno probabilmente incluse alcune personalizzazioni oltre a queste funzionalità di base. È quindi importante testare le prestazioni della propria soluzione.

Hardware

Il numero dei server Web della farm non è stato sempre lo stesso per tutti i test. Ogni server disponeva però degli stessi componenti hardware. Nella tabella seguente viene descritto l'hardware dei server Web e dei server applicazioni utilizzato durante questi test.

Specifiche hardware per i server applicazioni e i server Web

	Server Web
Processori	2 quad core a 2,33 GHz
RAM	8 GB
Sistema operativo	Windows Server 2008, 64 bit
Dimensioni dell'unità di SharePoint	300 GB
Numero di schede di rete	2
Velocità delle schede di rete	1 gigabit
Autenticazione	Di base di Windows
Tipo di servizio di bilanciamento del carico	Bilanciamento del carico hardware
Versione software	SharePoint Server 2010 (versione non definitiva)
Servizi in esecuzione localmente	Amministrazione centrale Posta elettronica in arrivo di Microsoft SharePoint Foundation Applicazione Web Microsoft SharePoint Foundation Servizio timer flussi di lavoro Microsoft SharePoint Foundation

Nella tabella seguente viene descritto l'hardware dei server di database utilizzato durante questi test.

Specifiche hardware per i server di database

	Server di database
Processori	4 quad core a 3,19 GHz
RAM	16 GB
Sistema operativo	Windows Server 2008, 64 bit
Archiviazione	15 dischi da 300 GB @ 15.000 RPM
Numero di schede di rete	2
Velocità delle schede di rete	1 gigabit
Autenticazione	NTLM
Versione software	Microsoft SQL Server 2008

Glossario

In questo documento vengono utilizzati alcuni termini specifici. Di seguito sono riportati i termini chiave con le relative definizioni:

• RPS   (Requests Per Second, richieste al secondo). Numero di richieste ricevute da una farm o da un server in un secondo. Questa è una misurazione comune del carico dei server e delle farm.

  Si noti che le richieste non corrispondono ai caricamenti delle pagine. In ogni pagina sono inclusi diversi componenti, ognuno dei quali genera una o più richieste quando la pagina viene caricata. Il caricamento di una pagina può pertanto dare luogo a diverse richieste. Le verifiche e gli eventi di autenticazione che utilizzano risorse non significative in genere non vengono conteggiati nelle misurazioni RPS.

• Area verde   Questo è lo stato in cui il server è in grado di mantenere la serie di criteri seguente:

  • La latenza sul lato server per almeno il 75% delle richieste è inferiore a 1 secondo.

  • In tutti i server l'utilizzo della CPU è inferiore al 50%.

  • La frequenza degli errori è inferiore allo 0,01%.

Distribuzioni della gestione del contenuto Web

Sulla scelta della topologia della server farm possono influire due modelli di creazione del contenuto nei siti di pubblicazione di SharePoint.

Nel modello di creazione e modifica sul posto una singola raccolta siti viene condivisa dagli autori e dai visitatori. Gli autori possono creare e aggiornare il contenuto in qualsiasi momento, con conseguenti distribuzioni variabili delle operazioni di lettura e scrittura in un determinato giorno. In questo tipo di server farm in genere viene eseguito un numero elevato di operazioni di lettura, mentre le operazioni di scrittura sono limitate.

Nella figura seguente viene illustrato il funzionamento del modello di creazione e modifica sul posto relativamente alla topologia.

Nel modello di distribuzione del contenuto diverse raccolte siti supportano separatamente e in modo esclusivo la creazione, la modifica e la pubblicazione del contenuto. Il contenuto viene creato e aggiornato nell'ambiente di creazione e modifica e quindi distribuito nell'ambiente di distribuzione in base a una pianificazione, in modo che possa essere letto dai visitatori. L'ambiente di pubblicazione principalmente gestisce le richieste di lettura, tranne quando il contenuto viene distribuito dall'ambiente di creazione e modifica. A differenza di quanto accade nel modello di creazione e modifica sul posto, il carico che viene esercitato sui server dalla distribuzione del contenuto può essere adattato a intervalli pianificati.

Nella figura seguente viene illustrato il funzionamento del modello di distribuzione del contenuto relativamente alla topologia.

Questi modelli di creazione e modifica del contenuto si escludono reciprocamente.

Benché per i siti di pubblicazione Internet e quelli di pubblicazione Intranet sia possibile utilizzare il modello di creazione e modifica sul posto oppure il modello di distribuzione del contenuto, i wiki aziendali funzionano meglio con il primo di questi modelli. In un wiki aziendale in genere le operazioni di scrittura eseguite sono in numero maggiore rispetto alle operazioni di lettura perché una parte più estesa di utenti può modificare le pagine. Le pagine dei wiki aziendali sono diverse dalle pagine degli articoli di pubblicazione e presentano caratteristiche di prestazioni diverse.

Elementi da ottimizzare

In questa sezione vengono fornite informazioni per l'ottimizzazione dell'ambiente di gestione del contenuto Web. Ai fini di tale ottimizzazione è necessario comprendere come gestire la velocità effettiva, i colli di bottiglia e la memorizzazione nella cache.

Contenuto della sezione:

• Velocità effettiva come metrica chiave

• Colli di bottiglia e relativa correzione

• Utilità della memorizzazione nella cache

Velocità effettiva come metrica chiave

La velocità effettiva e il tempo di risposta sono le metriche più importanti di cui tenere conto per l'ottimizzazione durante la pianificazione della capacità per una distribuzione della gestione del contenuto Web di SharePoint Server 2010. La velocità effettiva corrisponde al numero di operazioni che una server farm può eseguire al secondo e viene misurata come richieste al secondo (RPS, Requests Per Second).

Colli di bottiglia e relativa correzione

Un collo di bottiglia è rappresentato dalla risorsa di sistema che, una volta giunta a esaurimento, impedisce alla server farm di gestire ulteriori richieste. Nella figura seguente vengono illustrati gli elementi di una server farm e le risorse che possono diventare colli di bottiglia e che è quindi consigliabile monitorare.

Utilizzo della CPU dei server Web

La CPU dei server Web dovrebbe essere il collo di bottiglia di una topologia ottimizzata correttamente perché è il componente più facilmente scalabile. Il servizio di bilanciamento del carico instrada le richieste tra i diversi server Web, garantendo che nessuno di essi faccia registrare un utilizzo significativamente superiore a quello dei relativi peer.

Dopo che l'utilizzo della CPU dei server Web ha raggiunto il livello massimo, ulteriori utenti possono visitare il sito, ma il tempo di risposta dei server sarà più lungo. Questo comportamento è utile per gestire le punte nel volume delle richieste. Un carico sostenuto che vada oltre la capacità di una server farm a lungo andare genera un backlog di richieste sufficiente a superare la soglia delle richieste in attesa. A questo punto, i server Web limitano le richieste e rispondono con un errore HTTP 503. Nella figura seguente il tempo di risposta dei server diminuisce dopo il superamento della soglia delle richieste in attesa perché vengono gestiti solo errori HTTP.

Nel diagramma vengono illustrati i cambiamenti seguenti:

1. Il tempo di risposta aumenta man mano che l'utilizzo della CPU dei server Web si avvicina al 100%.

2. Dopo il superamento della soglia delle richieste in attesa, le ulteriori richieste vengono gestite con errori.

Altri colli di bottiglia

Se la CPU dei server Web non è il collo di bottiglia, i successivi elementi in cui ricercare eventuali colli di bottiglia sono la topologia della farm, la configurazione della farm e il contenuto delle pagine gestite. Di seguito sono riportati alcuni possibili colli di bottiglia relativi a tali elementi:

1. Rete    In situazioni di elevata velocità effettiva la rete può essere satura tra il server Web e il server di database oppure tra il server Web e gli utenti finali. Per evitare questo problema, è consigliabile che i server Web utilizzino schede di rete dual gigabit.

2. CPU del server di database    Se la CPU del server di database diventa il collo di bottiglia, l'aggiunta di server Web alla server farm non fa aumentare la velocità effettiva massima che può essere supportata dalla farm. Un collo di bottiglia relativo alla CPU di database ma non alle CPU dei server Web può essere il risultato di due situazioni:

   1. Impostazioni della cache non adeguate o pagine molto lente, soprattutto quelle che non sono memorizzate nella cache di output. Tale situazione è caratterizzata da un elevato utilizzo della CPU del server di database, ma da una velocità effettiva e da un utilizzo dei server Web contenuti o medi.

   2. Il server di database può avere raggiunto la capacità prevista per la velocità effettiva necessaria per la farm. Tale situazione è caratterizzata da un utilizzo elevato della CPU dei server Web e del server di database a una velocità effettiva elevata.

Utilità della memorizzazione nella cache

In SharePoint Server 2010 vengono utilizzati tre tipi di memorizzazione nella cache. L'obiettivo comune di tali cache è quello di aumentare l'efficienza riducendo le chiamate effettuate al database per ottenere dati richiesti frequentemente. Le richieste successive relative a una pagina possono essere gestite dalla cache del server Web, con un conseguente utilizzo notevolmente inferiore delle risorse dei server Web e dei server di database.

I tre tipi di memorizzazione nella cache sono i seguenti:

• Cache di output   Questa cache archivia il contenuto delle pagine richiesto nella memoria del server Web. Per ulteriori informazioni sulla cache di output, vedere Memorizzazione nella cache di output e profili di cache (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=121543&clcid=0x410).

• Cache degli oggetti   Questa cache archivia gli oggetti di SharePoint, quali metadati degli elementi Web e degli elenchi, nella memoria del server Web. Per ulteriori informazioni sulla cache degli oggetti, vedere Memorizzazione nella cache degli oggetti (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=123948&clcid=0x410).

• Cache basata su disco per gli oggetti binari di grandi dimensioni (BLOB)   Questa cache archivia i file di immagine, audio, video e altri file binari di grandi dimensioni su disco. Per ulteriori informazioni sulla cache BLOB, vedere Memorizzazione nella cache basata su disco per gli oggetti binari di grandi dimensioni (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=123947&clcid=0x410).

Ognuna di queste cache è importante per supportare una velocità effettiva elevata. La memorizzazione nella cache di output è comunque quella che incide maggiormente, pertanto viene illustrata in dettaglio in questo articolo.

Risultati dei test e suggerimenti

In questa sezione vengono illustrate le aree specifiche sottoposte ai test e vengono forniti suggerimenti risultanti da tali test.

Contenuto della sezione:

• Effetto dell'attivazione della cache di output

• Utenti anonimi e utenti autenticati

• Caratteristiche di scalabilità orizzontale delle operazioni di lettura e scrittura

• Avvertenze relative alla cache di output

• Effetto del volume di operazioni di lettura sulla CPU e sul tempo di risposta

• Effetto delle operazioni di scrittura sulla velocità effettiva

• Effetto della distribuzione del contenuto

• Effetto dello snapshot dei database durante l'esportazione della distribuzione del contenuto

• Caratteristiche del contenuto

Effetto dell'attivazione della cache di output

La cache di output è una funzionalità preziosa da utilizzare per ottimizzare una soluzione di SharePoint Server 2010 per numerose operazioni di lettura.

Ai fini di questi test, per stabilire il valore RPS massimo, il numero degli utenti attivi che effettuano richieste nella farm è stato aumentato finché l'utilizzo della CPU del server di database o dei server Web non ha raggiunto il 100% e non è diventato un collo di bottiglia. Il testo è stato eseguito su topologie di farm 1x1 (1 server Web e 1 server di database), 2x1, 4x1 e 8x1 per dimostrare l'effetto dell'implementazione della scalabilità orizzontale per i server Web con rapporti riscontri cache di output diversi.

Rapporto riscontri cache di output

Il rapporto riscontri cache di output è una misura del rapporto tra riscontri e mancati riscontri nella cache di output.

• Un riscontro cache si verifica quando viene ricevuta una richiesta di dati di oggetti già memorizzati nella cache.

• Un mancato riscontro cache si verifica quando viene ricevuta una richiesta di dati di oggetti non memorizzati nella cache. In tal caso, la cache tenterà di memorizzare i dati degli oggetti richiesti in modo che le successive richieste relative agli stessi dati diano luogo a un riscontro cache.

Sono diversi i motivi per cui la richiesta di una pagina può dare luogo a un mancato riscontro cache:

• Le pagine sono configurate in modo da non utilizzare la cache di output.

• Si tratta di pagine personalizzate, ad esempio pagine con dati specifici per l'utente corrente.

• Si tratta della prima esplorazione dopo la modifica della chiave di variante della cache di output.

• Si tratta della prima esplorazione dopo la scadenza del contenuto memorizzato nella cache.

Nella figura seguente viene illustrato l'effetto della memorizzazione nella cache di output sulla velocità effettiva di picco nelle farm contenenti da uno a quattro server Web e un server di database.

Nota

La coordinata per il valore RPS massimo in una server farm 4x1 con un rapporto riscontri cache di output pari al 100% viene estrapolata e non è stata effettivamente osservata. Il volume di richieste per la server farm ha raggiunto il limite della larghezza di banda di rete, ovvero la velocità di trasferimento dati si è avvicinata a 1 gigabit al secondo. In tutti i casi l'utilizzo della CPU dei server Web è uguale al 100%.

Nella tabella seguente vengono riportati gli effetti dei rapporti riscontri cache di output nelle topologie di farm contenenti da uno a quattro server Web e un server di database.

Effetti del rapporto riscontri cache di output su topologie di farm diverse

Rapporto riscontri cache di output	Misura	1x1	2x1	4x1
100%	Valore RPS massimo Utilizzo della CPU di SQL Server	3.463 0%	7.331 0%	11.032 0%
95%	Valore RPS massimo Utilizzo della CPU di SQL Server	2.137 5,93%	3.945 12,00%	5.937 21,80%
90%	Valore RPS massimo Utilizzo della CPU di SQL Server	1.518 7,12%	2.864 14,40%	4.518 28,00%
50%	Valore RPS massimo Utilizzo della CPU di SQL Server	459 9,86%	913 19,50%	1.596 42,00%
0%	Valore RPS massimo Utilizzo della CPU di SQL Server	172 9,53%	339 19,00%	638 36,30%

Conclusioni e suggerimenti per l'effetto dell'attivazione della cache di output

Rapporti riscontri cache di output elevati causano un aumento significativo del valore RPS massimo. È pertanto consigliabile attivare la memorizzazione nella cache di output per ottimizzare la soluzione di pubblicazione di SharePoint Server 2010. È possibile configurare la cache di output nella pagina Impostazioni cache di output della raccolta siti. Per ulteriori informazioni, vedere Configurare le impostazioni della cache di output delle pagine per una raccolta siti (https://go.microsoft.com/fwlink/?linkid=205058&clcid=0x410) sul sito Web Office.Microsoft.com.

Nei test in cui la memorizzazione nella cache di output era attivata la prima richiesta che ha memorizzato una pagina nella cache è stata esclusa. Più in dettaglio, nella cache è già memorizzata una determinata percentuale di pagine. Quando un utente richiede per la prima volta una pagina non memorizzata nella cache, tale pagina viene aggiunta alla cache. Se la cache ha già raggiunto o sta per raggiungere il limite di capacità, limita i dati richiesti di recente.

Un rapporto riscontri cache pari allo 0% simula in un ambiente il breve periodo di tempo durante il quale la cache di output attivata viene riempita dopo essere stata scaricata. Tale condizione ad esempio viene osservata ogni giorno in un ambiente reale durante il riciclo del pool di applicazioni. È importante implementare la scalabilità verticale o orizzontale per l'hardware in modo da adattarsi a una situazione in cui viene registrato un rapporto riscontri cache uguale allo 0% per il breve intervallo di tempo tra il riciclo del pool di applicazioni e la successiva richiesta e memorizzazione delle pagine nella cache. Il rapporto riscontri cache pari allo 0% simula inoltre un ambiente in cui la memorizzazione nella cache di output non è attivata.

Utenti anonimi e utenti autenticati

Nel test precedente si presuppone che tutte le richieste inviate al sito vengano effettuate da lettori anonimi. Nel sito in uso è invece possibile che alcuni o tutti gli utenti siano autenticati. Sono esempi di scenari con lettura autenticata i siti di pubblicazione Intranet aziendali e il contenuto per i soli membri in un sito Internet.

Con i profili di cache di output, è possibile specificare il comportamento di tale cache per gli utenti autenticati in modo che sia diverso dal comportamento per gli utenti anonimi.

Profili di cache

Nei profili di cache sono aggregate le impostazioni applicabili alle pagine, agli elementi delle pagine, ai tipi di contenuto e ai livelli di scalabilità nella distribuzione di un sito. Un profilo di cache definisce i tipi di comportamento seguenti per la cache:

• Periodo di tempo durante il quale mantenere gli elementi nella cache.

• Criteri di limitazione di sicurezza.

• Scadenza delle impostazioni, ad esempio la durata e le modifiche.

• Varianti del contenuto memorizzato nella cache, ad esempio in base all'autorizzazione utente, ai diritti utente e ad altre variabili.

Qualsiasi modifica apportata a un profilo di cache ha effetto immediatamente su tutto il contenuto applicabile del sito. È possibile impostare profili di cache diversi per gli utenti anonimi e per gli utenti autenticati.

Per gli utenti anonimi è stato utilizzato il profilo di cache di output Internet pubblico (totalmente anonimo), mentre per gli utenti autenticati è stato utilizzato il profilo di cache di output Extranet (sito pubblicato).

Nel grafico seguente vengono illustrati gli effetti della velocità effettiva autenticata sull'utilizzo della CPU del server di database.

Il modello di autenticazione era l'autenticazione di base di Windows. Benché non sia consigliabile utilizzare l'autenticazione di base di Windows per i siti Internet, è stato scelto questo metodo di autenticazione per dimostrare un minimo overhead imposto dall'autenticazione. L'entità di tale overhead varia in base allo specifico meccanismo di autenticazione in uso. Quando si esegue il testing della propria distribuzione, tenere conto dell'effetto del meccanismo di autenticazione adottato. Per ulteriori informazioni sui meccanismi di autenticazione supportati da SharePoint Server 2010, vedere Pianificare i metodi di autenticazione (SharePoint Server 2010).

Conclusioni e suggerimenti per gli utenti anonimi e gli utenti autenticati

Per gli utenti autenticati il valore RPS è più basso e il potenziale di scalabilità orizzontale è minore perché l'elaborazione aggiuntiva necessaria per convalidare le credenziali costituisce un carico per il server di database. Come dimostrato dai risultati dei test, il valore RPS massimo che viene osservato quando gli utenti vengono autenticati è notevolmente inferiore a quello di una farm con accesso anonimo.

Caratteristiche di scalabilità orizzontale delle operazioni di lettura e scrittura

I test sono stati realizzati in modo da registrare le operazioni di scrittura ogni ora. In questo articolo per operazione di scrittura si intende la creazione e l'archiviazione di una nuova pagina di pubblicazione oppure la modifica e l'archiviazione di una pagina di pubblicazione esistente.

Per i test successivi, sono stati aggiunti lettori al sistema finché l'utilizzo della CPU dei server Web non ha raggiunto l'80-90% circa e quindi le operazioni di scrittura sono state eseguite nell'ambiente con un ritardo artificiale. Il totale delle operazioni di scrittura l'ora per il test è stato approssimativamente pari a 500. È stato utilizzato un rapporto riscontri cache di output uguale al 90% per tutti i test. Lo stesso test è stato effettuato su una farm 1x1, 2x1 e 4x1 ed è stato osservato l'utilizzo della CPU dei server Web e di SQL Server, oltre alla velocità effettiva di lettura complessiva per ogni configurazione. È stata inoltre testata una configurazione anonima con sole operazioni di lettura come riferimento di base, nonché una configurazione con lettori autenticati mediante l'autenticazione di base di Windows.

Nonostante la CPU dei server Web avesse raggiunto un livello di utilizzo del 100% durante i test di scalabilità orizzontale con sole operazioni di lettura, l'utilizzo della CPU dei server Web è stato mantenuto tra l'80% e il 90% per i test di scalabilità orizzontale con operazioni di scrittura allo scopo di lasciare un margine per l'utilizzo della CPU durante l'esecuzione delle attività di scrittura.

Nel grafico seguente viene illustrato il valore RPS complessivo delle operazioni di lettura osservato durante ogni test. Il valore RPS per le operazioni di lettura varia in modo lineare man mano che vengono aggiunti ulteriori server Web, anche con attività di scrittura. Viene tuttavia registrata una diminuzione del valore RPS quando vengono incorporate le operazioni di scrittura.

L'utilizzo della CPU del server di database è aumentato man mano che cresceva il numero dei server Web. Nel grafico seguente viene illustrato il modello di crescita dell'utilizzo della CPU di SQL Server nelle diverse configurazioni. Come osservato precedentemente nella sezione Utenti anonimi e utenti autenticati di questo articolo, l'autenticazione incide sull'utilizzo della CPU del server di database e questo risulta più evidente quando viene aggiunta l'attività di scrittura, che influisce anch'essa sull'utilizzo della CPU del server di database.

La tendenza di utilizzo di SQL Server estrapolata dimostra che SQL Server diventerà il collo di bottiglia con sei server Web che dispongono di richieste di lettura autenticate. Nel caso di operazioni di lettura anonime, può tuttavia essere utile implementare la scalabilità orizzontale attraverso un numero elevato di server Web.

È importante tenere presente che ulteriori fattori di una distribuzione tipica incidono sul carico del server di database e che tali fattori devono essere considerati durante la pianificazione della capacità. Per ulteriori informazioni su come determinare un'area verde per un utilizzo tipico della CPU del server di database, vedere Panoramica del dimensionamento e della gestione della capacità per SharePoint Server 2010.

Conclusioni e suggerimenti per le caratteristiche di scalabilità orizzontale delle operazioni di lettura e scrittura

I dati raccolti mostrano che l'implementazione della scalabilità orizzontale, ovvero l'aumento del numero dei server Web, è una strategia efficace per migliorare la velocità effettiva se il server di database non diventa il collo di bottiglia. In media la combinazione di testing con operazioni di lettura anonime e operazioni di scrittura autenticate ha fatto registrare un aumento del 52% nell'utilizzo della CPU dei server Web rispetto a una combinazione di testing con operazioni di lettura anonime e nessuna operazione di scrittura. Le operazioni di lettura autenticate inoltre rappresentano un ulteriore carico considerevole per SQL Server, in quanto ogni richiesta viene sottoposta ad altre verifiche di autenticazione che richiedono un round trip per SQL Server.

Nel grafico seguente viene illustrato l'effetto della velocità effettiva sull'utilizzo della CPU del server di database.

Avvertenze relative alla cache di output

Se l'unico obiettivo della pianificazione della capacità fosse quello di ottenere il massimo valore RPS possibile, questi test suggerirebbero che il rapporto riscontri cache ottimale è il 100%. Potrebbe tuttavia non essere possibile o produttivo attivare la memorizzazione nella cache di output per alcune o per tutte le pagine a causa dei requisiti di aggiornamento dei dati o dei vincoli di memoria previsti.

Livello di aggiornamento dei dati

I dati ottenuti forniti dalla cache di output potrebbero non contenere gli ultimi aggiornamenti apportati al contenuto originale. Nell'origine della distribuzione del contenuto o (nel caso di autori autenticati) in uno scenario di creazione e modifica sul posto gli autori potrebbero avere necessità di visualizzare le modifiche più recenti subito dopo aver aggiornato il contenuto esistente.

Ciò in genere è possibile impostando nel profilo di cache la proprietà Durata, che specifica per quanto tempo una pagina memorizzata nella cache di output deve restarvi prima di scadere. Quando una pagina scade, viene rimossa dalla cache e, a una successiva richiesta, dà luogo a un mancato riscontro che aggiorna il contenuto della pagina.

È inoltre possibile impostare la proprietà Controlla modifiche del profilo di cache in modo che il server confronti il momento in cui una pagina è stata memorizzata nella cache con il momento in cui il contenuto è stato modificato per l'ultima volta in una raccolta siti. Una richiesta relativa a una pagina con timestamp non corrispondenti causa l'invalidamento della cache per tutte le pagine nella raccolta siti. Poiché la proprietà Controlla modifiche ha effetto su tutte le pagine di una raccolta siti, è consigliabile attivare tale opzione solo nel caso di una soluzione di creazione e modifica sul posto autenticata che viene aggiornata raramente e che quindi è fondamentalmente statica. Un utilizzo combinato di questa opzione e di una lunga durata consente di ottenere tutte le pagine dalla cache finché non viene apportato un aggiornamento nel sito.

Per impostazione predefinita, la proprietà Controlla modifiche non è attivata. Questo significa che il server Web fornisce i dati della cache di output in risposta alle richieste relative a una pagina non ancora scaduta, indipendentemente dal fatto che la pagina ASPX originale sottostante sia stata o meno modificata.

In questo test, eseguito su una server farm 1x1, tutte le variabili sono le stesse dei test descritti nella sezione Caratteristiche di scalabilità orizzontale delle operazioni di lettura e scrittura, tranne per la proprietà Controlla modifiche. Quando la proprietà Controlla modifiche è attivata, la cache viene scaricata più spesso, con un conseguente rapporto riscontri cache più basso.

Nel grafico seguente viene illustrato l'effetto della proprietà Controlla modifiche sulla velocità effettiva.

È consigliabile evitare la proprietà di profilo Controlla modifiche della cache di output, tranne in casi specifici. Un sito in cui viene utilizzato il modello di creazione e modifica sul posto e il cui contenuto viene modificato di rado può trarre vantaggio da questa impostazione per gli utenti autenticati in combinazione con una lunga durata della cache, ma per altri tipi di siti è molto probabile una diminuzione del valore RPS.

A seconda delle esigenze, potrebbe essere necessario pubblicare il contenuto con requisiti temporali specifici immediatamente o molto più rapidamente di quanto consentito dalle impostazioni predefinite. In questo caso è consigliabile ridurre la durata o non attivare la memorizzazione nella cache di output.

Conclusioni e suggerimenti per le avvertenze relative alla cache di output

La memorizzazione nella cache di output non risolve tutti i problemi correlati alla gestione della capacità. Vi sono infatti situazioni in cui non è opportuna. Tenere conto di tali situazioni quando si attiva la cache di output e si configurano i relativi profili.

Effetto del volume di operazioni di lettura sulla CPU e sul tempo di risposta

Questo test è stato eseguito su una farm 1x1 con l'accesso anonimo e la memorizzazione nella cache di output attivata.

Nel grafico seguente viene illustrato l'effetto del volume delle operazioni di lettura sulla CPU e sul tempo di risposta.

Conclusioni e suggerimenti per l'effetto del volume delle operazioni di lettura sulla CPU e sul tempo di risposta

Come spiegato nella sezione Colli di bottiglia e relativa correzione, il tempo di risposta dei server resterà generalmente costante fintanto che il server Web riceverà un volume di richieste sufficiente a utilizzare completamente la relativa CPU. Man mano che ci si avvicina al completo utilizzo della CPU del server Web, il tempo di risposta aumenta in modo significativo. La server farm sarà comunque ancora in grado di gestire un ulteriore volume di richieste.

Effetto delle operazioni di scrittura sulla velocità effettiva

Il rapporto tra le operazioni di creazione e quelle di modifica è distribuito in modo uniforme nel corso dei test. Le operazioni di scrittura l'ora sono state testate fino a valori all'incirca pari a 500, dal momento che la creazione o la modifica di più di 500 pagine l'ora esula dall'ambito operativo della maggior parte delle distribuzioni di SharePoint. Il test non ha riguardato processi automatizzati, come ad esempio la distribuzione del contenuto, che è illustrata nella sezione Effetto della distribuzione del contenuto. Tali operazioni di creazione e modifica potrebbero dare luogo a più operazioni di SQL Server. È quindi importante tenere presente che le operazioni di scrittura misurate in questi test non sono a livello di SQL Server, bensì rappresentano quello che un utente considererebbe un'operazione di scrittura. Tutti i test di confronto tra il valore RPS e le operazioni di scrittura sono stati eseguiti su una farm 1x1.

Al test sono state innanzitutto aggiunte operazioni di lettura fino a portare l'utilizzo della CPU del server Web a un livello compreso tra il 60% e l'80% in modo da lasciare un buffer per le punte di traffico e tale livello medio di utilizzo è stato mantenuto per tutta la durata del test. Sono state quindi introdotte operazioni di scrittura utilizzando un ritardo artificiale per controllare il numero di tali operazioni, nel corso delle quali sono state tuttavia registrate punte di utilizzo maggiore per il server Web e la CPU di SQL Server. Alcune di queste punte per determinati rapporti riscontri cache hanno superato la soglia relativa al funzionamento ordinario, come illustrato nel grafico seguente, benché la media fosse rimasta entro l'intervallo di funzionamento ordinario.

Come illustrato nel grafico precedente, vi è una minima riduzione della velocità effettiva quando le operazioni di scrittura vengono aggiunte all'ambiente. Nel grafico viene mostrata la differenza di velocità effettiva tra uno scenario con sole operazioni di lettura e le operazioni di lettura durante 500 operazioni di scrittura l'ora circa. Per ogni riscontro cache di output sono state registrate due coordinate. La relazione tra le coordinate pertanto non è necessariamente lineare.

La riduzione percentuale è più evidente per i rapporti riscontri cache più bassi, come illustrato nel grafico seguente. Il valore RPS complessivo per le operazioni di lettura rimane subordinato in larga misura al rapporto riscontri cache, indipendentemente dalle operazioni di scrittura.

Nel grafico seguente viene illustrato il fatto che l'utilizzo della CPU del server di database non è aumentato in modo significativo quando le operazioni di scrittura sono state aggiunte al sistema. Si noti che la scala verticale è compresa tra lo 0% e il 10% della capacità della CPU.

Durane le operazioni di scrittura è stato osservato ulteriore carico per SQL Server, una condizione prevista. Il maggiore aumento tuttavia è stato rappresentato da un ulteriore 2,06%, ovvero da un valore poco significativo. L'utilizzo medio della CPU del server di database è rimasto al di sotto del 10% per tutti i test. Questo test è stato eseguito su una farm 1x1. L'utilizzo della CPU del server di database aumenterà man mano che viene implementata la scalabilità orizzontale aggiungendo server Web. Questo aspetto viene trattato più in dettaglio in Caratteristiche di scalabilità orizzontale delle operazioni di lettura e scrittura.

Durante i test è stato inoltre misurato l'utilizzo della CPU dei server Web. Nel grafico seguente viene illustrato l'utilizzo medio della CPU dei server Web rimasto tra il 60% e l'80% per tutta la durata dei test, anche quando il numero delle operazioni di scrittura l'ora si è avvicinato a 500.

L'utilizzo della CPU misurato effettivo raggiunge tuttavia una punta durante l'esecuzione delle operazioni di scrittura, come illustrato nel grafico seguente. Tali punte relative alla CPU di solito non rappresentano un problema. L'obiettivo dell'area verde è quello di lasciare spazio alla CPU per assorbire alcuni picchi nel relativo carico. Inoltre, man mano che vengono aggiunti ulteriori server Web, l'effetto delle punte verrà distribuito fra tali server, in modo da ridurre l'effetto sulla CPU del singolo server Web. Considerare tuttavia che tali punte sono previste in una distribuzione reale. L'attività di scrittura non è distribuita in modo uniforme, benché in genere avvenga in burst.

Un rapporto riscontri cache del 90% è molto basso per una distribuzione tipica. La maggior parte delle distribuzioni di SharePoint Server 2010 con numerose operazioni di lettura avrà un rapporto riscontri cache almeno del 95%.

Conclusioni e suggerimenti per l'effetto delle operazioni di scrittura sulla velocità effettiva

I dati presentati indicano che le operazioni di scrittura non avranno un grande effetto negativo sulla velocità effettiva complessiva del sistema per i lettori. Rendersi conto che l'attività di scrittura può causare punte di utilizzo della CPU, pertanto è consigliabile pianificare la propria configurazione tipica in modo da prevedere tali punte. Una strategia per livellare le punte consiste nell'implementare la scalabilità orizzontale con l'aggiunta di più server Web. Tale strategia offre due vantaggi:

• Suddivide il carico di scrittura tra più server Web, contribuendo a smussare le punte globali.

• Garantisce un valore RPS di lettura più alto, soprattutto con rapporti riscontri cache di output elevati.

Effetto della distribuzione del contenuto

Un'alternativa al modello di creazione e modifica sul posto, in cui viene utilizzato un singolo ambiente per la modifica e la lettura, consiste nel dividere l'ambiente unico in due ambienti separati (uno di creazione e modifica e uno di produzione) e nell'utilizzare la distribuzione del contenuto per copiare il contenuto dall'ambiente di creazione e modifica a quello di produzione.

Con questa configurazione, nell'ambiente di produzione l'attività di scrittura è minima o addirittura nulla, tranne quando la distribuzione del contenuto importa il contenuto. Per questi test, sono state aggiunte operazioni di lettura finché l'utilizzo della CPU dei server Web non è arrivato al 70-80%. Il processo di distribuzione del contenuto ha quindi esportato 10 siti con 500 pagine ognuno dalla raccolta siti di creazione e modifica come pacchetto e quindi ha importato tale pacchetto nella raccolta siti di pubblicazione. Le dimensioni del pacchetto distribuito sono maggiori di quelle generalmente osservate in ambienti reali allo scopo di estendere la durata del processo di distribuzione del contenuto a sufficienza per vedere i risultati dei test. Per ulteriori informazioni sulle caratteristiche del contenuto distribuito, vedere la sezione Set di dati.

Al completamento dell'esportazione, il contenuto è stato importato in una raccolta siti distinta e, nel corso dell'importazione, è stato misurato il carico per i server applicazioni e SQL Server, oltre che la velocità effettiva. Il test di importazione è stato eseguito per rapporti riscontri cache di output diversi.

L'osservazione chiave è rappresentata dal fatto che l'importazione ha un effetto minimo sul valore RPS di lettura complessivo, come illustrato nel grafico seguente. È stato inoltre osservato che l'importazione non ha avuto alcun effetto significativo sull'utilizzo della CPU dei server Web, come indicato nelle tabelle seguenti, indipendentemente dal rapporto riscontri cache. È stato invece notato un effetto più evidente sulla CPU di SQL Server, mostrato nel grafico seguente. Questa condizione è prevista, dal momento che il server di database deve gestire un carico maggiore durante l'importazione del contenuto. L'utilizzo della CPU di SQL Server è comunque rimasto al di sotto del 12% con i rapporti riscontri cache testati, anche nel corso dell'importazione.

Nelle tabelle seguenti viene indicato l'effetto dell'importazione della distribuzione del contenuto sull'utilizzo della CPU dei server Web e del server di database.

Effetto dell'importazione della distribuzione del contenuto sull'utilizzo della CPU dei server Web

Riscontro cache	100%	99%	98%	95%	90%	50%	0%
Di base	72,32%	73,26%	71,28%	73,53%	71,79%	68,05%	63,97%
Con importazione	70,93%	74,45%	69,56%	74,12%	70,95%	67,93%	63,94%

Effetto dell'importazione della distribuzione del contenuto sull'utilizzo della CPU del server di database

Riscontro cache	100%	99%	98%	95%	90%	50%	0%
Di base	1,19%	1,64%	2,01%	3,00%	3,73%	5,40%	6,82%
Con importazione	6,03%	6,82%	6,97%	7,96%	8,52%	10,29%	10,56%

Conclusioni e suggerimenti per l'effetto della distribuzione del contenuto

I risultati dei test effettuati mostrano che l'esecuzione di operazioni di distribuzione del contenuto durante il normale funzionamento dei siti non incide in modo significativo sulle prestazioni. Tali risultati indicano che non è strettamente necessario distribuire il contenuto nei periodi di basso traffico per ridurre al minimo l'effetto dell'operazione sulle prestazioni globali e che i tempi di distribuzione possono essere decisi soprattutto in base alle esigenze aziendali piuttosto che in base ai requisiti di prestazioni.

Effetto dello snapshot dei database durante l'esportazione della distribuzione del contenuto

In SharePoint Server 2010 la distribuzione del contenuto può essere configurata in modo da creare uno snapshot del database del contenuto di origine prima che il contenuto venga esportato. In questo modo il processo di esportazione viene protetto da qualsiasi attività di creazione e modifica che potrebbe verificarsi mentre l'esportazione è in corso. Gli snapshot possono tuttavia incidere negativamente sulle prestazioni in scrittura del server di database perché fungono da moltiplicatori delle operazioni di scrittura. Se ad esempio si dispone di due snapshot di un database di origine e quindi si scrive in tale database, il server di database copia i dati esistenti in ogni snapshot e quindi scrive i nuovi dati nel database di origine. Questo significa che un'unica operazione di scrittura nel database di origine corrisponde a tre operazioni di scrittura effettive, ovvero una nel database di origine e una per ogni snapshot del database.

Per determinare l'effetto di uno snapshot sull'ambiente di creazione e modifica, sono stati misurati il valore RPS di scrittura, il tempo di risposta e l'utilizzo della CPU dei server Web, del server di database e del server applicazioni durante un'operazione di esportazione mentre era in corso anche un'attività di scrittura. I risultati sono riportati nelle tabelle seguenti.

Effetto degli snapshot dei database durante la distribuzione del contenuto

Metrica	4 operazioni di scrittura l'ora - Nessuno snapshot	4 operazioni di scrittura l'ora - Con snapshot
Valore RPS di scrittura	0,2	0,16
Tempo di risposta	0,13	0,15
% di utilizzo della CPU dei server Web	0,42%	0,27%
% di utilizzo della CPU del server applicazioni	8,67%	8,98%
% di utilizzo della CPU del server di database	3,34%	2,41%

Effetto degli snapshot dei database durante la distribuzione del contenuto

Metrica	8 operazioni di scrittura l'ora - Nessuno snapshot	8 operazioni di scrittura l'ora - Con snapshot
Valore RPS di scrittura	0,44	0,44
Tempo di risposta	0,13	0,13
% di utilizzo della CPU dei server Web	0,61%	0,73%
% di utilizzo della CPU del server applicazioni	14,6%	12%
% di utilizzo della CPU del server di database	7,04%	7,86%

Conclusioni e suggerimenti per l'effetto dello snapshot dei database durante l'esportazione della distribuzione del contenuto

I risultati dei test effettuati non hanno mostrato alcun effetto significativo sulle coordinate misurate con gli snapshot di database. La varianza registrata è stata sempre entro il margine di errore. Questo conferma che gli snapshot dei database possono essere utilizzati senza considerazioni eccessive sulle prestazioni.

Caratteristiche del contenuto

I test sono stati eseguiti su un singolo set di dati creato per rispondere a una serie specifica di domande. Il proprio set di dati sarà diverso e cambierà nel tempo. In questa sezione viene illustrato come utilizzare le caratteristiche del contenuto, ad esempio il numero di pagine della raccolta pagine e le caratteristiche incluse nelle pagine, come riferimenti per le decisioni relative alla gestione della capacità.

Numero di pagine

È stato testato il valore RPS massimo con raccolte pagine di diverse dimensioni. Questo test è stato eseguito su una topologia 4x1 con la memorizzazione nella cache di output disattivata e l'accesso anonimo. Tutte le pagine erano di 42 KB non compressi e 12 KB compressi. I risultati del test sono riportati nella tabella seguente.

Effetto del numero delle pagine della raccolta sul valore RPS

Numero di pagine	3	1.000	20.000
Valore RPS massimo	860	801	790

L'aumento del numero delle pagine a 20.000 non ha avuto alcun effetto significativo sul valore RPS massimo.

Campi di ricerca multivalore

Un campo di ricerca multivalore è una colonna di un elenco che fa riferimento a uno o più elementi di un altro elenco, ad esempio colonne in cui vengono utilizzati metadati gestiti dell'azienda. Tali campi in genere vengono utilizzati come parole chiave di ricerca per una pagina e non vengono necessariamente visualizzati tramite rendering. In alcuni casi, ad esempio per i wiki aziendali, è utile visualizzare i valori di questi campi nel contenuto delle pagine. Le pagine potrebbero magari essere raggruppate in categorie quando vengono create, ad esempio Notizie dal mondo, Questioni umanitarie e Sport in un sito di news, e nella pagina master potrebbe essere incluso un segnaposto che mostri all'utente le categorie a cui la pagina è associata.

Per i campi di ricerca multivalore viene recuperata una quantità di dati maggiore ogni volta che viene richiesta una pagina. La presenza di numerosi campi di ricerca multivalore in una pagina può pertanto incidere negativamente sulle prestazioni.

Nel grafico seguente viene illustrato l'effetto dei campi di ricerca multivalore sulla velocità effettiva.

Nel grafico seguente viene illustrato l'effetto dei campi di ricerca multivalore sull'utilizzo delle risorse della farm.

La massima diminuzione del valore RPS si verifica quando il numero dei campi di ricerca multivalore aumenta a seguito dell'effetto sulla rete tra il server Web e il server di database.

Effetto dei report di utilizzo

I report di utilizzo sono un servizio che consente agli amministratori di monitorare le statistiche relative all'utilizzo dei siti. Per ulteriori informazioni su tale servizio, vedere Configure usage and health data collection (SharePoint Server 2010).

L'effetto dei processi timer per i report di utilizzo è stato testato con un valore RPS massimo su una farm 1x1. I risultati vengono riportati nella tabella seguente.

Effetto della registrazione dei dati di utilizzo sulle prestazioni (in RPS)

	Database servizio di utilizzo attivato	Database servizio di utilizzo disattivato	Differenza
Cache di output attivata	3.459	3.463	4
Cache di output disattivata	629	638	9

I risultati mostrano che l'attivazione della registrazione dei dati di utilizzo non incide in modo significativo sul valore RPS in uno scenario con sole operazioni di lettura.

Informazioni sugli autori

Joshua Stickler è Program Manager per SharePoint Server 2010 presso Microsoft.

Tyler Butler è Program Manager per SharePoint Server 2010 presso Microsoft.

Zhi Liu è Software Development Engineer in Test per SharePoint Server 2010 presso Microsoft.

Cheuk Dong è Software Development Engineer in Test per SharePoint Server 2010 presso Microsoft.

Philippe Flamm è Software Development Engineer in Test per SharePoint Server 2010 presso Microsoft.