Esecuzione dei test delle prestazioni di SharePoint Server 2010

Articolo
03/05/2017

Si applica a: SharePoint Server 2010

Ultima modifica dell'argomento: 2016-11-30

In questo articolo viene illustrato come testare le prestazioni di Microsoft SharePoint Server 2010. La fase di testing e ottimizzazione è un aspetto fondamentale di una gestione efficace della capacità. È consigliabile testare le nuove architetture prima di distribuirle in un ambiente di produzione, nonché eseguire test di accettazione insieme alle procedure consigliate di monitoraggio seguenti per accertarsi che le architetture progettate soddisfino i requisiti 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 Microsoft Office SharePoint Server 2007 e si prevede di apportare modifiche all'architettura o si desidera effettuare una valutazione del carico utente per le nuove funzionalità di SharePoint Server 2010, è particolarmente importante eseguire i test per verificare che il nuovo ambiente basato su SharePoint Server 2010 soddisfi i requisiti 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 Passaggio 1: modellare di Pianificazione della capacità per SharePoint Server 2010.

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 Passaggio 2: progettare.
Inserire nello spazio di archiviazione il set di dati o parte di esso secondo quanto definito nelPassaggio 1: modellare.
Sollecitare il sistema con un carico sintetico che rappresenti il carico di lavoro identificato nel Passaggio 1: modellare.
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, vedere Panoramica del dimensionamento e della gestione della capacità per SharePoint Server 2010.

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 il 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 sono necessari 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à necessario un meccanismo 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, oltre ai server per la farm di SharePoint Server 2010, si devono pianificare i computer necessari per eseguire i test. Come minimo generalmente sono previsti tre server, anche se ne potrebbero essere necessari di più. Se si utilizza Visual Studio Team System (Team Test Load Agent) per effettuare il testing, un computer funge da controller del test di carico. Invece sono in genere almeno due i computer utilizzati come agenti del test di carico. Gli agenti sono i computer che ricevono dal controller del test le istruzioni sui componenti da testare e che inviano le richieste alla farm di SharePoint Server 2010. I risultati dei test vengono archiviati in un computer basato su SQL Server. A tale scopo, non utilizzare lo stesso computer SQL Server utilizzato per la farm di SharePoint Server 2010 perché le operazioni di scrittura dei dati dei test incidono sulle risorse di SQL Server disponibili per la farm di SharePoint Server 2010. È inoltre necessario monitorare i server di testing durante l'esecuzione dei test come si effettuerebbe il monitoraggio dei server nella farm di SharePoint Server 2010 oppure i controller di dominio e così via per essere certi che i risultati siano rappresentativi della farm che si sta impostando. Anche il controller o gli agenti di carico a volte possono diventare il collo di bottiglia. In tal caso, la velocità effettiva riscontrata nel test solitamente non è quella massima supportata dalla 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 2010).
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 proprio 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 effettivamente 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 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.
Verificare se sono necessarie ulteriori origini di 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 che l'ambiente di testing è funzionante, è necessario creare e regolare i test da utilizzare per misurare la capacità della farm in termini di prestazioni. 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 ulteriori informazioni su Visual Studio Team System, vedere Visual Studio Team System su MSDN (https://msdn.microsoft.com/it-it/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 nei 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 (le informazioni potrebbero essere in lingua inglese) (https://www.microsoft.com/downloads/details.aspx?familyid=718447d8-0814-427a-81c3-c9c3d84c456e\&displaylang=it-it) (le informazioni potrebbero essere in lingua inglese).

Un criterio chiave per una corretta esecuzione dei test è la possibilità di simulare effettivamente un carico di lavoro realistico generando richieste per una vasta gamma di dati presenti nel sito di testing, proprio come gli utenti che accedono a una vasta gamma di contenuti in una farm di SharePoint Server 2010 di produzione. A tale scopo, in genere è necessario creare 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 perché tali elementi possano accedere dinamicamente a quel set di pagine.

In Visual Studio Team System (Team Test Load Agent) un'origine dati può essere disponibile in diversi formati, ma un file in formato CSV è spesso quello più semplice da gestire e trasportare tra l'ambiente di sviluppo e quello di testing. Tenere presente che, per creare file CSV con tale contenuto, potrebbe essere necessario creare strumenti personalizzati per enumerare l'ambiente basato su SharePoint Server 2010 e registrare i diversi URL utilizzati.

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 dei 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, responsabili 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) nei relativi 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 semplice.
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 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 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 dei test siano 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 a 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 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 ambiente basato su SharePoint Server 2010. Con la memorizzazione nella cache BLOB attivata, vengono invece gestiti dai server Web, pertanto non generano carico per SQL Server.

Se regolarmente si registra 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 attivare 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 inoltre di modellare l'attività delle applicazioni client. Anche tali applicazioni, tra cui Microsoft Word, PowerPoint, Excel e Outlook, generano infatti richieste per le farm di SharePoint Server 2010. Esse aggiungono carico all'interno dell'ambiente inviando al server richieste ad esempio per il recupero di feed RSS, l'acquisizione di informazioni di social networking, la richiesta di dettagli sulla struttura dei siti e degli elenchi o la sincronizzazione dei dati. Questi tipi di richieste dovrebbero essere inclusi e modellati se si dispone di tali client nella propria 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 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 lettura/scrittura tendono a essere caratterizzati da un numero di operazioni di lettura superiore a quello delle operazioni di scrittura. Per ulteriori informazioni, vedere Performance and capacity technical case studies (SharePoint Server 2010).
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 massimo. In caso contrario, possono 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 i tempi interazione utente, che sono una nuova funzionalità di Visual Studio Team System (Team Test Load Agent) che consente di simulare la pausa tra un clic e l'altro effettuati dagli utenti in una pagina. Un utente tipico ad esempio può caricare una pagina, passare tre minuti a leggerla e quindi fare clic su un collegamento presente nella pagina per visitare un altro sito. Tentare di modellare correttamente tale situazione in un ambiente di testing è quasi impossibile e oltretutto non aggiunge valore ai risultati dei test. La modellazione è difficoltosa perché la maggior parte delle organizzazioni non ha un meccanismo di monitoraggio dei diversi utenti e del tempo che impiegano tra un clic e l'altro in tipi diversi di siti di SharePoint (ad esempio di pubblicazione rispetto a quelli di collaborazione e così via). Non viene inoltre aggiunto realmente alcun valore perché, anche se un utente può fare una pausa tra una richiesta di pagina e l'altra, i server basati su SharePoint Server 2010 non si fermano. Ottengono semplicemente un flusso stabile di richieste con possibili punte massime e minime nel tempo, ma non restano in attesa inattivi mentre i singoli utenti sospendono le operazioni tra un clic e l'altro sui collegamenti all'interno di 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 specificare 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 essere basati 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 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, ovvero di thread come spiegato al punto precedente, un modello di carico con aumento graduale degli utenti o un test di utilizzo basato sugli 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. Se invece si tenta di stabilire la velocità effettiva massima che la farm di SharePoint Server 2010 può sostenere con un carico di picco, è più efficace e accurato selezionare solo 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, 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 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 ogni test di carico, utilizzare il backup per ripristinare il contenuto nello stato in cui era prima dell'avvio del test.

Condividi tramite

Esecuzione dei test delle prestazioni di SharePoint Server 2010

Creare un piano di test

Creare l'ambiente di testing

Creare test e strumenti

See Also

Concepts

Risorse aggiuntive