Esecuzione dei test delle prestazioni di SharePoint Server 2013
SI APPLICA A:
2013 
2016 2019 Subscription Edition SharePoint in Microsoft 365
Questo articolo descrive come testare le prestazioni di SharePoint Server 2013. La fase di testing e ottimizzazione è un aspetto fondamentale di una gestione efficace della capacità. È consigliabile testare le nuove architetture prima di distribuirle nell'ambiente di produzione ed eseguire test di accettazione con le procedure consigliate di monitoraggio seguenti per garantire che le architetture progettate raggiungano gli obiettivi di prestazioni e capacità. In questo modo è possibile individuare e ottimizzare potenziali colli di bottiglia prima che creino problemi per gli utenti in una distribuzione attiva. Se si esegue l'aggiornamento da un ambiente di Office SharePoint Server 2007 e si prevede di apportare modifiche all'architettura o si stima il carico utente delle nuove funzionalità di SharePoint Server 2013, il test è importante per assicurarsi che il nuovo ambiente basato su SharePoint Server 2013 soddisfi gli obiettivi di prestazioni e capacità.
Dopo aver testato l'ambiente, è possibile analizzare i risultati del test per determinare quali modifiche devono essere apportate per raggiungere gli obiettivi di prestazioni e capacità stabiliti nel passaggio 1: Modello di pianificazione della capacità per SharePoint Server 2013.
Ecco i passaggi secondari consigliati da seguire per la preproduzione:
Creare l'ambiente di testing in modo da simulare l'architettura iniziale progettata nel passaggio 2 relativo alla progettazione.
Inserire nello spazio di archiviazione il set di dati o parte di esso secondo quanto definito nel passaggio 1 relativo alla modellazione.
Sollecitare il sistema con un carico sintetico che rappresenti il carico di lavoro identificato nel passaggio 1 relativo alla modellazione.
Eseguire i test, analizzare i risultati e ottimizzare l'architettura.
Distribuire l'architettura ottimizzata nel data center e implementare una distribuzione pilota con un insieme ridotto di utenti.
Analizzare i risultati della distribuzione pilota, individuare i potenziali colli di bottiglia e ottimizzare l'architettura. Rieseguire i test, se necessario.
Effettuare la distribuzione nell'ambiente di produzione.
Prima di leggere questo articolo, è consigliabile leggere Panoramica della gestione della capacità e del ridimensionamento per SharePoint Server 2013.
Creare un piano di test
Verificare che nel piano sia previsto quanto segue:
Hardware progettato per funzionare secondo i requisiti di prestazioni di produzione previsti. Misurare sempre le prestazioni dei sistemi di testing arrotondando per prudenza.
Se si dispone di codice personalizzato o di un componente personalizzato, è importante testare prima le prestazioni di tali componenti in isolamento per convalidarne le prestazioni e la stabilità. Dopo che sono stabili, è necessario testare il sistema con i componenti installati e confrontare le prestazioni con la farm senza che siano installate. I componenti personalizzati spesso sono la causa principale dei problemi di prestazioni e affidabilità rilevati nei sistemi di produzione.
Conoscere l'obiettivo dei test. Comprendere in anticipo quali sono gli obiettivi di test. È per convalidare le prestazioni di alcuni nuovi componenti personalizzati sviluppati per la farm? È per vedere quanto tempo ci vorrà per eseguire la ricerca per indicizzazione e indicizzare un set di contenuto? È per determinare il numero di richieste al secondo che la farm può supportare? Durante un test possono essere presenti molti obiettivi diversi e il primo passaggio per lo sviluppo di un buon piano di test consiste nel decidere quali sono gli obiettivi.
Decidere come effettuare le misurazioni sulla base dell'obiettivo del testing. Se si è interessati a misurare la capacità di velocità effettiva della farm, ad esempio, è necessario misurare il RPS e la latenza della pagina. Se si misurano le prestazioni di ricerca, è necessario misurare il tempo di ricerca per indicizzazione e i tassi di indicizzazione dei documenti. Se l'obiettivo del testing è ben chiaro, sarà più facile definire quali indicatori di prestazioni chiave sia necessario verificare per effettuare i test.
Creare l'ambiente di testing
Dopo aver stabilito gli obiettivi di test, le misurazioni sono state definite e sono stati determinati i requisiti di capacità per la farm (dai passaggi 1 e 2 di questo processo), l'obiettivo successivo sarà progettare e creare l'ambiente di test. L'impegno per creare un ambiente di test viene spesso sottovalutato. Deve duplicare il più possibile l'ambiente di produzione. Alcune delle funzionalità e delle funzionalità da considerare durante la progettazione dell'ambiente di test includono:
Autenticazione: decidere se la farm userà Active Directory Domain Services (AD DS), l'autenticazione basata su moduli (e in tal caso con quale directory), l'autenticazione basata sulle attestazioni e così via. Indipendentemente dalla directory in uso, quanti utenti sono necessari nell'ambiente di test e come si intende crearli? Indipendentemente dalla directory utilizzata, è inoltre necessario stabilire quanti utenti devono essere presenti nell'ambiente di testing e con quali modalità crearli e quanti gruppi o ruoli sono richiesti e con quali modalità crearli e inserirvi i dati. È altresì necessario verificare che siano sufficienti le risorse allocate ai servizi di autenticazione, in modo che non diventino un collo di bottiglia durante il testing.
DNS: conoscere gli spazi dei nomi necessari durante il test. Identificare i server che risponderanno a tali richieste e assicurarsi di aver incluso un piano con gli indirizzi IP che verranno usati dai server e le voci DNS da creare.
Bilanciamento del carico: supponendo che si stia usando più di un server (che in genere si farebbe o probabilmente non si avrebbe abbastanza carico per garantire il test di carico), sarà necessario un qualche tipo di soluzione di bilanciamento del carico. Potrebbe trattarsi di un dispositivo di bilanciamento del carico hardware oppure è possibile usare il bilanciamento del carico software, ad esempio Bilanciamento carico di rete di Windows. Capire cosa si userà e annotare tutte le informazioni di configurazione necessarie per configurarla in modo rapido ed efficiente. Un'altra cosa da ricordare è che gli agenti di test di carico in genere provano a risolvere l'indirizzo in un URL solo una volta ogni 30 minuti. Ciò significa che non è consigliabile usare un file host locale o un DNS round robin per il bilanciamento del carico perché gli agenti di test probabilmente finiranno per passare allo stesso server per ogni singola richiesta, invece di bilanciare tutti i server disponibili.
Server di test: quando si pianifica l'ambiente di test, non è sufficiente pianificare solo i server per la farm di SharePoint Server 2013, è anche necessario pianificare i computer necessari per eseguire i test. In genere, che includerà almeno tre server; potrebbe essere necessario di più. Se si usa Visual Studio Team System (Agente di carico test team) per eseguire il test, verrà usato un computer come controller di test di carico. In genere sono disponibili due o più computer usati come agenti di test di carico. Gli agenti sono i computer che accettano le istruzioni del controller di test su cosa testare ed emettere le richieste alla farm di SharePoint Server 2013. I risultati dei test vengono archiviati in un computer basato su SQL Server. Non è consigliabile usare lo stesso computer basato su SQL Server usato per la farm di SharePoint Server 2016, perché la scrittura dei dati di test inclina le risorse di SQL Server disponibili per la farm di SharePoint Server 2013. È anche necessario monitorare i server di test durante l'esecuzione dei test, allo stesso modo in cui si monitorano i server nella farm di SharePoint Server 2013 o nei controller di dominio e così via, per assicurarsi che i risultati dei test siano rappresentativi della farm che si sta configurando. Anche il controller o gli agenti di carico a volte possono diventare il collo di bottiglia. In questo caso, la velocità effettiva viene visualizzata nel test in genere non è la farm massima supportata.
SQL Server: nell'ambiente di test seguire le indicazioni riportate nelle sezioni "Configurare SQL Server" e "Convalidare e monitorare l'archiviazione e le prestazioni di SQL Server" nell'articolo Pianificazione e configurazione della capacità di Archiviazione e SQL Server (SharePoint Server).
Convalida del set di dati: quando si decide il contenuto su cui eseguire i test, tenere presente che nello scenario migliore si useranno i dati di un sistema di produzione esistente. È ad esempio possibile eseguire il backup dei propri database del contenuto da una farm di produzione e ripristinarli nell'ambiente di testing, quindi collegare i database per inserire il contenuto nella farm. Ogni volta che si eseguono test su dati preparati o di esempio, si corre il rischio che i risultati non siano attendibili a causa delle differenze nella composizione e nella combinazione dei tipi di contenuto.
Se è necessario creare dati di esempio, per preparare tale contenuto, considerare quanto segue:
Tutte le pagine devono essere pubblicate e nessun elemento deve essere estratto.
La struttura di spostamento dovrebbe essere realistica, attenendosi a quanto ragionevolmente avviene nell'ambiente di produzione.
Immaginare quali personalizzazioni verranno utilizzate nel sito di produzione. Ad esempio, le pagine master, i fogli di stile, il codice JavaScript e così via dovrebbero essere tutti implementati nell'ambiente di testing con modalità il più possibile analoghe a quelle dell'ambiente di produzione.
Determinare quanti gruppi e/o livelli di autorizzazione di SharePoint sono necessari e come associare gli utenti.
Pensare se sarà necessario eseguire importazioni dei profili e quale sarà la durata di tali operazioni.
Determinare se saranno necessari gruppi di destinatari, con le relative modalità di creazione e inserimento dei dati.
Determinare se sono necessarie altre origini di contenuto di ricerca e cosa è necessario creare. Se non è necessario crearle, vedere se si dispone dell'accesso in rete per potervi eseguire la ricerca per indicizzazione.
Determinare se sono disponibili dati di esempio sufficienti: documenti, elenchi, voci di elenco e così via. In caso contrario, creare un piano per la creazione di questo contenuto.
Predisporre un piano per avere sufficiente contenuto specifico per testare adeguatamente la funzionalità di ricerca. Un errore comune consiste nel caricare lo stesso documento, magari centinaia o migliaia di volte, in raccolte documenti diverse con nomi diversi. Ciò può incidere negativamente sulle prestazioni durante la ricerca perché il sistema di elaborazione delle query dovrà impiegare un certo tempo per eseguire un doppio rilevamento che altrimenti non sarebbe necessario in un ambiente di produzione con contenuto reale.
Creare test e strumenti
Dopo il funzionamento dell'ambiente di test, è necessario creare e ottimizzare i test che verranno usati per misurare la capacità delle prestazioni della farm. In questa sezione di tanto in tanto verrà fatto specificamente riferimento a Visual Studio Team System (Team Test Load Agent), ma molti dei concetti illustrati sono applicabili a qualsiasi strumento utilizzato per il test di carico. Per altre informazioni sugli strumenti di test disponibili per Azure DevOps (in precedenza VSTS), vedere Panoramica degli strumenti DevOps per Azure DevOps.
È anche possibile usare SharePoint Load Test Kit (LTK) con VSTS per il test di carico delle farm di SharePoint 2010. Load Test Kit genera un test di carico di Visual Studio Team System 2008 basato sui log DI IIS di Windows SharePoint Services 3.0 e Microsoft Office SharePoint Server 2007. Il test di carico VSTS può essere usato per generare carico sintetico su SharePoint Foundation 2010 o SharePoint Server 2010 come parte di un esercizio di pianificazione della capacità o di un test di stress pre-aggiornamento.
Load Test Kit è incluso in Microsoft SharePoint 2010 Administration Toolkit v2.0, disponibile nell'Area download Microsoft.
Un criterio chiave per il successo dei test consiste nel poter simulare in modo efficace un carico di lavoro realistico generando richieste in un'ampia gamma di dati del sito di test, così come gli utenti accederebbero a un'ampia gamma di contenuti in una farm di SharePoint Server 2013 di produzione. A tale scopo, è in genere necessario costruire i test in modo che siano basati sui dati. Invece di creare centinaia di singoli test specificati a livello di codice (hard-coded) per accedere a una determinata pagina, è consigliabile utilizzare solo pochi test che si avvalgono di origini dati contenenti gli URL per tali elementi per un accesso dinamico a quel set di pagine.
In Visual Studio Team System (Agente di carico test team) un'origine dati può essere disponibile in diversi formati, ma un formato di file CSV è spesso più semplice da gestire e trasportare tra ambienti di sviluppo e test. Tenere presente che la creazione di file CSV con tale contenuto potrebbe richiedere la creazione di strumenti personalizzati per enumerare l'ambiente basato su SharePoint Server 2013 e registrare i vari URL usati.
Potrebbe essere necessario utilizzare strumenti per le attività seguenti:
Creazione di utenti e gruppi in Active Directory o in un altro archivio di autenticazione se viene utilizzata l'autenticazione basata su moduli.
Enumerazione degli URL di siti, elenchi e raccolte, elementi di elenchi, documenti e così via e relativo inserimento in file CSV per i test di carico.
Caricamento di documenti di esempio in una serie di raccolte documenti e siti diversi.
Creazione di raccolte siti, siti Web, elenchi, raccolte, cartelle ed elementi di elenchi.
Creazione di siti personali.
Creazione di file CSV con nomi utente e password per gli utenti di test; questi sono gli account utente con cui verranno eseguiti i test di carico. Devono essere presenti più file in modo che, ad esempio, alcuni contengano solo utenti amministratori, altri con privilegi elevati (ad esempio autore/collaboratore, responsabile gerarchia e così via) e altri siano solo lettori e così via.
Creazione di un elenco di parole chiave e frasi di esempio per la ricerca.
Popolamento di gruppi e livelli di autorizzazione di SharePoint con utenti e gruppi di Active Directory (o ruoli se si usa l'autenticazione basata su moduli)
Quando si creano i test Web, è necessario osservare e implementare altre procedure consigliate. che includono:
Registrare semplici test Web come punto di partenza. Tali test avranno valori hardcoded per parametri come URL, ID e così via. Sostituire questi valori hardcoded con i collegamenti dai file CSV. Il data binding di tali valori in Visual Studio Team System (agente di carico di team test) è semplice.
Disporre sempre di regole di convalida per il test. Ad esempio, quando si richiede una pagina, se si verifica un errore si ottiene spesso la pagina error.aspx in risposta. Dal punto di vista di un test Web, viene visualizzata come un'altra risposta positiva, perché si ottiene un codice di stato HTTP 200 (esito positivo) nei risultati del test di carico. Si tratta invece ovviamente di un errore che deve essere registrato in modo diverso. Creando una o più regole di convalida, è possibile intercettare l'invio di un determinato testo come risposta, in modo che la convalida abbia esito negativo e la richiesta venga contrassegnata come errore. Ad esempio, in Visual Studio Team System (Agente di carico test team) una semplice regola di convalida potrebbe essere una convalida ResponseUrl. Registra un errore se la pagina di cui viene eseguito il rendering dopo i reindirizzamenti non è la stessa pagina di risposta registrata nel test. È anche possibile aggiungere una regola FindText che registra un errore se trova la parola "accesso negato", ad esempio, nella risposta.
Utilizzare più utenti in diversi ruoli per i test. Alcuni comportamenti, come la memorizzazione nella cache di output, variano a seconda dei diritti dell'utente corrente. Ad esempio, un amministratore della raccolta siti o un utente autenticato con diritti di approvazione o creazione non ottiene risultati memorizzati nella cache perché si vuole sempre che visualizzino la versione più recente del contenuto. Gli utenti anonimi invece potranno ottenere il contenuto memorizzato nella cache. È pertanto necessario assicurarsi che gli utenti di test costituiscano una combinazione di tali ruoli molto simile a quella degli utenti dell'ambiente di produzione. Ad esempio, nell'ambiente di produzione sono probabilmente presenti solo due o tre amministratori della raccolta siti, quindi non è consigliabile creare test in cui il 10% delle richieste di pagina vengono effettuate da account utente che sono amministratori della raccolta siti sul contenuto del test.
L'analisi delle richieste dipendenti è un attributo di un Visual Studio Team System (Team Test Load Agent) che determina se l'agente del test deve tentare di recuperare solo la pagina oppure la pagina e tutte le richieste associate che fanno parte di essa, ad esempio immagini, fogli di stile, script e così via. Durante il test di carico in genere questi elementi vengono ignorati per diversi motivi:
Dopo che un utente accede a un sito per la prima volta, questi elementi vengono spesso memorizzati nella cache dal browser locale.
Questi elementi non provengono in genere da SQL Server in un ambiente basato su SharePoint Server 2013. Con la memorizzazione nella cache BLOB attivata, vengono invece gestiti dai server Web in modo che non generino il carico di SQL Server.
Se regolarmente si rileva un'elevata percentuale di utenti che per la prima volta accedono al sito, se la memorizzazione nella cache da parte del browser è stata disattivata oppure se per un motivo qualsiasi non si intende utilizzare la cache BLOB, può essere utile abilitare l'analisi delle richieste dipendenti nei test. Questa è tuttavia un'eccezione per la maggior parte delle implementazioni. Tenere presente che, attivando tale funzionalità, possono aumentare in modo significativo i valori RPS segnalati dal controller del test. Queste richieste vengono servite così rapidamente che potrebbe ingannare l'utente a pensare che c'è più capacità disponibile nella farm di quanto non ci sia effettivamente.
Ricordarsi di modellare anche l'attività dell'applicazione client. Le applicazioni client, ad esempio Microsoft Word, PowerPoint, Excel e Outlook, generano richieste anche alle farm di SharePoint Server 2013. Aggiungono il carico all'ambiente inviando le richieste del server, ad esempio il recupero di feed RSS, l'acquisizione di informazioni di social networking, la richiesta di dettagli sulla struttura del sito e dell'elenco, la sincronizzazione dei dati e così via. Questi tipi di richieste devono essere inclusi e modellati se tali client sono presenti nell'implementazione.
Nella maggior parte dei casi un test Web deve contenere solo un'unica richiesta. In questo modo, è più facile eseguire l'ottimizzazione e la risoluzione dei problemi per il test harness e le singole richieste. I test Web dovranno in genere contenere più richieste se l'operazione simulata è composta da più richieste. Ad esempio, per testare questo set di azioni è necessario un test con più passaggi: estrazione di un documento, modifica, archiviazione e pubblicazione. È anche necessario riservare lo stato tra i passaggi, ad esempio per estrarre, apportare le modifiche e archiviarlo di nuovo, ad esempio lo stesso account utente. Queste operazioni in più passaggi che richiedono il mantenimento dello stesso stato da un passaggio all'altro vengono gestite in modo ottimale con più richieste in un singolo test Web.
Verificare ogni test Web singolarmente. Controllare che possa essere completato correttamente prima di eseguirlo in un test di carico di portata più ampia. Accertarsi che tutti i nomi delle applicazioni Web vengano risolti e che gli account utente utilizzati nel test dispongano di diritti sufficienti per eseguirlo.
I test Web comprendono le richieste per singole pagine, il caricamento di documenti, la visualizzazione di voci di elenco e così via. Tutti questi elementi vengono raggruppati in test di carico. Un test di carico è il percorso in cui si collegano tutti i diversi test Web che verranno eseguiti. A ogni test Web può essere assegnata una percentuale di tempo di esecuzione, ad esempio se si rileva che il 10% delle richieste in una farm di produzione è costituito da query di ricerca, nel test di carico è necessario configurare un test Web di query per l'esecuzione del 10% del tempo. In Visual Studio Team System (Agente di carico test team) i test di carico consentono anche di configurare elementi come la combinazione di browser, la combinazione di reti, i modelli di carico e le impostazioni di esecuzione.
Per i test di carico è inoltre preferibile seguire e implementare alcune procedure consigliate aggiuntive:
Utilizzare un rapporto di lettura/scrittura ragionevole nei test. L'utilizzo di un numero di operazioni di scrittura eccessivo rispetto al solito può incidere in modo significativo sulla velocità effettiva complessiva di un test. Persino nelle farm di collaborazione i rapporti di lettura/scrittura tendono a essere caratterizzati da un numero di operazioni di lettura superiore a quello delle operazioni di scrittura.
Considerare l'impatto di altre operazioni a elevato utilizzo di risorse e decidere se devono verificarsi durante il test di carico. Ad esempio, operazioni come il backup e il ripristino non vengono eseguite in genere durante un test di carico. Una ricerca per indicizzazione completa potrebbe non essere in genere eseguita durante un test di carico, mentre una ricerca per indicizzazione incrementale potrebbe essere normale. È necessario considerare il modo in cui tali attività verranno pianificate nell'ambiente di produzione, ovvero verranno eseguite nelle ore di caricamento di picco? In caso contrario, è probabile che vengano esclusi durante i test di carico, quando si tenta di determinare il carico massimo in stato stazionario che è possibile supportare per il traffico di picco.
Non usare i tempi di riflessione. I tempi di riflessione sono una funzionalità di Visual Studio Team System (Agente di carico test team) che consente di simulare il tempo in cui gli utenti si fermano tra i clic su una pagina. Ad esempio, un utente tipico potrebbe caricare una pagina, trascorrerne tre minuti a leggerla, quindi fare clic su un collegamento nella pagina per visitare un altro sito. Il tentativo di modellare questa operazione in un ambiente di test è quasi impossibile da eseguire correttamente e in effetti non aggiunge valore ai risultati del test. È difficile modellare perché la maggior parte delle organizzazioni non ha un modo per monitorare utenti diversi e il tempo trascorso tra i clic su diversi tipi di siti di SharePoint (come la pubblicazione e la ricerca rispetto alla collaborazione e così via). Inoltre, non aggiunge alcun valore perché, anche se un utente può sospendere tra le richieste di pagina, i server basati su SharePoint Server 2013 non lo fanno. Ottengono solo un flusso costante di richieste che possono avere picchi e valli nel tempo, ma non sono in attesa pigri mentre ogni utente si ferma tra un clic sui collegamenti in una pagina.
Comprendere la differenza tra utenti e richieste. Visual Studio Team System (Team Test Load Agent) presenta un modello di carico in cui è necessario specificare il numero di utenti da simulare. Questo non ha nulla a che fare con gli utenti dell'applicazione, è solo il numero di thread che verranno usati negli agenti di test di carico per generare richieste. Un errore comune è pensare che se la distribuzione avrà 5.000 utenti, ad esempio, 5.000 è il numero che deve essere usato in Visual Studio Team System (agente di carico di team test) - non lo è! Questa è una delle tante ragioni per cui, durante la stima dei requisiti di pianificazione della capacità, i requisiti di utilizzo dovrebbero basarsi sul numero di richieste al secondo e non sul numero di utenti. In un test di carico di Visual Studio Team System (Team Test Load Agent) è possibile generare spesso centinaia di richieste al secondo usando solo 50-75 "utenti" di test di carico.
Utilizzare un modello di carico costante per ottenere dai test risultati più attendibili e riproducibili. In Visual Studio Team System (Team Test Load Agent) è possibile basare il carico su un numero costante di utenti (thread, come illustrato nel punto precedente), un modello di carico aumentato degli utenti o un test di utilizzo basato su obiettivi. Nel caso di un modello di carico con aumento graduale, si inizia con un numero di utenti più basso e quindi si procede aggiungendo ulteriori utenti a intervalli di pochi minuti. Nel caso di un test di utilizzo basato sugli obiettivi, si stabilisce una soglia per un determinato contatore di diagnostica, ad esempio l'utilizzo della CPU, e il test tenta di controllare il carico in modo da mantenere tale contatore tra una soglia minima e una soglia massima definite a tale scopo. Tuttavia, se si sta solo cercando di determinare la velocità effettiva massima che la farm di SharePoint Server 2013 può sostenere durante il carico di picco, è più efficace e accurato scegliere semplicemente un modello di carico costante. In questo modo, è possibile identificare più agevolmente la quantità di carico che il sistema può accettare prima di cominciare a superare con regolarità le soglie da rispettare in una farm in buone condizioni di integrità.
Ogni volta che si esegue un test di carico, tenere presente che i dati cambiano nel database. Indipendentemente dal fatto che vengano caricati documenti, modificati elementi di un elenco o solo registrata l'attività nel database del servizio di utilizzo, in SQL Server verranno comunque scritti dei dati. Per avere un set di risultati coerente e attendibile da ogni test di carico, è consigliabile procurarsi un backup prima di eseguire il primo test di carico. Al termine di ogni test di carico, il backup deve essere usato per ripristinare il contenuto nel modo in cui era stato eseguito prima dell'avvio del test.
Vedere anche
Concetti
Pianificazione della capacità per SharePoint Server 2013
Monitoraggio e manutenzione di SharePoint Server 2013
Limiti software statici e configurabili per SharePoint Server 2016
Ulteriori risorse
Capacity management and sizing overview for SharePoint Server 2013