Stimare capacità e prestazioni per la gestione del contenuto Web (SharePoint Server 2013)

 

**Si applica a:**SharePoint Server 2013

**Ultima modifica dell'argomento:**2017-08-25

Riepilogo: informazioni su come determinare il numero e i tipi di computer necessari per la pubblicazione di contenuto e la gestione di contenuto Web in SharePoint Server 2013.

Spesso le aziende utilizzano SharePoint Server 2013 la pubblicazione di contenuto autenticazione agli utenti l'accesso in un sito intranet di un sito Internet o che l'accesso agli utenti anonimi. In questo articolo contiene dati di capacità e prestazioni per pianificare i tipi di computer necessari per la pubblicazione di contenuti e gestire contenuto web in SharePoint Server 2013 e il numero di computer da utilizzare.

Contenuto dell'articolo:

• Introduzione

• Informazioni preliminari

• Pubblicazione intersito con esplorazione gestita

• Pubblicazione con creazione e modifica sul posto

Pubblicazione di SharePoint è diversi tipi di siti di pubblicazione e associare i metodi disponibili per ogni sito. Le caratteristiche di pubblicazione di SharePoint Server 2013 sono utili per creare siti extranet, intranet e Internet personalizzato. Per ulteriori informazioni sulla pubblicazione SharePoint Server 2013, vedere Panoramica della pubblicazione in siti Internet, Intranet ed Extranet in SharePoint Server.

Introduzione

In questo articolo vengono descritti i seguenti scenari:

• Sito di presenza Internet

  Fornisce informazioni a clienti, partner, investitori e potenziali dipendenti. Questo tipo di sito consente agli utenti Internet anonimi di trovare informazioni relative a una società. I siti di questo tipo includono informazioni personalizzate e distintive dell'azienda e il contenuto è rigidamente controllato.

• Sito aziendale Internet

  Promuove i prodotti e i servizi offerti ai clienti da una società. Nel sito può essere presentato un catalogo di prodotti offerti dalla società.

• Sito Intranet

  Questo tipo di sito viene pubblicato internamente in un'organizzazione e viene utilizzato per condividere informazioni con utenti autenticati. Una società può decidere di gestire il sito rigidamente oppure di limitare l'accesso ad alcune aree o consentirlo solo agli utenti interni.

• Sito Extranet

  Consente a dipendenti remoti, partner e clienti di accedere a contenuto specifico. Questi tipi di siti possono fornire l'accesso a knowledge base in cui viene utilizzato contenuto creato e contrassegnato con metadati per la classificazione degli articoli. Gli utenti possono cercare o selezionare informazioni specifiche, ad esempio articoli di supporto tecnico e di risoluzione dei problemi.

La pubblicazione di raccolte intersito e la web part Ricerca contenuto consentono il riutilizzo del contenuto tra raccolte siti in questi scenari. Queste caratteristiche e funzionalità incidono sul modo in cui viene pianificata la capacità. Per ulteriori informazioni, vedere Panoramica della pubblicazione intersito in SharePoint Server.

Nota

La pubblicazione di raccolte intersito viene indicata con il termine di pubblicazione intersito in questo articolo.

Esplorazione gestita in SharePoint Server 2013 fornisce esplorazione basata sulla tassonomia per un sito di pubblicazione. Per ulteriori informazioni, vedere Panoramica dell'esplorazione gestita in SharePoint Server.

I dati relativi alla capacità e alle prestazioni sono suddivisi in due parti in questo articolo. La prima parte è relativa al nuovo metodo di pubblicazione intersito e all'esplorazione gestita. La seconda parte invece si basa sul modello di creazione e modifica sul posto.

Nota

Gli scenari descritti in questo articolo possono essere riprodotti sia in siti di pubblicazione intersito che in siti di creazione e modifica sul posto. Le funzionalità di pubblicazione intersito ed esplorazione gestita non dipendono l'una dall'altra e possono essere utilizzate separatamente.

I modelli utilizzati in questo articolo si basano sulle due seguenti metriche chiave:

• Velocità effettiva

  Il numero di visualizzazioni pagina al secondo supportato nel sito.

• Tempo di risposta del server

  Il tempo utilizzato dal server per elaborare una richiesta. Influisce sul tempo impiegato dall'utente per visualizzare la pagina. I tempi di risposta del server forniti in questo documento sono valori del 95° e del 50° percentile. Questi valori indicano che rispettivamente il 95% e il 50% delle richieste è più veloce del valore fornito. Questi valori vengono misurati utilizzando la durata registrata nel database servizio di utilizzo di SharePoint per una determinata richiesta.

• Livello di aggiornamento del contenuto

  Il tempo necessario per la visualizzazione di un elemento aggiornato nei risultati di ricerca è una buona metrica da prendere in considerazione se si desidera utilizzare scenari di pubblicazione intersito.

Negli scenari illustrati in questo articolo vengono utilizzati i due seguenti stati:

• Area verde

  L'utilizzo dei server è inferiore al 60%. Questo dovrebbe essere l'obiettivo per la maggior parte del tempo di esecuzione dei server.

• Area rossa

  I server sono prossimi all'utilizzo totale. Questo può essere considerato uno stato in cui il sito di SharePoint è sottoposto a un carico maggiore del solito. Nell'area rossa i valori del tempo di risposta del server iniziano ad aumentare man mano che il server tenta di soddisfare le richieste in ingresso.

Informazioni preliminari

Prima di leggere questo articolo, assicurarsi di avere compreso i concetti di base della gestione della capacità SharePoint Server 2013. Gli articoli seguenti consentono di conoscere l'approccio consigliato per la gestione della capacità e forniscono il contesto che consentono di comprendere come ottimizzare l'utilizzo delle informazioni in questo articolo.

Si noti che alcune nuove funzionalità che influiscono sugli scenari di pubblicazione non sono citate in questo articolo. Questi scenari includono i canali di dispositivi, l'ottimizzazione SEO, i modelli di visualizzazione e le regole di query. In questo articolo inoltre non viene descritta in modo dettagliato la funzione e la configurazione di un sito di pubblicazione intersito. Per ulteriori informazioni, vedere Pianificare la pubblicazione intersito in SharePoint Server e Configurare le soluzioni di gestione del contenuto web in SharePoint Server.

Per ulteriori informazioni sui concetti di prestazioni e capacità utili per comprendere il contesto dei dati di questo articolo, vedere Pianificare le prestazioni di pianificazione in SharePoint Server 2013.

Pubblicazione intersito con esplorazione gestita

In questa sezione i dati di test vengono applicati a due aree: pubblicazione intersito con utenti anonimi e pubblicazione con creazione e modifica sul posto.

Pubblicazione intersito con utenti anonimi

I risultati dei test forniti in questa sezione sono basati su un modello di sito di pubblicazione intersito di base per fornire indicazioni sulla pianificazione della capacità. Quando si pianifica una distribuzione di SharePoint per consentire a utenti anonimi di accedere a un sito Web, utilizzare queste indicazioni e adattare le specifiche della distribuzione di conseguenza.

Nel test case dei test viene utilizzata la funzionalità di pubblicazione intersito. Questo scenario fornisce contenuto in più raccolte siti contrassegnate come cataloghi e quindi sottoposte a ricerca per indicizzazione dall'applicazione del servizio di ricerca di SharePoint. Nelle web part in cui viene utilizzata la tecnologia di ricerca, ad esempio le web part Ricerca contenuto e Riutilizzo elemento catalogo, viene visualizzato il contenuto di pagine di un altro sito. Per ulteriori informazioni, vedere Panoramica della pubblicazione intersito in SharePoint Server.

Nel sito modelli creato per testare la pubblicazione intersito sono state utilizzate le seguenti caratteristiche:

• Il sito Web di pubblicazione include circa 5 milioni di pagine o elementi.

• Gli elementi sono associati a circa 1000 categorie.

• Il contenuto è posizionato in altre raccolte siti in uno o più cataloghi.

• Viene utilizzata l'esplorazione gestita collegata alle categorie a cui sono associati gli elementi.

• Per la topologia di distribuzione di base descritta più avanti nell'elenco, il sito Web riceve in media fino a 80 visualizzazioni pagina al secondo. Nelle ore di punta vengono raggiunte fino a 100 visualizzazioni pagina al secondo. Per aumentare questo valore di velocità effettiva, aggiungere computer alla topologia. Per ridurlo invece rimuovere computer dalla topologia.

• Il crawler di ricerca viene eseguito con ricerche per indicizzazione continue a intervalli di un minuto con cinque aggiornamenti al secondo nel catalogo.

• Il sito Web presenta i seguenti modelli di pagine e traffico:

  • La home page con tre web part Ricerca contenuto e una web part Riquadro di perfezionamento riceve il 15% del traffico.

  • Le pagine di categoria con tre web part Ricerca contenuto, una web part Riquadro affinamento tassonomia e una web part Riquadro di perfezionamento ricevono il 45% del traffico.

  • Le pagine di elementi di catalogo con una web part Riutilizzo elemento catalogo e due web part Ricerca contenuto ricevono il 40% del traffico.

• Ogni web part Ricerca contenuto e Riutilizzo elemento catalogo invia un query sincrona.

• Nelle pagine di elementi di catalogo non viene utilizzata la cache dei risultati di ricerca anonima a causa del traffico ridotto.

• Nella farm è attivata la cache di oggetti binari di grandi dimensioni (BLOB, Binary Large Object) per i computer eseguiti come server Web front-end.

La topologia di server utilizzata per testare questo scenario è illustrata nella figura riportata di seguito:

Figura 1: topologia di server di laboratorio di testing

• Un computer che ospita SQL Server con tutti i database utilizzati da SharePoint

• Un computer che ospita le applicazioni di servizio di SharePoint, il servizio cache distribuita, l'elaborazione dell'analisi della ricerca e i ruoli di amministrazione della ricerca

• Un computer che ospita il crawler di ricerca e i ruoli di elaborazione del contenuto

• Tre computer che ospitano i nodi dell'indice di ricerca con l'elaborazione delle query e funzionano come server Web front-end

Nota

I computer di questo test sono computer fisici che eseguono Windows Server 2008 R2. Fare riferimento alla pianificazione della capacità di ricerca e a Pianificazione della capacità per SharePoint Server 2013 per indicazioni su come utilizzare le macchine virtuali e Windows Server 2012.

Importante

La configurazione della topologia del laboratorio di testing è ottimizzata per scenari di pubblicazione basati sulla ricerca. Questa configurazione è diversa dai tipi di collaborazione delle distribuzioni di SharePoint. In questa configurazione ad esempio i server Web front-end vengono utilizzati come server dell'indice di ricerca per ottenere prestazioni ottimali.
Nella topologia del laboratorio di testing è stato rilevato un utilizzo ridotto del computer che ospita il server applicazioni. Di conseguenza il servizio cache distribuita è stato posizionato in questo server applicazioni anziché in un server dedicato. È possibile decidere di ospitare il servizio cache distribuita in un server dedicato nell'ambiente. Per ottenere prestazioni ottimali, non è consigliabile ospitare il servizio cache distribuita in un server Web front-end con ruolo di server dell'indice di ricerca.

Report del laboratorio di testing

La topologia nella figura 1 viene utilizzato per il nostro laboratorio di testing con computer fisici e un test di carico Visual Studio Team System (VSTS). Per ulteriori informazioni, vedere Visual Studio Team System. Specifiche tecniche per i computer di test sono nelle tabelle seguenti.

Nota

Nei test VBTS non è stata utilizzata la cache dei browser o le richieste dipendenti, ad esempio immagini o file JavaScript. A seconda del modo in cui è stato personalizzato il sito di pubblicazione, la quantità di richieste dipendenti può variare in modo significativo.
Le pagine utilizzate nei test hanno effettuato circa 50 tipi di richieste PLT1 (Page Load Time 1, tempo di caricamento pagina 1) con cache del browser vuota e circa tre richieste per tipi di richieste PLT2 (richieste successive con risultati restituiti dalla cache del browser). In genere le richieste di questi elementi vengono gestite dalla cache BLOB di SharePoint senza incidere in modo significativo sulle prestazioni.

Componenti server	Server che eseguono SharePoint Server
Processori	CPU Intel Xeon @ 2,27 GHz (2 processori, totale di 8 core, totale di 16 thread)
RAM	24 GB
Sistema operativo	Windows Server 2008 R2 Enterprise SP1, 64 bit
Dimensione dell'unità di SharePoint	200 GB su disco interno
Spazio di archiviazione utilizzato per l'indice di ricerca	78 GB su un array di dischi esterno (2 x Dell PERC H700 SCSI)
Numero di schede di rete	2
Velocità delle schede di rete	1 gigabit
Autenticazione	Nessuna - Anonimo
Versione software	SharePoint Server 2013

Componenti server	Server di database
Processori	CPU Intel Xeon L5520 @ 2,27 GHz (2 processori, totale di 8 core, totale di 16 thread
RAM	24 GB
Sistema operativo	Windows Server 2008 R2 Enterprise SP1, 64 bit
Array di dischi	2 x Dell H700 SCSI
Numero di schede di rete	2
Velocità delle schede di rete	1 gigabit
Autenticazione	NTLM
Versione software	Microsoft SQL Server 2008 R2 SP1

I risultati di un'esecuzione di 10 minuti sono i seguenti:

Caratteristiche dei test	Area verde	Area rossa
Numero di utenti VSTS (simulazione di utenti simultanei):	60	100
50° percentile del tempo di risposta del server*:	219 ms	302 ms
95° percentile del tempo di risposta del server*:	412 ms	635 ms
Visualizzazioni pagina al secondo:	78	98

Questo è uno scenario di pubblicazione intersito in cui viene visualizzato il contenuto dell'indice di ricerca. Può essere interessante esaminare il numero di query gestito dai server che ospitano le query di ricerca e il numero di query gestito dalla cache dei risultati di ricerca anonima. In questo modello la cache dei risultati di ricerca anonima gestisce circa il 60% delle query. Questa cache verrà illustrata più avanti nell'articolo.

Caratteristiche dei test	Area verde	Area rossa
Query totali al secondo:	235	294
Query gestite dalla cache dei risultati di ricerca anonima:	145	182
Query gestite dalla ricerca:	90	112

I valori relativi all'utilizzo medio della CPU e all'utilizzo massimo della memoria per questi computer durante l'esecuzione dei test sono stati i seguenti:

Caratteristiche dei test	Area verde	Area rossa
Utilizzo medio della CPU (nodi di indice di ricerca per server Web front-end)	59%	80%
Utilizzo medio della CPU (server applicazioni inclusa la cache distribuita)	8%	9%
Utilizzo medio della CPU (nodi di elaborazione del contenuto di ricerca)	5%	5%
Utilizzo medio della CPU (SQL Server)	Misurazione non effettuata	Misurazione non effettuata
Utilizzo massimo della memoria (nodi di indice di ricerca per server Web front-end)	7,5 GB	7,5 GB
Utilizzo massimo della memoria (server applicazioni inclusa la cache distribuita)	10,1 GB	10 GB
Utilizzo massimo della memoria (nodi di elaborazione del contenuto di ricerca)	6,5 GB	6,5 GB

Si noti che l'utilizzo della memoria può variare poiché nel server vengono eseguiti diversi processi timer durante il normale utilizzo. È stato rilevato che i nodi dei server Web di indicizzazione/front-end hanno utilizzato 12 GB di memoria dopo due settimane di esecuzione dei test con un carico prolungato.

Visualizzazione del contenuto nelle web part di ricerca nelle pagine di pubblicazione intersito

Se in una pagina di pubblicazione è contenuta una web part di ricerca, ad esempio Ricerca contenuto, il browser inizia a elaborare la pagina prima del completamento della query di ricerca. In questo modo viene migliorata la latenza percepita della pagina. Al termine della query di ricerca, vengono inviati al browser i risultati completi della query e viene chiusa la connessione con il browser. Gli utenti possono pensare che i risultati di ricerca vengano caricati in modo asincrono. Le query tuttavia continuano a essere inviate dal server mentre viene richiesta la pagina.

Si noti che esiste una modalità asincrona separata per la web part Ricerca contenuto in base alla quale le query vengono inviate dal browser dopo il caricamento di una pagina.

Effetto delle variazioni di carico sul sito di pubblicazione intersito

È stato variato il numero di utenti VSTS (come il numero di utenti simultanei che accedono al sito) utilizzati nel test di carico. Nel grafico riportato di seguito viene mostrato che il tempo di risposta del server aumenta con l'aumento del carico e che si verifica un aumento incrementale del numero di pagine gestite al secondo. È consigliabile mantenere i tempi di risposta del server al di sotto dei 750 ms in modo che gli utenti possano usufruire di una distribuzione di SharePoint reattiva.

Figura 2: grafico in cui vengono mostrati la velocità effettiva e i tempi di risposta del server con carichi diversi

Scalabilità orizzontale del sito di pubblicazione intersito

Se si prevede che la distribuzione di SharePoint riceverà più o meno traffico rispetto allo scenario di base descritto precedentemente, è possibile modificare il numero di computer eseguiti con il ruolo di server di indicizzazione e server Web front-end nella farm per supportare tale traffico. Nel grafico riportato di seguito vengono mostrati i risultati dell'implementazione della scalabilità orizzontale dello stesso sito di pubblicazione intersito con diversi modelli di carico e un numero variabile di computer utilizzati come server Web front-end con nodi di indice, a partire da un singolo computer nel ruolo di server Web front-end con nodi di indice fino a sei computer:

Figura 3: implementazione della scalabilità orizzontale della distribuzione

In ciascuna configurazione è stato adattato il carico in modo da ottenere tempi di risposta del server con valori simili rispetto allo scenario di base della sezione precedente.

Si noti che con l'aumento del numero di computer, a una topologia sempre più complessa non corrispondono altrettanti vantaggi. Ogni computer aggiuntivo presenta una velocità effettiva inferiore rispetto ai computer già inclusi nell'ambiente. Questi numeri vengono forniti per mostrare il modello per la scalabilità orizzontale. Le prestazioni effettive dipenderanno dalla distribuzione di SharePoint.

Linee guida per la pianificazione di un sito

Per la maggior parte dei test delle prestazioni è stata utilizzata la distribuzione descritta nelle sezioni precedenti. Le linee guida incluse nell'elenco riportato di seguito consentono una corretta pianificazione della capacità in caso di distribuzioni che si differenziano da quelle utilizzate nel laboratorio di testing.

• A un numero elevato di elementi nell'indice di ricerca corrisponde in genere una latenza maggiore. Ogni partizione di indice può includere fino a 10 milioni di elementi. Poiché nei siti Web tipici è raro che siano contenuti più di 10 milioni di elementi da mostrare, è sufficiente una partizione, come illustrato nella topologia descritta precedentemente. È possibile utilizzare più partizioni di indice per ospitare più di 10 milioni di elementi oppure per disporre di un numero superiore di partizioni di indice più piccole e veloci. Se si prevede di utilizzare più partizioni di indice, vedere Implementare la scalabilità della ricerca per i siti Internet in SharePoint Server per informazioni sulle dimensioni appropriate di una topologia di ricerca.

• Ogni controllo o web part aggiunta a una pagina o a un layout di pagina comporterà un sovraccarico per il tempo di risposta del server per la pagina.

• Evitare di utilizzare più di cinque sincrona Web part ricerca contenuto o elemento catalogo riutilizzare Web part in una pagina. Durante l'elaborazione della richiesta di una pagina, SharePoint Server 2013 esegue fino a cinque query in parallelo e restituisce i risultati. Se più di cinque query in una pagina, SharePoint Server 2013 esegue le prime cinque query prima che venga avviato eseguire il set di cinque query successivo. Se pagine richiedono più di cinque elemento catalogo riutilizzare Web part o Web part ricerca contenuto, si può eseguire le ulteriori Web part ricerca contenuto in modalità asincrona oppure utilizzare le regole di query e blocchi di risultati.

• Le web part Ricerca contenuto e Riutilizzo elemento catalogo supportano una modalità asincrona. La query associata alla web part viene eseguita dopo il caricamento della pagina nel browser. Utilizzare questa modalità per query lente in modo che gli utenti possano visualizzare più velocemente il resto della pagina. In caso contrario è consigliabile utilizzare query asincrone per tempi di caricamento ottimali delle pagine.

• Una web part Riquadro di perfezionamento con molti criteri di affinamento comporta un aumento del tempo di elaborazione di una query. È possibile cambiare il numero di criteri di affinamento da visualizzare per una proprietà gestita. Per ulteriori informazioni, vedere Configurare criteri di affinamento ricerca e l'esplorazione in base a facet in SharePoint Server.

• Se si utilizza la web part Riquadro affinamento tassonomia in presenza di una gerarchia complessa di nodi di navigazione, il tempo di elaborazione di una query aumenta. Non è consigliabile utilizzare questa web part in una pagina con più di 200 nodi di navigazione sottostanti. Il numero elevato di nodi di navigazione può comportare un rallentamento dei tempi di risposta del server e della velocità effettiva.

• Se è necessario progettare una distribuzione di SharePoint con disponibilità elevata, aggiungere i seguenti elementi:

  • Un computer aggiuntivo eseguito con le applicazioni di servizio nei ruoli della cache distribuita qualora il computer esistente non sia disponibile

  • Computer aggiuntivi in grado di sostenere il carico qualora uno o più computer server Web front-end con nodi di indice non siano disponibili

  • Un computer aggiuntivo con ruoli di elaborazione del contenuto per garantire la distribuzione degli aggiornamenti nel sito anche se il computer con il ruolo di elaborazione del contento non è disponibile

  • Una topologia di SQL Server che continua a gestire le query di database qualora uno dei server di database non sia disponibile

Velocità della ricerca per indicizzazione e livello di aggiornamento del contenuto

Sono stati anche eseguiti test del processo di aggiornamento del contenuto del catalogo pubblicato. È stata analizzata quindi la quantità di tempo trascorsa prima della visualizzazione di un elemento aggiornato nel sito di pubblicazione. Negli esperimenti eseguiti sono stati effettuati cinque aggiornamenti al secondo nel catalogo e sono state impostate ricerche per indicizzazione continue nel catalogo a intervalli di un minuto. Il tempo medio di visualizzazione delle modifiche nel sito di pubblicazione osservato è stato di due minuti. Il tempo minimo è stato inferiore a un minuto e il tempo massimo è stato di tre minuti. Non sono stati osservati scostamenti significativi da questi valori aumentando il numero di computer eseguiti con il ruolo di elaborazione del contenuto.

Per la ricerca per indicizzazione completa nel catalogo tuttavia è stato osservato che un aumento del numero di computer con il ruolo di elaborazione del contenuto ha comportato un aumento del numero di elementi elaborati al secondo. Nel grafico riportato di seguito viene mostrata la relazione tra gli elementi elaborati al secondo e il numero di computer della farm con ruolo di elaborazione del contenuto. Si noti che questi dati di test sono stati ottenuti da una distribuzione di SharePoint diversa da quella utilizzata nei test di base. I risultati rilevati dovrebbero applicarsi alle distribuzioni di SharePoint poiché l'aggiunta di ulteriori modi di elaborazione del contenuto comportano un miglioramento dei tempi delle ricerche per indicizzazione complete.

Figura 4: effetto dei computer di elaborazione del contenuto su una ricerca per indicizzazione completa

Se pertanto si necessita di ricerche per indicizzazione complete più veloci per i cataloghi, è possibile aumentare il numero di computer con ruolo di elaborazione del contenuto nella distribuzione.

Carico sull'applicazione di servizio metadati gestiti

Dai test risulta che gli scenari di pubblicazione con siti in cui viene utilizzata l'esplorazione gestita non presentano requisiti significativi di memoria o CPU nell'applicazione di servizio metadati gestiti. Per una distribuzione come quella descritta precedentemente, l'applicazione di servizio metadati gestiti può essere eseguita in un computer che esegue altre applicazioni di servizio di SharePoint. La funzionalità esplorazione gestita effettua una connessione all'applicazione di servizio quando riceve la prima richiesta per un sito. Nelle richieste successive vengono utilizzati valori memorizzati nella cache dai server Web front-end. Non viene applicato pertanto alcun carico sull'applicazione di servizio metadati gestiti mentre i server Web front-end gestiscono le richieste.

Cache dei risultati di ricerca anonima

Nella cache dei risultati di ricerca anonima vengono archiviati i risultati di una query, i dati di perfezionamento per la query e ulteriori tabelle di risultati restituite dal servizio cache distribuita di SharePoint. Ogni voce della cache dipende dai parametri di una query, ad esempio l'ordinamento dei risultati, i criteri di affinamento richiesti ed eventuali regole di ridisposizione dinamica. La cache influisce su tutte le query gestite da un'applicazione Web, incluse le query di web part di ricerca e client CSOM. Per ulteriori informazioni, vedere Panoramica dell'architettura di ricerca in SharePoint Server e Implementare la scalabilità della ricerca per i siti Internet in SharePoint Server.

Questa cache non viene utilizzata per le query autenticate per motivi di sicurezza.

Per ottenere risultati ottimali, è consigliabile configurare il servizio cache distribuita in modo che venga eseguito solo nel computer che esegue le applicazioni di servizio di SharePoint. Il servizio cache distribuita non deve essere eseguito nei computer con ruoli del server Web front-end.

Per impostazione predefinita, nella cache dei risultati di ricerca anonima gli elementi vengono aggiornati ogni 15 minuti. È possibile utilizzare Microsoft PowerShell per configurare la durata della cache nell'applicazione Web in cui è configurata la cache:

$webapp.Properties["SearchResultsCacheTTL"] = <number of seconds to keep in cache> 
$webapp.Update()

Se si desidera che i risultati di ricerca vengano aggiornati più frequentemente rispetto al valore predefinito, impostare un valore inferiore. Si noti che in questo modo aumenta il numero di query che dovranno essere gestite dal servizio di ricerca.

È consigliabile utilizzare sempre la cache nelle pagine di pubblicazione con traffico intenso. Alcuni esempi di questi tipi di pagine sono rappresentati dalla home page del sito e dalle pagine di categoria in cui vengono utilizzate web part di ricerca. Non è consigliabile utilizzare la memorizzazione nella cache per le pagine degli elementi di catalogo. Poiché gli accessi a una pagina di elementi di catalogo sono molto meno frequenti rispetto agli accessi a una home page, potrebbe essere inutile archiviare l'elemento nella cache.

Disattivando la cache dei risultati di ricerca anonima nell'ambiente di testing con gli stessi modelli di carico, i tempi di risposta del server sono aumentati in modo significativo e la velocità effettiva in numero di visualizzazioni pagina al secondo è diminuita. Viene riportato di seguito un grafico in cui viene mostrata questa relazione:

Figura 5: effetto della cache dei risultati di ricerca anonima

Per impostazione predefinita, le web part Ricerca contenuto sono configurate per l'utilizzo della cache dei risultati di ricerca anonima. Le web part Riutilizzo elemento catalogo, che vengono utilizzate nelle pagine di elementi di catalogo, non sono configurate invece per utilizzare questa cache a causa dei modelli di accesso ridotto generalmente rilevati in queste pagine.

Per configurare il comportamento di memorizzazione nella cache per una singola web part in modo da utilizzare o non utilizzare la cache dei risultati di ricerca anonima, impostare il valore della proprietà secondaria "TryCache" nella proprietà DataProviderJSON della web part. Se il valore è "true", la query utilizzerà la cache. Se invece il valore è "false", la query non utilizzerà la cache per le query di ricerca anonima.

Effetto della cache di output

La cache di output è un modo efficace per ridurre il carico SharePoint Server 2013 negli scenari di pubblicazione. Per ulteriori informazioni sul funzionamento della Cache di Output in questo articolo, vedere memorizzazione nella cache di Output e profili di Cache.

Una distribuzione di SharePoint può trarre vantaggio dalla memorizzazione nella cache di output per ridurre il carico sui database del contenuto di SharePoint e sull'applicazione del servizio di ricerca. Vengono riportate di seguito alcune situazioni di esempio:

• Viene ricevuto un traffico elevato in alcune pagine.

• Viene ricevuto un traffico elevato nei database del contenuto di SharePoint.

• I computer che gestiscono le query di ricerca vengono eseguiti con un utilizzo elevato della CPU.

È consigliabile utilizzare la memorizzazione nella cache di output per le pagine più visitate del sito, ad esempio la home page o le pagine di categoria principale del sito e alcune pagine di elemento con traffico intenso.

Importante

Non esiste un problema noto in SharePoint Server 2013 quando pagine con la cache di Output attivata inoltre contengano Web part ricerca contenuto. Per evitare questo problema della distribuzione, installare aggiornamento di SharePoint Server 2013: 12 marzo 2013.

Nel grafico riportato di seguito vengono mostrati alcuni risultati ottenuti nell'ambiente di testing con l'utilizzo della memorizzazione nella cache di output nella home page e nelle pagine di categoria che ricevono il 60% del traffico del sito.

Figura 6: effetto della memorizzazione nella cache di output sulla home page e le pagine di categoria

Nota

Nelle web part Ricerca contenuto è disponibile un'impostazione per l'esecuzione in modalità asincrona. La memorizzazione nella cache di output non si applica al carico delle web part Ricerca contenuto anonime.

Elaborazione dell'analisi dei dati di utilizzo

Per ottenere informazioni sugli analitica utilizzo pronto per l'utilizzo, SharePoint Server 2013 elabora le informazioni in questo database. La topologia di elaborazione Analitica disponibile nel nodo che contiene i nodi di amministrazione delle ricerche, servizio Cache distribuita e altre applicazioni di servizio. Per ulteriori informazioni, vedere Panoramica dell'elaborazione dell'analisi in SharePoint Server

È necessario alcuni analitica le misure del tempo di elaborazione tramite il sito di pubblicazione intersito, che viene utilizzate nei test precedenti. Viene misurata la fase di tale SharePoint Server 2013 abbia per elaborare una grande quantità di fare clic su eventi nelle pagine del sito. Anche se questi risultati da un sito di pubblicazione intersito, vengono applicate anche a siti che utilizzano il metodo di pubblicazione autore sul posto.

Per i test sull'elaborazione dell'analisi dei dati di utilizzo, sono stati generati i seguenti eventi fittizi ogni giorno per una settimana:

• 27,5 milioni di eventi clic distribuiti su 3 milioni di elementi elenco e 400.000 utenti.

  È stata utilizzata la distribuzione di Zipf, in modo che alcuni elementi e utenti siano associati a molti eventi e altri a un numero inferiore.

In questo modo è stato generato un totale di 7,5 milioni di eventi al giorno, simulando utenti diversi che generano modelli di traffico diversi per il sito.

L'esecuzione dell'analisi è stata attivata sette volte per simulare una settimana di traffico. Ogni giorno è stato eseguito il processo Analisi uso per i dati accumulati in sei giorni. È stato misurato quindi il tempo impiegato il settimo giorno, ovvero il giorno in cui è richiesto più tempo per l'elaborazione, poiché vengono elaborati gli elementi dell'intera settimana e viene aggiornato il grafico delle relazioni. La fase di esecuzione e l'utilizzo del disco per l'ottavo giorno sono simili a quelli del primo giorno.

L'elaborazione dell'analisi non ha prodotto un impatto significativo sul computer in cui è stata eseguita ed è stato possibile continuare a gestire le query e a mantenere aggiornato il contenuto nel sito basato sulla ricerca.

I risultati sono riepilogati nella tabella riportata di seguito:

Pianificazione test	Aggiornamento grafico relazioni	Tempo di esecuzione (ore)	Utilizzo massimo disco totale	Utilizzo massimo disco analisi dati utilizzo
Giorno 1	No	02.35		2,65 GB
Giorno 2	No	02.43
Giorno 3	No	03.23
Giorno 4	No	04.39
Giorno 5	No	06.08
Giorno 6	No	07.35
Giorno 7	Sì	08.29	82,4 GB	4 GB

Nel seguente grafico vengono visualizzati i tempi di esecuzione per i diversi giorni:

Figura 7: ore di tempo di esecuzione al giorno

Pubblicazione intersito con utenti autenticati

Pubblicazione di SharePoint viene utilizzata in genere nei siti intranet. Utilizzando SharePoint Server 2013, questi siti possono inoltre essere con tecnologia la pubblicazione intersito. Nelle sezioni seguenti mostrano alcune distinzioni importanti da considerare quando si pianifica un sito di pubblicazione intersito, che utilizza gli utenti autenticati. Diverso da eccezioni indicate nelle sezioni seguenti, le regole che si applicano ai siti a cui si accede in modo anonimo comunque valide per i siti che agli utenti l'accesso autenticato.

Assenza della cache dei risultati di ricerca anonima

Come indicato nella sezione Cache dei risultati di ricerca anonima più indietro in questo articolo, questa cache ha effetto solo sugli utenti che accedono al sito di SharePoint in modalità anonima. Rispetto ai siti con accesso anonimo in cui viene utilizzata la cache dei risultati di ricerca anonima, la capacità di velocità effettiva dei siti a cui accedono utenti autenticati sarà decisamente inferiore. I siti Intranet in genere ricevono raramente carichi elevati come quelli indicati nella sezione precedente (fino a 100 visualizzazioni pagina/secondo). Questa tuttavia è un'importante distinzione di cui tenere conto.

L'utilizzo della cache di output può compensare in parte l'assenza della cache dei risultati di ricerca anonima per questi scenari. È consigliabile valutare la possibilità di abilitare la cache di output per i siti di pubblicazione intersito in cui sono previste più visualizzazioni pagina al secondo.

Importante

Nelle web part Ricerca contenuto è disponibile un'impostazione che, se abilitata, ne consente l'esecuzione in modalità asincrona. La cache di output non si applica al carico delle web part Ricerca contenuto asincrone.

Indice di ricerca di dimensioni maggiori

A seconda delle dimensioni dell'organizzazione che consente di distribuire SharePoint Server 2013, distribuzioni intranet per SharePoint Server 2013 consente in genere l'indicizzazione numero più elevato di documenti. Ciò significa che la topologia di ricerca necessaria per indicizzare i documenti è diversa rispetto alla topologia descritta nella sezione precedente. Fare riferimento a Pianificare la ricerca in SharePoint Server per impostare le dimensioni della distribuzione di SharePoint in modo appropriato.

Pubblicazione con creazione e modifica sul posto

In questa sezione vengono fornite indicazioni e i risultati che utilizzano SharePoint Server 2013, ma non descrive le diverse caratteristiche che influiscono sulla pianificazione della capacità. Per informazioni dettagliate in quest ' area, vedere Pianificare la gestione del contenuto Web in SharePoint Server.

Pubblicazione con creazione e modifica sul posto con utenti anonimi

Per i test è stato utilizzato un sito Web con le seguenti caratteristiche:

• Sito Web con un massimo di 20.000 pagine di articolo divise in 20 cartelle da 1000 pagine ciascuna su 50 siti di una singola raccolta siti.

• Nel sito viene utilizzata l'esplorazione strutturata.

• Il sito riceve in genere un minimo di 50-100 visualizzazioni pagina al secondo.

• I modelli di traffico si applicano alla seguente combinazione di pagine:

  • 20 pagine contenenti una singola web part Query contenuto che invia query di database del contenuto con ambiti diversi (20% del traffico)

  • 30 pagine che includono più web part Query contenuto che inviano query di database del contenuto con ambiti diversi (30% del traffico)

  • 1600 articoli con 40 k di testo e due immagini (50% del traffico)

Nella figura riportata di seguito viene illustrata la topologia di server consigliata:

Figura 8: topologia per i test della pubblicazione con creazione e modifica sul posto

• Un computer che ospita SQL Server

• Un computer che ospita le applicazioni di servizio di SharePoint come server Web front-end

Risultati del laboratorio di testing

Nel laboratorio di testing è stata utilizzata la topologia mostrata nella figura precedente con computer fisici e un test di carico Visual Studio Team System.

Nella seguente tabella vengono riportate le specifiche tecniche utilizzate nei computer testati:

Componenti server	SharePoint Server
Processori	CPU Intel Xeon @ 2,33 GHz (2 processori, totale di 8 core, totale di 8 thread)
RAM	24 GB
Sistema operativo	Windows Server 2008 R2 Enterprise, 64 bit
Numero di schede di rete	2
Velocità delle schede di rete	1 Gb/s
Autenticazione	Nessuna - Anonimo
Tipo di bilanciamento del carico	Bilanciamento del carico del software Windows
Versione software	SharePoint Server 2013

Componenti server	Server di database
Processori	CPU Intel Xeon MP7130M @ 2,79 GHz (2 processori, totale di 8 core, totale di 16 thread)
RAM	16 GB
Sistema operativo	Windows Server 2008 R2 Enterprise, 64 bit
Array di dischi	2 x Dell PERC 5/E
Numero di schede di rete	1
Velocità delle schede di rete	1 gigabit o Gb/s
Autenticazione	NTLM
Versione software	Microsoft SQL Server 2008 R2 SP1

Nella seguente tabella vengono mostrati i risultati per un'esecuzione di 10 minuti:

Caratteristiche dei test	Area verde	Area rossa
Numero di utenti VSTS:	5	15
50° percentile del tempo di risposta del server:	69 ms	112 ms
95° percentile del tempo di risposta del server:	92 ms	221 ms
Visualizzazioni pagina al secondo:	57	93
Utilizzo medio della CPU (server applicazioni e server Web front-end)	55	97
Utilizzo medio della CPU (SQL Server)	7	9
Utilizzo massimo della memoria (server applicazioni e server Web front-end)	8,9 GB	8,9 GB

Effetto della cache di output

La cache di output è un modo efficace per ridurre il carico SharePoint Server 2013 negli scenari di pubblicazione. Per ulteriori informazioni, vedere Pianificare la memorizzazione nella cache e le prestazioni in SharePoint Server.

Nella tabella riportata di seguito vengono mostrati i risultati per un'esecuzione di 10 minuti con la cache di output abilitata e un rapporto riscontri del 90%:

Caratteristiche dei test	Area verde	Area rossa
Numero di utenti VSTS:	5	15
50° percentile del tempo di risposta del server:	2 ms	2 ms
95° percentile del tempo di risposta del server:	74 ms	88 ms
Visualizzazioni pagina al secondo:	190	418
Utilizzo medio della CPU (server applicazioni e server Web front-end)	58	85
Utilizzo medio della CPU (SQL Server)	5	7
Utilizzo massimo della memoria (server applicazioni e server Web front-end)	9,2 GB	9,4 GB

Dai risultati dei test si osserva che l'utilizzo della memorizzazione nella cache di output può determinare un aumento significativo della velocità effettiva di un sito di pubblicazione di SharePoint e ridurre i tempi di risposta del server. Per le richieste gestite dalla cache di output, i tempi di risposta sono quasi immediati.

Nel grafico seguente viene mostrato un riepilogo dei risultati dei test:

Figura 9: effetto della memorizzazione nella cache di output con un rapporto riscontri cache del 90%

Effetto dell'esplorazione gestita

In SharePoint Server 2013, i siti di pubblicazione possono inoltre utilizzare esplorazione gestita. Per informazioni dettagliate sulla configurazione, vedere Panoramica dell'esplorazione gestita in SharePoint Server.

Per il sito di test con l'esplorazione gestita è stato eseguito lo stesso insieme di test utilizzato per i test di esplorazione strutturata. Dai test risulta che non esistono differenze significative delle prestazioni quando nei siti viene utilizzata l'esplorazione gestita o l'esplorazione strutturata.

Caratteristiche dei test	Area verde	Area rossa
Numero di utenti VSTS:	5	15
50° percentile del tempo di risposta del server:	70 ms	111 ms
95° percentile del tempo di risposta del server:	95 ms	215 ms
Visualizzazioni pagina al secondo:	56	94
Utilizzo medio della CPU (server applicazioni e server Web front-end)	54	97
Utilizzo medio della CPU (SQL Server)	7	9
Utilizzo massimo della memoria (server applicazioni e server Web front-end)	8 GB	8 GB

Nel seguente grafico vengono mostrati i diversi tipi di esplorazione per lo stesso sito:

Figura 10: esplorazione gestita ed esplorazione strutturata

Effetto dell'aggiunta di computer (scalabilità orizzontale)

Se si rileva che è necessario velocità effettiva più di una distribuzione di SharePoint, la scalabilità orizzontale (l'aumento del numero di computer che ospitano SharePoint Server 2013 ) è possibile utilizzare l'opzione. Il grafico seguente mostra come la velocità effettiva aumenta man mano che si aggiungono più computer nella farm:

Figura 11: effetto dell'aggiunta di server Web front-end sulla velocità effettiva

I risultati dei test viene aumentato il carico sui server che esegue SharePoint Server 2013 per ogni computer in cui è stato aggiunto in modo che i tempi di risposta del server sono circa lo stessi (circa 11 millisecondi per l'area verde circa 250 millisecondi per l'area rossa).

Siti di pubblicazione con creazione e modifica sul posto con utenti autenticati

La funzionalità di pubblicazione di SharePoint viene utilizzata in genere nella rete Intranet, in cui gli utenti che accedono a un sito vengono autenticati. In questa sezione vengono mostrati i test in cui sono stati utilizzati utenti autenticati e gli effetti prodotti.

Nella tabella riportata di seguito vengono mostrati i risultati dei test di siti di pubblicazione con creazione e modifica sul posto a cui gli utenti autenticati hanno avuto accesso mediante autenticazione basata sulle attestazioni con NTLM. Si noti che in questi test viene utilizzato lo stesso hardware dei test della sezione precedente.

Caratteristiche dei test	Area verde	Area rossa
Numero di utenti VSTS:	5	15
50° percentile del tempo di risposta del server:	76 ms	107 ms
95° percentile del tempo di risposta del server:	103 ms	194 ms
Visualizzazioni pagina al secondo:	54	100
Utilizzo medio della CPU (server applicazioni e server Web front-end)	50	97
Utilizzo medio della CPU (SQL Server)	6	9
Utilizzo massimo della memoria (server applicazioni e server Web front-end)	9,5 GB	9,5 GB

Da questi numeri risulta che non esiste una differenza significativa tra richieste anonime e richieste autenticate per tempi di riposta e velocità effettiva del server.

Nel seguente grafico vengono mostrati i diversi tipi di richieste per lo stesso sito:

Figura 12: richieste anonime e richieste autenticate

Effetto della cache di output in scenari autenticati

Le richieste autenticate nel server richiedono un round trip nel database del contenuto per verificare che l'account che accede al contenuto disponga delle autorizzazioni di visualizzazione. Le caratteristiche delle prestazioni di memorizzazione nella cache di output dei siti autenticati sono pertanto diverse rispetto ai siti anonimi.

Nella tabella riportata di seguito vengono mostrati i risultati per un'esecuzione di 10 minuti con la cache di output abilitata e un rapporto riscontri cache del 90%:

Caratteristiche dei test	Area verde	Area rossa
Numero di utenti VSTS:	6	18
50° percentile del tempo di risposta del server:	17 ms	29 ms
95° percentile del tempo di risposta del server:	87 ms	118 ms
Visualizzazioni pagina al secondo:	114	236
Utilizzo medio della CPU (server applicazioni e server Web front-end)	50	97
Utilizzo medio della CPU (SQL Server)	7	10
Utilizzo massimo della memoria (server applicazioni e server Web front-end)	9,9 GB	10 GB

Nel seguente grafico viene mostrato il riepilogo di questi risultati:

Figura 13: effetto della memorizzazione nella cache di output autenticata

See also

Pianificare la gestione del contenuto Web in SharePoint Server
Configurare le soluzioni di gestione del contenuto web in SharePoint Server
Amministrazione di gestione del contenuto web in SharePoint Server
Configure cache settings for a web application in SharePoint Server
Pianificare la memorizzazione nella cache e le prestazioni in SharePoint Server