Esecuzione dei test delle prestazioni di SharePoint Server 2013

Articolo
03/21/2018

**Si applica a:**SharePoint Server 2013 Enterprise, SharePoint Server 2013 Standard

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

**Riepilogo:**informazioni su come pianificare ed eseguire i test delle prestazioni di un ambiente SharePoint Server 2013.

In questo articolo viene descritto come testare le prestazioni di SharePoint Server 2013. La fase di test e ottimizzazione è essenziale di gestione efficace della capacità. È consigliabile testare nuove architetture prima di distribuirli a quello di produzione ed è consigliabile condurre accettazione test in combinazione con monitoraggio procedure consigliate seguenti per garantire le architetture di di che conformità raggiungere gli obiettivi di prestazioni e capacità. Ciò consente di identificare e ottimizzare possibili colli di bottiglia prima che influiscano sugli utenti in una distribuzione di live. Se esegue l'aggiornamento da un ambiente Office SharePoint Server 2007 e si intende apportare modifiche all'architettura o sono stima utente delle nuove funzionalità SharePoint Server 2013, quindi il test di carico particolarmente importante per verificare che il nuovo SharePoint Server 2013-ambiente basato sul grado di soddisfare gli obiettivi di prestazioni e capacità.

Dopo avere testato l'ambiente, è possibile analizzare i risultati dei test per determinare le modifiche che devono essere apportate per raggiungere gli obiettivi di prestazioni e capacità definiti nel Step 1: Model in Pianificazione della capacità per SharePoint Server 2013.

Per la fase di pre-produzione è consigliabile eseguire i passaggi secondari seguenti:

Creare l'ambiente di testing in modo da simulare l'architettura iniziale progettata nel Step 2: Design.
Inserire nello spazio di archiviazione il set di dati o parte di esso secondo quanto definito nel Step 1: Model.
Sollecitare il sistema con un carico sintetico che rappresenti il carico di lavoro identificato nel Step 1: Model.
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 del dimensionamento e della gestione della capacità per SharePoint Server 2013.

Contenuto dell'articolo:

Creare un piano di test
Creare l'ambiente di testing
Creare test e strumenti

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 le prestazioni di tali componenti innanzitutto in isolamento per verificarne le prestazioni e la stabilità iniziali. Quando sono stabili, è opportuno testare il sistema con questi componenti installati e confrontare le prestazioni con quelle della farm prima che venissero installati. I componenti personalizzati spesso sono la causa principale dei problemi di prestazioni e affidabilità rilevati nei sistemi di produzione.
Conoscere lo scopo del testing, ovvero sapere in anticipo quali sono gli obiettivi da realizzare. I test devono verificare le prestazioni di alcuni nuovi componenti personalizzati sviluppati per la farm? Devono stabilire quanto tempo è necessario per eseguire la ricerca per indicizzazione e l'indicizzazione di un set di contenuti? Devono determinare quante richieste al secondo possono essere supportate dalla farm? Possono essere molti e molto diversi gli scopi di un test, pertanto decidere quali siano gli obiettivi da perseguire è il primo passaggio nella procedura di sviluppo di un buon piano di test.
Decidere come effettuare le misurazioni sulla base dell'obiettivo del testing. Se ad esempio si è interessati a misurare la capacità della farm in termini di velocità effettiva, sarà necessario misurare le richieste al secondo (valore RPS) e la latenza delle pagine. Se si desidera misurare le prestazioni della ricerca, sarà invece necessario misurare il tempo di ricerca per indicizzazione e la velocità 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 avere deciso gli obiettivi del testing, avere definito le misurazioni e avere stabilito i requisiti di capacità per la farm (dai passaggi 1 e 2 di questo processo), l'obiettivo successivo è quello di progettare e creare l'ambiente di testing. Lo sforzo necessario per creare questo tipo di ambiente spesso viene sottovalutato, mentre in realtà è necessario duplicare quanto più possibile l'ambiente di produzione. Di seguito sono riportate alcune delle caratteristiche e funzionalità da considerare durante la progettazione dell'ambiente di testing:

Autenticazione: decidere se nella farm verranno utilizzati Servizi di dominio Active Directory, l'autenticazione basata su moduli (e in case affermativo, con quale directory), l'autenticazione basata sulle attestazioni e così via. 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: stabilire quali spazi dei nomi saranno necessari nel corso del testing. Identificare i server che risponderanno a tali richieste e verificare di aver incluso un piano con gli indirizzi IP che verranno utilizzati dai diversi server e le voci DNS da creare.
Bilanciamento del carico: presupponendo che venga utilizzato più di un server (configurazione generalmente adottata, anche perché altrimenti il carico non sarebbe sufficiente a garantire il relativo test), sarà necessaria una soluzione di bilanciamento del carico, che si tratti di un dispositivo hardware o di un componente software come Bilanciamento carico di rete di Windows. Pensare a quali elementi verranno utilizzati e annotare tutte le informazioni di configurazione necessarie per effettuare un'impostazione rapida ed efficiente. Un altro aspetto da ricordare è che gli agenti del test di carico di solito tentano di risolvere l'indirizzo in un URL solo una volta ogni 30 minuti, pertanto non è consigliabile utilizzare un file hosts locale o DNS round robin per il bilanciamento del carico perché tali agenti finirebbero per contattare lo stesso server per ogni singola richiesta invece di distribuire il carico tra tutti i server disponibili.
Server di testing: quando si pianifica l'ambiente di testing, è necessario non solo la pianificazione per i server della farm SharePoint Server 2013, è inoltre necessario pianificare per le macchine virtuali necessarie per eseguire il test. In genere che includerà 3 server come minimo, Per ulteriori potrebbe essere necessario. Se si utilizza Visual Studio Team System (Team Test Load Agent) per effettuare i test, verrà utilizzato un computer come il controller di test di carico. Sono in genere 2 o più computer che vengono utilizzati come agenti di test di carico. Gli agenti sono i computer che utilizzano le istruzioni fornite dal controller di test su cosa testare e inviare le richieste nella farm SharePoint Server 2013. I risultati dei test se stessi sono archiviati in un computer basato su SQL Server. È consigliabile utilizzare il computer basato su SQL Server stesso utilizzato per la farm SharePoint Server 2016, non dal momento che la scrittura dei dati di test verrà skew, le risorse di SQL Server disponibili per la farm SharePoint Server 2013. È inoltre necessario monitorare i server di prova durante l'esecuzione dei test, allo stesso modo come verrebbero monitoraggio dei server nella farm SharePoint Server 2013, o controller di dominio e così via per assicurarsi che i risultati dei test sono rappresentante della farm che si sta impostando. In alcuni casi il carico agenti o controller può diventare il collo di bottiglia se stessi. In tal caso quindi la velocità effettiva che viene visualizzato nel test in genere non è il massimo che grado di supportare la farm.
SQL Server: nell'ambiente di testing seguire le istruzioni riportate nelle sezioni sulla configurazione di SQL Server e la verifica e il monitoraggio dell'archiviazione e delle prestazioni di SQL Server dell'articolo Pianificazione e configurazione dell'archiviazione e della capacità di SQL Server (SharePoint Server).
Convalida del set di dati: mentre si decide quale contenuto sottoporre ai test, ricordare che in uno scenario ottimale i dati da utilizzare sono quelli provenienti da 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.
Stabilire quanti gruppi e/o livelli di autorizzazione di SharePoint saranno necessari e le modalità con cui associarvi 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.
Verificare se sono necessarie ulteriori origini contenuto per la ricerca e quali elementi sono necessari per crearle. Se non è necessario crearle, vedere se si dispone dell'accesso in rete per potervi eseguire la ricerca per indicizzazione.
Controllare se si dispone di dati di esempio sufficienti, tra cui documenti, elenchi o elementi di elenchi. In caso contrario, definire un piano per la creazione di tale contenuto.
Predisporre un piano per avere sufficiente contenuto specifico per testare adeguatamente la funzionalità di ricerca. Un errore che si commette comunemente è quello di caricare lo stesso documento, magari centinaia o persino 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 aver funziona l'ambiente di testing, è necessario creare e ottimizzare i test che verranno utilizzati per calcolare la capacità delle prestazioni della farm. In questa sezione verrà talvolta fanno riferimento in modo specifico a Visual Studio Team System (Team Test Load Agent), ma molti dei concetti sono applicabili indipendentemente dal quale strumento di test di carico è utilizzare. Per ulteriori informazioni su Visual Studio Team System, vedere Visual Studio Team System MSDN (https://msdn.microsoft.com/en-us/library/fda2bad5.aspx").

Per eseguire il test di carico per le farm di SharePoint 2010, oltre a VSTS, è possibile utilizzare SharePoint Load Test Kit (LTK), che genera un test di carico di Visual Studio Team System 2008 basato sui registri IIS di Windows SharePoint Services 3.0 e Microsoft Office SharePoint Server 2007. Il test di carico di VSTS può essere utilizzato per generare un carico sintetico su SharePoint Foundation 2010 o SharePoint Server 2010 durante un esercizio di pianificazione della capacità o un test di stress pre-aggiornamento.

Load Test Kit è incluso in Microsoft SharePoint 2010 Administration Toolkit v1.0, disponibile nell'Area download Microsoft (https://www.microsoft.com/downloads/details.aspx?FamilyId=718447d8-0814-427a-81c3-c9c3d84c456e\&displaylang=en).

Un criterio chiave all'efficacia dei test deve essere in grado di in modo efficace simulare un carico di lavoro realistico mediante la generazione di richieste su una vasta gamma di dati del sito di test, così come utenti accedono un'ampia gamma di contenuto in una farm di produzione SharePoint Server 2013. Per ottenere questo risultato, è necessario in genere creare i test in modo che sono basati sui dati. Anziché creare centinaia di singoli test che sono hardcoded per accedere a una pagina specifica, è consigliabile utilizzare un numero limitato test che utilizzano origini dati che contiene gli URL per gli elementi accedere in modo dinamico quell'insieme di pagine.

In Visual Studio Team System (Team Test Load Agent), un'origine dati può essere diversi formati, ma un formato di file CSV rappresenta in genere più semplice gestire e tra gli ambienti di sviluppo e testing di trasporto. Tenere presente che creazione di file CSV con tale contenuto potrebbero richiedere la creazione degli strumenti personalizzati per enumerare SharePoint Server 2013-basati su ambiente e record i diversi URL in uso.

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. Si tratta degli account utente che verranno utilizzati per eseguire i test di carico. Vi dovrebbero essere più file, in modo che ad esempio alcuni contengano solo utenti amministratori, alcuni contengano altri utenti con privilegi elevati (autore/collaboratore, responsabile della gerarchia e così via) e altri ancora siano solo lettori.
Creazione di un elenco di parole chiave e frasi di esempio per la ricerca.
Inserimento degli utenti e dei gruppi di Active Directory (o dei ruoli se viene utilizzata l'autenticazione basata su moduli) nei gruppi e nei livelli di autorizzazione di SharePoint.

Quando si creano i test Web, vi sono altre procedure consigliate che è opportuno seguire e implementare, ovvero:

Registrare test Web semplici come punto di partenza. Tali test avranno valori specificati a livello di codice (hard-coded) per i parametri come URL, ID e così via. Sostituire questi valori con collegamenti dai file CSV. L'associazione dati per questi valori in Visual Studio Team System (Team Test Load Agent) è estremamente facile.
Disporre sempre di regole di convalida per il test. Quando ad esempio si richiede una pagina, se si verifica un errore, spesso si riceve la pagina error.aspx come risposta. Dal punto di vista di un test Web, questa situazione appare come un'altra risposta positiva perché si ottiene un codice di stato HTTP 200 (operazione eseguita correttamente) 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. In Visual Studio Team System (Team Test Load Agent) ad esempio una semplice regola di convalida potrebbe essere una convalida ResponseUrl che registra un errore se la pagina di cui viene eseguito il rendering dopo i reindirizzamenti non è la stessa pagina di risposta registrata nel test. Si potrebbe inoltre aggiungere una regola FindText che registra un errore se trova le parole "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. L'amministratore di una raccolta siti o un utente autenticato con diritti di approvazione o di creazione e modifica ad esempio non potrà ottenere i risultati memorizzati nella cache perché è sempre opportuno che visualizzi la versione più aggiornata 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. In tale ambiente ad esempio è probabile che vi siano solo due o tre amministratori di raccolte siti, pertanto non creare test in cui il 10% delle richieste di pagine venga effettuato da account utente che corrispondono ad amministratori di raccolte siti per il 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 in genere non provengono da SQL Server in un SharePoint Server 2013-ambiente basato su. Con la cache BLOB di attivata, sono invece resi disponibili per i server Web in modo che non generano carico su 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. Tali richieste vengono gestite così rapidamente da indurre erroneamente a credere che nella farm sia disponibile una capacità superiore a quella effettiva.

Ricordarsi di attività applicazioni client di modello anche. Applicazioni client, ad esempio Microsoft Word, PowerPoint, Excel e Outlook generano le richieste in anche farm SharePoint Server 2013. Aggiungono carico nell'ambiente mediante l'invio di richieste del server, ad esempio il recupero dei feed RSS, acquisire informazioni di social networking, che richiede informazioni dettagliate sulla struttura del sito e di elenco, la sincronizzazione dei dati e così via. Questi tipi di richieste devono essere incluso e modellati se si dispone di tali client 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 in genere devono contenere più richieste se il funzionamento da simulare prevede più richieste. Ad esempio, per testare questa serie di azioni, sarà necessario un test con più passaggi, ovvero l'estrazione di un documento, la modifica di quest'ultimo, l'archiviazione dello stesso e infine la pubblicazione. Sarà inoltre necessario mantenere lo stato tra i passaggi, ad esempio dovrà essere utilizzato lo stesso account utente per l'estrazione, l'esecuzione delle modifiche e l'archiviazione. 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.

Nei test Web sono incluse le richieste per le singole pagine, il caricamento dei documenti, la visualizzazione degli elementi degli elenchi e così via. Tutti questi test Web da eseguire vengono raggruppati nei test di carico. A ogni test Web è possibile assegnare una percentuale di tempo per l'esecuzione. Se ad esempio si riscontra che il 10% delle richieste in una farm di produzione è costituito da query di ricerca, nel test di carico è opportuno configurare un 10% del tempo per l'esecuzione di un test Web per le query. In Visual Studio Team System (Team Test Load Agent) i test di carico consentono inoltre di verificare come configurare aspetti quali la combinazione dei browser e delle 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 avere luogo durante il test di carico. Operazioni quali il backup e il ripristino ad esempio generalmente non vengono eseguite in un test di questo tipo, così come una ricerca per indicizzazione completa, mentre è normale effettuare una ricerca per indicizzazione incrementale. È necessario pensare a come tali attività saranno pianificate nell'ambiente di produzione, ad esempio se verranno eseguite nei momenti di carico maggiore. In caso contrario, dovrebbero probabilmente essere escluse nel corso del test di carico, quando si tenta di stabilire il massimo carico con stato stabile che può essere supportato in condizioni di traffico di picco.
Non utilizzare il tempo interazione utente. Il tempo interazione utente è una funzionalità di Visual Studio Team System (Team Test Load Agent) che consentono di simulare al momento in cui gli utenti le pause tra fa clic su una pagina. Ad esempio un utente tipico può caricare una pagina, tre minuti leggerli, quindi fare clic sul collegamento nella pagina a un altro sito. Tentativo di questo modello in un ambiente di testing è quasi impossibile da eseguire in modo corretto, in modo efficace non aggiunge valore ai risultati del test. È difficile modello perché la maggior parte delle organizzazioni non dispongono di un modo per monitorare utenti diversi e il tempo dedicato tra fa clic sui diversi tipi di siti di SharePoint (ad esempio pubblicazione rispetto alla ricerca e la collaborazione, ecc.). Inoltre non realmente aggiunta valore poiché anche se un utente può venire interrotto tra le richieste di pagina, SharePoint Server 2013-non basato su server. Vedono solo un flusso di richieste che possono avere picchi e minimi nel tempo continuo, ma non è in attesa scritte come ogni utente pause tra facendo 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. Tale aspetto non ha niente a che vedere con gli utenti delle applicazioni e corrisponde sostanzialmente al numero di thread che verranno utilizzati negli agenti del test di carico per generare le richieste. Un errore comune è quello di pensare che, per una distribuzione che ad esempio disporrà di 5.000 utenti, il numero da utilizzare in Visual Studio Team System (Team Test Load Agent) sia 5.000, ma tale ragionamento è errato. 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) si scoprirà che è spesso possibile generare centinaia di richieste al secondo utilizzando solo tra il 50% e il 75% degli "utenti" del test di carico.
Utilizzare un modello di carico costante per i risultati dei test più affidabile e riproducibili. In Visual Studio Team System (Team Test Load Agent) è necessario l'opzione di adeguati Carica su un costante numero di utenti (thread, come indicato nel punto precedente), un graduali backup modello di carico di utenti o basato su un obiettivo test di utilizzo. Un modello di carico graduali è quando si inizia con un numero inferiore di utenti e quindi "affrontare" aggiunta di altri utenti alcuni minuti. Un test di utilizzo basato su obiettivo è quando si stabilisce una soglia relativa a un determinato contatore diagnostica, ad esempio dell'utilizzo della CPU, e tenta di unità del carico per mantenere tale contatore tra una soglia minima e massima definita per il test. Tuttavia, se si sta tentando solo determinare la velocità effettiva massima che della farm SharePoint Server 2013 in grado di sostenere nelle ore di punta, è più efficace e accurato per solo selezionare un modello di carico costante. Che consente di determinare più facilmente la quantità di carico il sistema può eseguire prima di iniziare a superano regolarmente le soglie che devono essere mantenute in una farm integra.

Ogni volta che si esegue un test di carico, ricordare che i dati presenti nel database vengono modificati. 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. Dopo il completamento di ciascun test di carico, utilizzare il backup per ripristinare il contenuto nello stato in cui era prima dell'avvio del test.

Esecuzione dei test delle prestazioni di SharePoint Server 2013

Creare un piano di test

Creare l'ambiente di testing

Creare test e strumenti

See also

Risorse aggiuntive