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.
Informazioni sulla pianificazione di prestazioni e capacità per SharePoint Server 2013
Limiti software statici e configurabili per SharePoint Server 2016
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:
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.
È stato aggiunto un server dedicato in cui viene eseguito il servizio cache distribuita.
È stato disabilitato il servizio cache distribuita nei server Web.
Sempre implementando la scalabilità orizzontale, il numero dei server Web è stato incrementato al massimo per l'ambito del testing.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
È stato creato un ambiente SharePoint Server 2010.
L'ambiente SharePoint Server 2010 è stato testato utilizzando il carico di lavoro descritto precedentemente in questa sezione.
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.
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.
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.
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.
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.
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.
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.
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.
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.
See also
Pianificare le prestazioni di pianificazione in SharePoint Server 2013
Risultati dei testi delle prestazioni e della capacità e suggerimenti (SharePoint Server 2013)