Stimare capacità e prestazioni per la gestione del contenuto Web (SharePoint Server 2013)
SI APPLICA A:
2013 
2016 2019 Subscription Edition SharePoint in Microsoft 365
Le aziende usano spesso SharePoint Server 2013 per pubblicare contenuto a cui gli utenti anonimi accedono in un sito Internet o a cui gli utenti autenticati accedono in un sito Intranet. Questo articolo contiene dati sulla capacità e sulle prestazioni che consentono di pianificare il numero di computer da usare e i tipi di computer necessari per pubblicare contenuto e gestire il contenuto Web in SharePoint Server 2013.
La pubblicazione in SharePoint include tipi diversi di siti di pubblicazione e metodi associati disponibili per ogni sito. Le funzionalità di pubblicazione di SharePoint Server 2013 consentono di creare siti Internet, Intranet ed Extranet di marca. Per altre informazioni sulla pubblicazione di 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.
Lo spostamento gestito in SharePoint Server 2013 offre la navigazione 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
Tempo necessario per l'elaborazione di una richiesta da parte del server, che influisce sul tempo necessario a un utente per visualizzare la pagina. I tempi di risposta del server specificati in questo documento sono i valori del 95° e del 50° percentile. Questi valori indicano che il 95% e il 50% delle richieste sono rispettivamente più veloci del valore fornito. Questi valori vengono misurati usando la "Durata" registrata nel database 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 comprendere i concetti chiave alla base della gestione della capacità di SharePoint Server 2013. Negli articoli seguenti verrà descritto l'approccio consigliato per la gestione della capacità e verrà fornito il contesto per un utilizzo efficace delle informazioni presentate.
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 altre informazioni, vedere Pianificare la pubblicazione tra siti in SharePoint Server e Configurare soluzioni di gestione del contenuto Web in SharePoint Server.
Per altre informazioni sulla capacità e sulle prestazioni per comprendere i dati in questo articolo, vedere Pianificazione delle prestazioni 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 usati 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 in questo test sono computer fisici che eseguono Windows Server 2008 R2. Per consigli su come usare le macchine virtuali e Windows Server 2012, vedere Pianificazione della capacità di ricerca e Pianificazione della capacità per SharePoint Server 2013 .
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 lab di test si è appreso che il computer che ospita il server applicazioni era sottoutilizzato. 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
Per il laboratorio di testing è stata utilizzata la topologia illustrata nella figura 1 con computer fisici e un test di carico Visual Studio Team System (VSTS). Per altre informazioni, vedere Visual Studio Team System. Le specifiche tecniche per i computer di test sono illustrate nelle tabelle riportate di seguito.
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 usate nei test hanno eseguito quasi 50 tipi di richiesta PLT1 (Page Load Time 1) (cache del browser vuota) e circa 3 richieste per i tipi di richiesta PLT2 (richieste successive con risultati 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, a 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 | Nessuno - 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, a 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 di scalabilità orizzontale. Le prestazioni effettive cambieranno a seconda di come viene compilata la 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.
Più elementi nell'indice di ricerca in genere indicano una latenza più elevata. Ogni partizione di indice può contenere fino a 10 milioni di elementi. I siti Web tipici raramente hanno più di 10 milioni di elementi da mostrare. È quindi necessaria una sola partizione, come nella topologia descritta in precedenza. È possibile usare più partizioni di indice per ospitare più di 10 milioni di elementi o per avere più partizioni di indice, più piccole e più veloci. Se si prevede di usare più partizioni di indice, vedere Ridimensionare la ricerca di siti Internet in SharePoint Server per ridimensionare correttamente la 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 web part Ricerca contenuto o Riutilizzo elemento catalogo sincrone in una pagina. Durante l'elaborazione di una richiesta per una pagina, SharePoint Server 2013 esegue fino a cinque query in parallelo e restituisce i risultati. Se sono presenti più di cinque query in una pagina, SharePoint Server 2013 esegue le prime cinque query prima di iniziare a eseguire il set successivo di cinque query. Se le pagine richiedono più di cinque web part Ricerca contenuto o Riutilizzo elemento catalogo, è possibile eseguire le web part Ricerca contenuto aggiuntive in modalità asincrona oppure utilizzare 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 altre informazioni, vedere Configurare criteri di affinamento affinamento e spostamento 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
Topologia di SQL Server che continua a gestire le query di database se uno dei server di database non è 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 altre informazioni, vedere Panoramica dell'architettura di ricerca in SharePoint Server e Scalare la ricerca di 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 usare 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. Ecco un grafico che mostra 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 per l'uso (o meno) della cache dei risultati della ricerca anonima, impostare il valore della proprietà "TryCache" nella DataProviderJSON proprietà della web part. Se il valore è "true", la query usa la cache. Se il valore è "false", la query non usa la cache per le query di ricerca anonime.
Effetto della cache di output
La memorizzazione nella cache di output è un modo efficace per ridurre il carico su SharePoint Server 2013 negli scenari di pubblicazione. Per altre 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 usare la memorizzazione nella cache di output per le pagine molto popolari del sito, ad esempio la home page del sito o le pagine di categoria di primo livello e alcune pagine di elementi che ricevono grandi quantità di traffico.
Importante
Esiste un problema noto in SharePoint Server 2013 quando le pagine in cui è abilitata la memorizzazione nella cache di output contengono anche web part ricerca contenuto. Per evitare questo problema nella distribuzione, installare l'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 avere informazioni sull'analisi di utilizzo pronte per l'uso, SharePoint Server 2013 elabora le informazioni presenti nel database di utilizzo. Nella topologia l'elaborazione dell'analisi dei dati di utilizzo viene eseguita nel nodo contenente il nodo di amministrazione della ricerca, il servizio cache distribuita e altre applicazioni di servizio. Per altre informazioni, vedere Panoramica dell'elaborazione dell'analisi in SharePoint Server
Sono state effettuate alcune misurazioni dei tempi di elaborazione dell'analisi utilizzando il sito di pubblicazione intersito dei test precedenti. È stato misurato il tempo impiegato da SharePoint Server 2013 per elaborare una grande quantità di eventi click nelle pagine del sito. Benché questi risultati siano relativi a un sito di pubblicazione intersito, si applicano anche ai siti in cui viene utilizzato il metodo di pubblicazione con creazione e modifica 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'analisi è stata attivata sette volte per simulare una settimana di traffico. È stato eseguito il processo di analisi dell'utilizzo ogni giorno per i dati accumulati in sei giorni. Poi abbiamo misurato il tempo, il settimo giorno ha preso. Il settimo giorno sarà il giorno che richiede più tempo per l'elaborazione man mano che gli elementi della settimana completa vengono elaborati e il grafico delle relazioni viene aggiornato. Il runtime e l'utilizzo del disco per il giorno 8 saranno simili al giorno 1.
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
La funzionalità di pubblicazione di SharePoint viene utilizzata in genere nei siti Intranet. Usando SharePoint Server 2013, questi siti possono anche essere basati sulla pubblicazione tra siti. Nelle sezioni riportate di seguito vengono illustrate alcune importanti distinzioni di cui tenere conto per la pianificazione di un sito di pubblicazione intersito con utenti autenticati. Oltre alle eccezioni illustrate nelle sezioni che seguono, le regole valide per i siti con accesso anonimo si applicano anche ai siti con accesso di utenti autenticati.
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 distribuisce SharePoint Server 2013, le distribuzioni Intranet per SharePoint Server 2013 in genere indicizzano un numero maggiore di documenti. Questo comporta una topologia di ricerca per l'indicizzazione dei documenti diversa rispetto a quella descritta nella sezione precedente. Fare riferimento a Pianificare la ricerca in SharePoint Server per ridimensionare la distribuzione di SharePoint in modo appropriato.
Pubblicazione con creazione e modifica sul posto
Questa sezione fornisce indicazioni e risultati che usano SharePoint Server 2013, ma non descrive in dettaglio le diverse funzionalità che influiscono sulla pianificazione della capacità. Per informazioni dettagliate su questa area, vedere 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, a 64 bit |
| Numero di schede di rete | 2 |
| Velocità delle schede di rete | 1 Gb/s |
| Autenticazione | Nessuno - 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, a 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 memorizzazione nella cache di output è un modo efficace per ridurre il carico su 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 anche usare lo spostamento gestito. Per informazioni dettagliate su come configurare questa funzionalità, vedere Panoramica dello spostamento gestito 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 ritiene che sia necessaria una maggiore velocità effettiva da una distribuzione di SharePoint, la scalabilità orizzontale (aumentando il numero di computer che ospitaNo SharePoint Server 2013) è un'opzione da considerare. Nel seguente grafico viene mostrato l'aumento della velocità effettiva con l'aggiunta di computer alla farm:
Figura 11: effetto dell'aggiunta di server Web front-end sulla velocità effettiva
Nei test è stato aumentato il carico sul server che esegue SharePoint Server 2013 per ogni computer aggiunto in modo che i tempi di risposta del server fossero approssimativamente uguali (circa 11 millisecondi per la zona verde, circa 250 millisecondi per la zona 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
Vedere anche
Concetti
Pianificare la gestione del contenuto Web in SharePoint Server
Configurare soluzioni di gestione del contenuto Web in SharePoint Server
Configurare le impostazioni della cache per un'applicazione Web in SharePoint Server
Pianificare la memorizzazione nella cache e le prestazioni in SharePoint Server