Stimare i requisiti di prestazioni e capacità per ambienti di collaborazione su Intranet aziendale (SharePoint Server 2013)

 

**Si applica a:**SharePoint Server 2013

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

**Riepilogo:**utilizzare i risultati dei test e i suggerimenti riportati in questo articolo per stimare i requisiti di prestazioni e capacità per una soluzione di collaborazione su Intranet aziendale per SharePoint Server 2013.

In questo articolo contiene informazioni aggiuntive sulle prestazioni e pianificazione della capacità per una soluzione di collaborazione intranet aziendale basata su SharePoint Server 2013. Include le operazioni seguenti:

  • Specifiche dell'ambiente lab, ad esempio hardware, topologia della farm e configurazione

  • Carico di lavoro della farm di testing e set di dati utilizzati per generare il carico dei test

  • Risultati dei test e analisi che dimostrano e spiegano le tendenze in termini di velocità effettiva, latenza e richiesta di hardware sotto carico in punti specifici dell'implementazione della scalabilità.

Utilizzare le informazioni presenti in questo articolo per comprendere le caratteristiche dello scenario sia con un carico normale sia con un carico di picco e le variazioni nelle tendenze relative alle prestazioni quando il numero dei server della farm viene incrementato mediante implementazione della scalabilità orizzontale. Questo articolo può inoltre rivelarsi utile per stimare un punto di partenza appropriato per l'architettura pianificata e i fattori importanti da considerare quando si effettua la pianificazione delle risorse che saranno necessarie alla farm per mantenere livelli accettabili di prestazioni con il carico di picco.

Contenuto dell'articolo:

  • Introduzione all'ambiente

  • Glossario

  • Panoramica

  • Specifiche

  • Risultati e analisi

Introduzione all'ambiente

In questo articolo vengono fornite indicazioni sulla scalabilità orizzontale server in una soluzione di collaborazione intranet aziendale SharePoint Server 2013. Pianificazione della capacità informa decisioni sull'hardware per le configurazioni di acquisto e di sistema che ottimizzare la soluzione.

Farm singola SharePoint Server 2013 sono univoche e ogni farm sono elencati i requisiti diversi che dipendono da hardware, il comportamento degli utenti, la configurazione delle caratteristiche installate e molti altri fattori. Di conseguenza, complemento queste linee guida con ulteriori verifiche prevista nel proprio ambiente. Se la progettazione pianificati e carico di lavoro utilizza il formato dell'ambiente descritta in questo articolo, è possibile utilizzare questo articolo per disegnare conclusioni su come implementare la scalabilità dell'ambiente.

I risultati dei test riportati in questo articolo sono stati prodotti in un laboratorio di testing utilizzando un carico di lavoro, un set di dati e un'architettura che emulano un ambiente di produzione in condizioni strettamente controllate. Anche se questi test sono stati progettati con la massima cura, le caratteristiche di prestazioni di un laboratorio di testing non sono mai tali da riprodurre esattamente il comportamento di un ambiente di produzione. Tali risultati dei test non rappresentano quindi le caratteristiche di prestazioni e capacità di una farm di produzione, ma dimostrano le tendenze osservate in termini di velocità effettiva, latenza e richiesta di hardware e forniscono un'analisi dei dati osservati che può essere utile per prendere decisioni su come pianificare la capacità e gestire la propria farm.

In questo articolo sono incluse le informazioni seguenti:

  • Specifiche, che comprendono hardware, topologia e configurazione

  • Carico di lavoro, che comprende un'analisi della richiesta per la farm, il numero degli utenti e le caratteristiche di utilizzo

  • Set di dati, ad esempio le dimensioni dei database e i tipi di contenuto

  • Risultati dei test e relativa analisi per incrementare il numero dei server Web mediante implementazione della scalabilità orizzontale

  • Confronto tra SharePoint Server 2010 e SharePoint Server 2013 velocità effettiva, latenza e le prestazioni dei server web nel server fisici e le macchine virtuali

Prima di leggere questo articolo, leggere gli articoli seguenti per verificare di avere compreso i concetti di base gestione della capacità in SharePoint Server 2013.

In tali articoli vengono fornite le informazioni seguenti:

  • Approccio consigliato per la gestione della capacità

  • Modalità da seguire per un utilizzo efficace delle informazioni presenti in questo articolo

  • Definizioni dei termini utilizzati all'interno di questo articolo

Glossario

Di seguito sono spiegati alcuni termini specializzati che verranno utilizzati all'interno di questo articolo.

  • Richieste al secondo (RPS): è il numero di richieste che una farm o un server riceve in un secondo. Questa è una misurazione comune del carico dei server e delle farm.

    Si noti che le richieste sono diverse dai caricamenti di pagine. Una pagina include numerosi componenti, ognuno dei quali genera una o più richieste quando un browser carica la pagina. Il caricamento di una pagina pertanto dà luogo a diverse richieste. Gli eventi e le verifiche di autenticazione che utilizzano risorse poco significative in genere non vengono conteggiati nelle misurazioni relative alle richieste al secondo.

  • Area verde: rappresenta un set definito di caratteristiche di carico in condizioni operative normali, fino ai carichi di picco giornalieri previsti. Una farm che opera in questo ambito deve essere in grado di offrire tempi di risposta e latenza entro parametri accettabili.

    Si tratta dello stato in cui il server può soddisfare il set di criteri seguente:

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

    • Tutti i server della farm mantengono una media di utilizzo della CPU inferiore al 60%.

      Nota

      Poiché in questo ambiente lab non era in esecuzione una ricerca per indicizzazione attiva, il server di database è stato mantenuto approssimativamente a una percentuale di utilizzo della CPU non superiore al 50% per riservare un 10% al carico della ricerca per indicizzazione. Questo presuppone che in produzione venga utilizzato Resource Governor di SQL Server per limitare il carico della ricerca per indicizzazione al 10% della CPU.

    • La percentuale di errori è inferiore allo 0,01%.

  • Area rossa (max): rappresenta un set definito di caratteristiche di carico in condizioni operative di picco. Nell'area rossa la farm ha un tasso molto elevato di richieste di risorse temporanee che può sostenere soltanto per periodi limitati prima che si verifichino errori e altri problemi di prestazioni e affidabilità.

    Si tratta dello stato in cui il server può soddisfare il set di criteri seguente per un periodo limitato:

    • La funzionalità di limitazione delle richieste HTTP è abilitata, ma non vengono restituiti errori 503 (server occupato).

    • La percentuale di errori è inferiore allo 0,1%.

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

    • Tutti i server della farm (esclusi i server di database) mantengono una media di utilizzo della CPU approssimativamente inferiore al 90%.

    • La media di utilizzo della CPU dei server di database è approssimativamente inferiore al 50%, pertanto viene riservato un ampio margine di sovraccarico in relazione al carico di ricerca per indicizzazione.

  • AxBxC (notazione nei grafici): indica rispettivamente il numero di server Web, server applicazioni e server di database presenti in una farm. 10x1x1 ad esempio indica che l'ambiente dispone di 10 server Web, 1 server applicazioni e 1 server di database.

  • MDF e LDF: SQL Server file fisici. Per ulteriori informazioni, vedere file e filegroup architettura

Panoramica

In questa sezione viene fornita una panoramica dell'approccio di implementazione della scalabilità e la metodologia di test utilizzati.

Approccio di implementazione della scalabilità

In questa sezione viene descritto l'approccio che è stato adottato per implementare la scalabilità nell'ambiente lab. Tale approccio consentirà di individuare la configurazione più adatta per il proprio carico di lavoro:

  1. Implementando la scalabilità orizzontale, è stato incrementato fino a quattro il numero dei server Web in uso. In ogni server viene eseguito il servizio cache distribuita.

  2. È stato aggiunto un server dedicato in cui viene eseguito il servizio cache distribuita.

  3. È stato disabilitato il servizio cache distribuita nei server Web.

  4. Sempre implementando la scalabilità orizzontale, il numero dei server Web è stato incrementato al massimo per l'ambito del testing.

  5. Sono stati eseguiti ulteriori test per confrontare le caratteristiche delle prestazioni di SharePoint Server 2013 e SharePoint Server 2010.

Metodologia e note sui test

Poiché in questo articolo vengono forniti i risultati provenienti da un ambiente lab di testing, è stato possibile controllare alcuni fattori per mostrare aspetti specifici delle prestazioni per questo carico di lavoro. Inoltre, determinati elementi dell'ambiente di produzione, inclusi nell'elenco riportato di seguito, non sono stati inseriti nell'ambiente lab per semplificare il sovraccarico dei test.

Nota

È consigliabile inserire tali elementi negli ambienti di produzione.

  • Tra un'esecuzione e l'altra dei test, è stata modificata una sola variabile alla volta per semplificare il confronto dei risultati.

  • I server di database non facevano parte di un cluster perché la ridondanza non era necessaria ai fini di questi test.

  • La ricerca per indicizzazione non era in esecuzione durante i test, ma ovviamente potrebbe esserlo in un ambiente di produzione. Per tenere conto di questo elemento, il livello di utilizzo della CPU di SQL Server nelle definizioni di "area verde" e "area rossa" è stato abbassato in modo da considerare le risorse che in genere verrebbero utilizzate da una ricerca per indicizzazione in esecuzione durante il testing.

Specifiche

In questa sezione vengono forniti i dettagli relativi all'hardware, al software, alla topologia e alla configurazione dell'ambiente lab.

Hardware

Nelle sezioni seguenti viene descritto l'hardware utilizzato in questo ambiente lab.

Importante

Tenere presente che tutti i server Web e i server applicazioni inclusi nel laboratorio di testing sono stati virtualizzati mediante l'utilizzo di host Hyper-V. I server di database non sono stati virtualizzati. Di seguito l'hardware degli host fisici e l'hardware virtuale delle macchine virtuali vengono indicati separatamente.

Host Hyper-V

Per il testing è stato utilizzato un totale di sei host Hyper-V configurati nello stesso modo. In ogni host vengono eseguite da una a due macchine virtuali.

Hardware degli host Valore

Processore/i

2 processori quad core a 2,49 GHz

RAM

32 GB

Sistema operativo

Windows Server 2008 R2 SP1

Numero di schede di rete

2

Velocità schede di rete

1 gigabit

Server Web e server applicazioni virtuali

Nella farm sono presenti da 1 a 10 server Web virtuali. In un ulteriore server virtuale dedicato viene eseguito il servizio cache distribuita.

Nota

In un ambiente di produzione i server dedicati che eseguono il servizio cache distribuita in genere sono distribuiti in una configurazione a disponibilità elevata. A scopo di test, è stato utilizzato un unico server dedicato per la cache distribuita perché la disponibilità elevata non era un fattore critico.

Hardware delle macchine virtuali WFE1-10 e DC1

Processori

4 processori virtuali

RAM

12 GB

Sistema operativo

Windows Server 2008 R2 SP1

Dimensione dell'unità di SharePoint

100 GB

Numero di schede di rete

2

Velocità schede di rete

10 gigabit (traffico tra host limitato alla velocità della scheda NIC dell'host)

Autenticazione

Windows NTLM

Tipo di bilanciamento del carico

F5 Big IP

Servizi in esecuzione localmente

WFE 1-10: servizi federati di base. Sono inclusi Servizio Timer di SharePoint, Servizio di traccia, Word Automation Services, Excel Services e Servizio codice in modalità sandbox di Microsoft SharePoint Foundation.

DC1: servizio cache distribuita.

Server di database

Un solo server di database fisico esegue l'istanza predefinita di SQL Server che dispone dei database di SharePoint. Il database di registrazione non viene trattato in questo articolo.

Nota

Se si abilita la generazione di report sull'uso, è consigliabile archiviare il database di registrazione in un numero di unità logica (LUN) separato. Le distribuzioni di grandi dimensioni e alcune distribuzioni medie potrebbero richiedere un server di database di registrazione dedicato per soddisfare la richiesta del processore per un elevato volume di log.
In questo ambiente lab sono stati applicati vincoli per la registrazione e il database di registrazione è stato archiviato in un'istanza separata di SQL Server.

Server di database - Istanza predefinita SPSQL

Processori

4 processori quad core a 2,4 GHz

RAM

32 GB

Sistema operativo

Windows Server 2008 R2 SP1

Archiviazione e geometria

Archiviazione DAS (Direct-Attached Storage)

1 volume di sistema (RAID0, 1 asse, 300 GB)

2 volumi di dati del contenuto (RAID0, 4 assi, 450 GB ognuno)

2 volumi di log del contenuto (RAID0, 2 assi, 450 GB ognuno)

1 volume di dati temp (RAID0, 2 assi, 300 GB ognuno)

1 volume di log temp (RAID0, 2 assi, 300 GB ognuno)

Numero di schede di rete

1

Velocità schede di rete

1 gigabit

Autenticazione

Windows NTLM

Versione software

SQL Server 2008 R2

Topologia

Nel diagramma riportato di seguito viene illustrata la topologia di questo ambiente lab.

This graph shows the lab topology for performance and capacity testing of the enterprise intranet collaboration scenario.

Configurazione

Per consentire prestazioni ottimali dei test e relazioni chiare tra i parametri e i risultati dei test, in questo ambiente lab sono state apportate le importanti modifiche di configurazione riportate di seguito.

Impostazione Valore Note

Site collection

179

Nelle raccolte siti dell'ambiente di testing vengono utilizzate le impostazioni predefinite e l'autenticazione basata su attestazioni di Windows.

Blob caching

On

È Off (disattivata) per impostazione predefinita. Se si abilita la cache BLOB, si migliora l'efficienza dei server riducendo le chiamate al server di database per risorse di pagine statiche che possono essere richieste frequentemente.

Max degree of parallelism (MAXDOP)

1

Questo parametro è impostato sull'istanza SQL Server o istanze che contengono i database del contenuto SharePoint Server 2013. Il valore predefinito è 0, che consente a SQL Server determinare il massimo grado di parallelismo. SharePoint Server 2013 richiede MAXDOP verrà impostata su 1 per le istanze di SQL Server contenenti SharePoint Server 2013 database.

Per ulteriori informazioni su come configurare l'impostazione MAXDOP per SQL Server 2008 R2, vedere opzione max degree of parallelism Option.

Per ulteriori informazioni su come configurare l'impostazione MAXDOP per SQL Server 2012, vedere Configure il massimo grado di parallelismo Server Configuration Option.

Carico di lavoro

In questa sezione vengono illustrati i test lab che vengono eseguiti su SharePoint Server 2013. I dettagli dei test sono tipici di un ambiente di collaborazione aziendale.

This graphic displays the breakdown of the performance test workload into operation categories.

Set di dati

Il set di dati per l'ambiente lab descritto in questo articolo, che rappresenta un ambiente di collaborazione aziendale tipico, include diverse raccolte siti, siti, elenchi, raccolte, tipi e dimensioni di file.

Caratteristiche del set di dati Valore

Dimensioni database (combinate)

174 GB

Dimensioni MDF

154 GB

Dimensioni LDF

20 GB

Dimensioni BLOB

152 GB

Numero di database del contenuto

2

Numero di raccolte siti

179

Numero di applicazioni Web

1

Numero di siti

1.471

Risultati e analisi

I risultati riportati di seguito sono ordinati in base all'approccio di implementazione della scalabilità descritto nella sezione Panoramica di questo articolo.

Implementazione della scalabilità orizzontale per i server Web

In questa sezione vengono illustrati i risultati dei test ottenuti quando nell'ambiente lab il numero dei server Web è stato incrementato implementando la scalabilità orizzontale.

Metodologia di test

  • Aggiungere server Web con le stesse specifiche hardware ed eseguire di nuovo il test senza apportare modifiche alla farm o ai parametri del test.

  • Misurare le richieste al secondo, la latenza e l'utilizzo delle risorse in ogni server della farm di testing.

Analisi

A seguito dei test eseguiti, è stato rilevato quanto segue:

  • Nell'ambiente i server Web sono diventati dieci per ogni server di database. L'incremento della velocità effettiva è stato piuttosto lineare.

  • Anche fino al numero massimo di dieci server Web testati, l'aggiunta di ulteriori server di database non ha determinato un aumento della velocità effettiva. Il collo di bottiglia in generale riguardava le risorse dei server Web.

  • La latenza media nell'area verde è stata quasi costante per tutta la durata del test. Il numero dei server Web e la velocità effettiva non hanno influito sulla latenza in tale area. I dati relativi alla latenza nell'area rossa mostrano una linea di tendenza prevista. La latenza è molto elevata in un singolo server Web. Una curva tra 2 e 10 server web rimane tranquillamente entro i criteri dell'area rossa.

    Nota

    La latenza può variare leggermente quando si sposta il servizio cache distribuita dai server Web di una farm a un server dedicato a tale cache. Questo può accadere perché il traffico relativo alla cache distribuita, che precedentemente era interno a ciascun server Web, inizia ad attraversare la rete. Verificare le prestazioni dopo aver implementato la scalabilità orizzontale nel proprio ambiente per stabilire se tale effetto negativo è significativo. Tenere presente che la latenza nell'ambiente di testing è aumentata lievemente dopo la migrazione del servizio cache distribuita in un server dedicato. La latenza è diminuita man mano che sono stati aggiunti server Web, in quanto la latenza aggiunta nominale è stata compensata da una riduzione del carico di elaborazione e memoria nei server Web.
    Per ulteriori informazioni sulla pianificazione della capacità della cache distribuita, vedere Pianificare i feed e il servizio cache distribuita in SharePoint Server.

  • Quando è stato eseguito il test delle prestazioni per SharePoint Server 2010, il server di database è diventato un collo di bottiglia alla velocità effettiva massima con quattro server web. I miglioramenti apportati alle caratteristiche di utilizzo della memorizzazione nella cache e il database in SharePoint Server 2013, medi di caricamento del livello di server di database è notevolmente inferiori rispetto a era SharePoint Server 2010 e non è stato necessario per la scalabilità dei server di database durante il test.

    Per ulteriori informazioni sui risultati dei test di SharePoint Server 2010 per questo scenario, vedere Studio di un ambiente lab di collaborazione su Intranet aziendale (SharePoint Server 2010).

  • I miglioramenti delle prestazioni quando si aggiungono server Web virtuali dipendono in parte dalle risorse hardware dell'host e dall'utilizzo delle risorse degli altri computer virtuali in esecuzione nello stesso host. La pianificazione della capacità per i server virtuali richiede ulteriori strategie di pianificazione e gestione specifiche della virtualizzazione.

    Per ulteriori informazioni sulla pianificazione delle prestazioni e della capacità di Hyper-V, vedere Requisiti di virtualizzazione Hyper-V per SharePoint 2013 e Utilizzare le configurazioni ottimali per le macchine virtuali e l'ambiente Hyper-V per SharePoint 2013.

Nota

Le conclusioni illustrate in questa sezione sono specifiche dell'hardware che costituisce l'ambiente. Quest'ultimo avrebbe potuto raggiungere la stessa velocità effettiva con un numero maggiore di server host Hyper-V meno potenti oppure con un numero minore di server host Hyper-V più potenti. Un incremento delle risorse hardware nel server di database non inciderebbe materialmente sui risultati.

Risultati, grafici e diagrammi

Nei grafici riportati di seguito l'asse x mostra la variazione nel numero dei server Web della farm. La scala (che rispecchia lo schema di implementazione della scalabilità) parte con un server Web virtuale e un server di database fisico (1x1). Il punto massimo è rappresentato da dieci server Web virtuali, un server virtuale dedicato alla cache distribuita (aggiunto a quattro server Web) e un server di database fisico (10x1x1).

Nota

I grafici di questa sezione rappresentano i valori medi per ogni punto dati per tutta la durata del test. In tutti i grafici sono inclusi come riferimento i valori relativi alle richieste al secondo (RPS) per l'area verde e l'area rossa per mostrare la relazione tra il valore RPS e fattori quali la latenza, l'utilizzo delle risorse dei server e l'utilizzo del disco di SQL Server.

1. Richieste al secondo (RPS)

Nel grafico riportato di seguito viene mostrato come l'implementazione della scalabilità orizzontale influisca sui valori RPS di riferimento.

This graph shows the RPS baseline for both Green and Red zones.

2. Latenza

Nel grafico riportato di seguito viene mostrato come l'implementazione della scalabilità orizzontale influisca sulla latenza. Si noti che la latenza nell'area verde rimane quasi costante, mentre nell'area rossa presenta moderate variazioni che rientrano nei limiti accettabili.

This graph shows the relationship between RPS and latency.

3. Utilizzo del processore e della memoria dei server Web

Nel grafico riportato di seguito viene mostrato come l'implementazione della scalabilità orizzontale influisca sull'utilizzo medio del processore e della memoria nei server Web. L'utilizzo del processore nell'area verde rimane praticamente costante man mano che le richieste al secondo aumentano, mentre l'utilizzo medio della memoria aumenta leggermente.

L'utilizzo del processore nell'area rossa ha una tendenza discendente e questo riflette il fatto che la richiesta media del processore del server Web al massimo carico si riduce gradualmente con l'aumento progressivo del numero di server.

This graph shows the relationship between RPS and utilization of web server processor and memory.

4. Operazioni di I/O al secondo (IOPs) e utilizzo del processore di SQL Server

Nel grafico riportato di seguito viene mostrato come variano i valori medi relativi alle operazioni di I/O al secondo su disco (sia totali che letture/scritture) e all'utilizzo del processore man mano che viene incrementato il numero dei server Web mediante l'implementazione della scalabilità orizzontale. Per misurare i valori relativi alle operazioni di I/O al secondo sono stati utilizzati i contatori delle prestazioni seguenti:

  • Disco fisico: Letture disco/sec

  • Disco fisico: Scritture disco/sec

Per i valori di ogni contatore nel corso del test viene calcolata la media, quindi le medie vengono sommate per produrre il numero di operazioni di I/O al secondo totali.

Nota

I dati relativi all'utilizzo della memoria di SQL Server non erano disponibili, pertanto non sono presenti in questo grafico.

Importante

Questi risultati del test relativo alle operazioni di I/O al secondo non sono rappresentativi di un ambiente di produzione perché il set di dati utilizzato in questo caso è molto più limitato di quello di una farm di produzione. È stato pertanto possibile memorizzare nella cache dei server Web una percentuale di dati superiore a quella memorizzabile in un ambiente di produzione. I risultati riguardanti le operazioni di I/O al secondo in questa sezione sono quindi medie calcolate basate sui dati di test disponibili e in via generale è prevedibile che siano inferiori alle operazioni di I/O al secondo eseguite in un ambiente di produzione. Un testing approfondito della propria farm in un ambiente pilota può produrre risultati diversi.

Si noti che nei grafici contenuti in questa azione sia le operazioni di I/O al secondo sia l'utilizzo del processore del server di database presentano una flessione con 9 e 10 server Web front-end, mentre il valore relativo alle richieste al secondo continua ad aumentare. Tale variazione si riflette anche sull'utilizzo del processore dei server Web, come illustrato nel grafico precedente.

Questo dimostra che il livello di scalabilità della farm ha raggiunto il punto di massima pressione sulle risorse dei server della farm utilizzando il carico e il set di dati di riferimento. Per far fronte al carico della farm, è necessario un minor utilizzo medio delle risorse dei server.

Da questa tendenza è possibile estrapolare quanto segue:

  • Se il carico del test fosse stato aumentato a livello del nono server Web nell'implementazione della scalabilità, sarebbe stato possibile raggiungere un numero di richieste al secondo più elevato mantenendo una curva piatta relativamente all'utilizzo delle risorse dei server.

  • Se il numero dei server Web fosse stato incrementato ulteriormente mantenendo lo stesso carico del test, il numero delle richieste al secondo avrebbe continuato ad aumentare mentre la pressione sulle risorse dei server avrebbe continuato ad avere una tendenza discendente.

  1. Operazioni di I/O al secondo totali di SQL Server

    Nel grafico riportato di seguito viene mostrato come l'implementazione della scalabilità orizzontale influisca sulle operazioni di I/O al secondo totali.

    This graph shows the relationship between RPS and SQL Server total IOPs.

  2. Operazioni di I/O al secondo di SQL Server suddivise tra operazioni di lettura e scrittura

    Nel grafico riportato di seguito viene mostrato come l'implementazione della scalabilità orizzontale influisca sulle operazioni di I/O al secondo, suddivise tra letture al secondo e scritture al secondo.

    This graph shows the relationship between RPS and SQL Server IOPs, broken down into read and write operations.

  3. Utilizzo del processore di SQL Server

    Nel grafico riportato di seguito viene mostrato come l'implementazione della scalabilità orizzontale influisca sull'utilizzo del processore di SQL Server.

    This graph shows the relationship between RPS and SQL Server processor utilization.

Confronto tra SharePoint Server 2013 e SharePoint Server 2010

In questa sezione vengono fornite informazioni su come le prestazioni per questo carico di lavoro diversificata tra SharePoint Server 2013 e SharePoint Server 2010.

Carico di lavoro

Per confrontare SharePoint Server 2013 con SharePoint Server 2010, viene utilizzata una combinazione di test diverso da quello descritto nella sezione specifiche . Questa era necessaria perché alcune funzionalità SharePoint Server 2013 (ad esempio, il servizio Cache distribuita) e operazioni non erano disponibili in SharePoint Server 2010.

Metodologia di test

Per verificare le prestazioni nei due ambienti, è stata utilizzata la metodologia di test seguente:

  1. È stato creato un ambiente SharePoint Server 2010.

  2. L'ambiente SharePoint Server 2010 è stato testato utilizzando il carico di lavoro descritto precedentemente in questa sezione.

  3. Sono stati aggiornati i database del contenuto a SharePoint Server 2013 senza cambiare i client che utilizzano l'ambiente.

In questo ambiente aggiornato è stato quindi testato nuovamente nei server aggiornati che ospitano SharePoint Server 2013 utilizzando la stessa combinazione di test, che include soltanto operazioni SharePoint Server 2010.

  • I due ambienti sono stati testati per essere messi a confronto. In un ambiente è stato utilizzato hardware per server fisici, mentre nell'altro sono state utilizzate macchine virtuali per eseguire i server Web in un host Hyper-V. In entrambi i casi il server di database è stato eseguito in un server fisico.

  • Non è stato modificato il set di dati dopo l'aggiornamento di database del contenuto per i test SharePoint Server 2013.

  • La combinazione di test per SharePoint Server 2010 esclusi nuovo SharePoint Server 2013-operazioni specifiche e aveva la soluzione di collaborazione intranet aziendale che è stata testata e descritta precedentemente in questo articolo.

L'obiettivo dei test di stato per applicare carichi simili rispetto farm sia SharePoint Server 2013 e SharePoint Server 2010 utilizzando lo stesso carico di lavoro e set di dati e visualizzare le differenze di consumo delle risorse di velocità effettiva, latenza e server. Obiettivi e le metodologie più test differenziavano tra i test di server fisici e virtuali web:

  • Per confrontare le modalità farm SharePoint Server 2013 e SharePoint Server 2010 relative alla scalabilità in presenza di carico è stato lo scopo di test del server fisico. I server web in questo test sono stati scalabilità orizzontale da due a cinque server web.

  • Lo scopo di test del server virtuale era per confrontare le modalità SharePoint Server 2013 e SharePoint Server 2010 farms con quattro server web eseguiti a carichi utente sia verde e area rossa. Nessun test di scalabilità orizzontale server web sono stato eseguito.

Analisi

  • In generale, SharePoint Server 2013 eseguita meglio SharePoint Server 2010 quando la scalabilità a cinque server web, ma i risultati SharePoint Server 2010 sono stati migliori in due server web. Test delle server farm aggiornata SharePoint Server 2013 non sono stati implicano l'utilizzo di post-aggiornamento ottimizzazioni o sfruttare SharePoint Server 2013 miglioramenti delle prestazioni, ad esempio il servizio Cache distribuita o gestione richieste. i risultati dei test SharePoint Server 2013, sono pertanto presenta differenze significative rispetto dei risultati in un ambiente reale.

  • La relazione tra le tendenze dei dati nei grafici in questa sezione mostra come il modello di gestione delle risorse SharePoint Server 2013 priorità che assegna l'utilizzo delle risorse del processore su disco al secondo previste.

  • Nell'area verde, SharePoint Server 2013 rispetto SharePoint Server 2010 a cinque server web, con più di 10% miglioramento delle richieste al secondo e latenza leggermente inferiore. Tuttavia, in due server web, SharePoint Server 2013 produce inferiore richieste al secondo e un piccolo miglioramento della latenza su SharePoint Server 2010.

  • Nell'area rossa, SharePoint Server 2013 raggiunge circa 12% maggiore velocità effettiva rispetto ai SharePoint Server 2010 a cinque server web. Due server web, la velocità effettiva del SharePoint Server 2010 era maggiore circa 30%. SharePoint Server 2013 hanno dimostrato un miglioramento moderato della latenza su SharePoint Server 2010 a cinque server web.

  • Test server web virtuali, sia SharePoint Server 2013 e SharePoint Server 2010 i risultati sono simili all'area verde. SharePoint Server 2013 Mostra miglioramento significativo su SharePoint Server 2010 in velocità effettiva e latenza in area rossa.

Risultati, grafici e diagrammi

I test che hanno prodotto i risultati riportati nei grafici di questa sezione sono stati eseguiti su server Web sia fisici che virtuali, come già indicato. In tutti i test è stato utilizzato un solo server di database fisico in cui era in esecuzione SQL Server 2008 R2 con SP1.

  1. Richieste al secondo e latenza

    Nel grafico seguente illustra la differenza di velocità effettiva e latenza tra SharePoint Server 2013 e SharePoint Server 2010 con due e cinque server fisici web all'area verde. SharePoint Server 2010 ha RPS superiore a due server web e della latenza superiore. A cinque server web, SharePoint Server 2013 Visualizza che entrambe maggiore RPS e latenza inferiore.

    This graph compares Green Zone RPS and latency between SharePoint Server 2013 and SharePoint Server 2010.

    Nel grafico seguente illustra la differenza di server web dell'utilizzo del processore con due e cinque server fisici web all'area rossa. SharePoint Server 2013 rispetto SharePoint Server 2010 in RPS e latenza 5 server web, ma non a due server web.

    This graph compares Red Zone RPS and latency between SharePoint Server 2013 and SharePoint Server 2010.

  2. Richieste al secondo e utilizzo delle risorse dei server

    Il grafico seguente illustra la differenza nel server web e database dell'utilizzo del processore con due e cinque server fisici web con carico area verde. Si noti che SharePoint Server 2013 raggiunge maggiore velocità effettiva a cinque server web da più efficiente trarre vantaggio delle risorse dei server disponibili.

    This graph compares Green Zone web server processor utilization between SharePoint Server 2013 and SharePoint Server 2010.

    Il grafico seguente illustra la differenza nel server web e database dell'utilizzo del processore con due e cinque server fisici web con carico area rossa. Nuovamente, SharePoint Server 2013 raggiunge maggiore velocità effettiva cinque server web, ma non a due server web.

    This graph compares Red Zone web server processor utilization between SharePoint Server 2013 and SharePoint Server 2010.

  3. Richieste al secondo e operazioni di I/O al secondo

    Nel grafico seguente illustra la differenza di IOPs con due e cinque server fisici web all'area verde. Si noti che in area verde, SharePoint Server 2013SharePoint Server 2016 IOPs aumenta tra due e cinque server web, mentre SharePoint Server 2010 IOPs diminuisce. Al contempo, la percentuale di aumento SharePoint Server 2013 RPS è significativamente maggiore di SharePoint Server 2010. Questa differenza tendenze viene illustrato come SharePoint Server 2013 gestisce le risorse di server in modo diverso in una farm di dimensioni maggiore per ottenere un maggiore velocità effettiva.

    This graph compares Green Zone IOPs between SharePoint Server 2013 and SharePoint Server 2010.

    Nel grafico seguente illustra la differenza di IOPs con due e cinque server fisici web con carico area rossa. Quando questi risultati verranno confrontati con grafico area rossa nella sezione Utilizzo delle risorse di server e RPS precedenti, è possibile osservare che il modello di gestione delle risorse SharePoint Server 2013 assegna una priorità l'utilizzo delle risorse del processore su SQL Server su disco al secondo previste.

    This graph compares Red Zone IOPs between SharePoint Server 2013 and SharePoint Server 2010.

  4. Richieste al secondo, latenza e operazioni di I/O al secondo dei server Web virtuali

    Il testing di confronto dei server virtuali è stato eseguito su quattro server Web virtuali e un server di database fisico.

    Nel grafico seguente illustra la differenza di velocità effettiva e latenza con quattro server web virtuale. Caricamento di area verde, sia SharePoint Server 2013 e SharePoint Server 2010 i risultati sono simili, mentre SharePoint Server 2013 illustrata miglioramento significativo su SharePoint Server 2010 in velocità effettiva e latenza in area rossa.

    This graph compares virtual server RPS and latency between SharePoint Server 2013 and SharePoint Server 2010.

    Nel grafico seguente illustra la differenza nel database di IOPs con quattro server web virtuale. SharePoint Server 2013 viene caricato un miglioramento significativo nel database delle prestazioni di IOPs sia verde e area rossa.

    This graph compares virtual server IOPs between SharePoint Server 2013 and SharePoint Server 2010.

See also

Pianificare le prestazioni di pianificazione in SharePoint Server 2013
Risultati dei testi delle prestazioni e della capacità e suggerimenti (SharePoint Server 2013)