Considerazioni relative ai test di carico
In questo argomento vengono forniti suggerimenti per l'esecuzione di test di carico di grandi dimensioni in Visual Studio Ultimate. Verranno descritti i seguenti aspetti:
Scelta del modello di carico appropriato
Scelta del modello di connessione appropriato
Frequenza di campionamento e raccolta dati
Tempo interazione utente
Impostazione dei tempi di risposta obiettivo per le richieste test Web
Inclusione dei dettagli di intervallo per la raccolta di dati percentili
Impostazione della proprietà Percentuale di nuovi utenti
Abilitazione di Profiler ASP.NET
Abilitazione della registrazione dell'utente virtuale
Attivazione della traccia SQL
Mantenimento di un numero appropriato di computer agente
Scelta del modello di carico appropriato
Sono disponibili tre tipi di modello di carico: costante, per passaggio e basato su obiettivo. Per scegliere il modello di carico appropriato per il test di carico, è necessario comprendere i vantaggi di ogni tipo. Per ulteriori informazioni, vedere Modifica dei modelli di carico per modellare le attività utente virtuali.
Costante |
Un modello di carico costante risulta utile quando si desidera eseguire il test di carico con lo stesso carico utente per un periodo prolungato di tempo. Se si specifica un carico utente elevato con un modello di carico costante, si consiglia di specificare anche un tempo di riscaldamento per il test di carico. In questo modo, si evita di sottoporre il sito a uno stress eccessivo causato da centinaia di nuove sessioni utente che accedono contemporaneamente al sito. |
Passaggio |
Il modello di carico per passaggio è il più comune e utile tra quelli disponibili, in quanto consente di monitorare le prestazioni del sistema con l'aumento del carico utente. Monitorando il sistema via via che il carico utente aumenta, si può determinare il numero di utenti che è possibile supportare con tempi di risposta accettabili o, viceversa, il numero di utenti raggiunto il quale le prestazioni diventano inaccettabili. Se a ogni passaggio viene aggiunto un numero elevato di utenti, ad esempio più di 50, considerare l'opportunità di utilizzare la proprietà Tempo di preparazione passaggio per sfalsare l'avvio degli utenti nel passaggio. Per ulteriori informazioni, vedere Procedura: specificare la proprietà relativa al tempo di preparazione del passaggio per un modello di carico passaggio. |
Basato su obiettivo |
Il modello di carico basato su obiettivo è simile al modello per passaggio, in quanto il carico utente aumenta in genere nel corso del tempo, ma consente di specificare che il carico non deve più aumentare quando un contatore delle prestazioni raggiunge un determinato livello. È ad esempio possibile utilizzare un modello di carico basato su obiettivo per continuare ad aumentare il carico finché uno dei server di destinazione non viene occupato al 75% e quindi mantenerlo stabile. |
Se nessun modello di carico predefinito soddisfa le proprie esigenze, è anche possibile implementare un plug-in test di carico personalizzato che controlla il carico utente durante l'esecuzione del test di carico. Per ulteriori informazioni, vedere Creazione e utilizzo di plug-in personalizzati per i test di carico e delle prestazioni Web.
Scelta del modello di connessione del test delle prestazioni Web appropriato
Le impostazioni esecuzione test di carico supportano diverse opzioni per la modellazione delle connessioni utente al server Web tramite la proprietà Modello di connessione WebTest. Sono disponibili tre tipi di modello di connessione: connessione per utente, pool di connessioni e connessione per iterazione test. Per scegliere il modello di connessione appropriato per il test di carico, è necessario comprendere i vantaggi di ogni tipo.
Connessione per utente |
Il modello di connessione per utente simula con la massima approssimazione il comportamento di un vero browser. Ogni utente virtuale che esegue un test delle prestazioni Web utilizza fino a sei connessioni a ogni server Web. La connessione viene tenuta aperta per il server Web dedicato a tale utente virtuale. La prima connessione viene stabilita quando viene emessa la prima richiesta nel test Web. Le connessioni aggiuntive possono essere utilizzate quando una pagina contiene più di una richiesta dipendente. Tali richieste possono essere emesse in parallelo utilizzando le connessioni aggiuntive. I browser meno recenti utilizzano fino a due connessioni per server Web, mentre in FireFox 3 e Internet Explorer 8 vengono utilizzate fino a 6 connessioni per server Web. Queste stesse connessioni vengono riutilizzate per l'utente virtuale durante tutto il test di carico. Lo svantaggio di questo modello è che il numero di connessioni aperte nel computer agente può essere fino a sei volte superiore rispetto al carico utente, o addirittura maggiore se vengono utilizzati più server Web di destinazione, e le risorse richieste per supportare un numero così elevato di connessioni possono limitare il carico utente che può essere gestito da un singolo agente di test di carico. |
Pool di connessioni |
Il modello del pool di connessioni consente di conservare le risorse nell'agente del test di carico condividendo le connessioni al server Web tra più utenti del test Web virtuali. In questo modello la dimensione del pool specifica il numero massimo di connessioni da stabilire tra l'agente del test di carico e il server Web. Se il carico utente è maggiore delle dimensioni del pool di connessioni, la connessione sarà condivisa dai test Web eseguiti da utenti virtuali diversi. Si tratta del modello migliore da utilizzare per indirizzare la maggior parte del carico al livello applicazione. Questo significa che, quando la connessione è in uso in un altro test Web, potrebbe essere necessario un periodo di attesa prima che in un test Web venga emessa una richiesta. Il tempo medio di attesa per un test di prestazioni Web prima di inviare una richiesta viene registrato dal contatore delle prestazioni del test di carico Tempo medio di attesa connessione. Questo valore deve essere inferiore al tempo di risposta medio per una pagina. In caso contrario, la dimensione del pool di connessioni è probabilmente insufficiente. |
Connessione per iterazione test |
Connessione per iterazione test chiude la connessione dopo ogni iterazione di test e ne apre una nuova nell'iterazione successiva. Questa impostazione genera il maggior sovraccarico per gli accessi alla rete. Se non è un requisito, si consiglia di utilizzare una delle due opzioni precedenti. |
Frequenza di campionamento e raccolta dati
Scegliere una frequenza di campionamento appropriata in base alla durata del test di carico. Una frequenza di campionamento ridotta, ad esempio di cinque secondi, consente di raccogliere più dati per ogni contatore delle prestazioni rispetto a una frequenza più elevata. La raccolta di grandi quantità di dati per un periodo di tempo prolungato potrebbe generare errori di spazio su disco. Per i test di carico lunghi è possibile aumentare la frequenza di campionamento per ridurre la quantità di dati raccolti. Anche il numero di contatori delle prestazioni influisce sulla quantità di dati raccolti. Per i computer sottoposti a test, la riduzione del numero di contatori consente di ridurre la quantità di dati raccolti.
È necessario sperimentare varie soluzioni per determinare la frequenza di campionamento ottimale per uno specifico test di carico. Tuttavia, nella tabella seguente sono riportate le frequenze di campionamento consigliate che è possibile utilizzare per iniziare.
Durata test di carico |
Frequenza di campionamento consigliata |
|---|---|
< 1 ora |
5 secondi |
1 - 8 ore |
15 secondi |
8 - 24 ore |
30 secondi |
> 24 ore |
60 secondi |
Tempo interazione utente
Il tempo interazione utente per le richieste test Web ha un effetto significativo sul numero di utenti che possono essere supportati con tempi di risposta accettabili. Modificando il tempo interazione utente da 2 a 10 secondi è in genere possibile simulare un numero di utenti 5 volte maggiore. Tuttavia, se l'obiettivo è simulare gli utenti reali, è consigliabile impostare il tempo interazione utente in base al comportamento previsto di tali utenti sul sito Web. Aumentando il tempo interazione utente e il numero di utenti non si sottoporrà necessariamente il server Web a uno stress maggiore. Se il sito Web è autenticato, il tipo di schema utilizzato influirà sulle prestazioni.
Se si disabilita il tempo interazione utente per un test Web, potrebbe essere possibile generare un test di carico con una velocità effettiva superiore in termini di richieste al secondo. Se il tempo interazione utente è disabilitato, è necessario ridurre il numero di utenti rispetto a quando è attivato. Ad esempio, se si disabilita il tempo interazione utente e si tenta di gestire 1000 utenti, è probabile che il server di destinazione o l'agente del test di carico risulti sovraccaricato.
Per ulteriori informazioni, vedere Modifica dei tempi interazione utente per simulare i ritardi di interazione umana con i siti Web negli scenari di test di carico.
Impostazione dei tempi di risposta obiettivo per le richieste test Web
Una delle proprietà di una richiesta test Web è il tempo di risposta obiettivo. Se si definiscono tempi di risposta obiettivo per le richieste di test delle prestazioni Web, quando questo test viene eseguito in un test di carico, nell'analizzatore test di carico verrà segnalata la percentuale dei test delle prestazioni Web per cui il tempo di risposta non ha soddisfatto l'obiettivo. Per impostazione predefinita, per le richieste Web non sono definiti tempi di risposta obiettivo.
Se si utilizza inoltre la regola di convalida del tempo di risposta obiettivo, le pagine che non soddisfano tale obiettivo restituiranno un errore nel test di carico. Se si utilizza la funzionalità di registrazione in caso di errore, è possibile verificare le attività svolte dall'utente virtuale nel momento in cui è stata rilevata la pagina lenta.
Per ulteriori informazioni, vedere Procedura: impostare i tempi di risposta pagina ottimali in un test Web.
Inclusione dei dettagli dell'intervallo per raccogliere dati percentili e abilitare la visualizzazione dei dettagli
Le impostazioni di esecuzione includono una proprietà denominata Intervallo archiviazione dettagli. Se questa proprietà è abilitata, il tempo richiesto per eseguire ogni test, transazione e pagina durante il test di carico verrà archiviato nel repository dei risultati del test di carico. In questo modo verranno abilitati il Grafico attività utente virtuale e l'analizzatore test di carico. Ciò consente inoltre di visualizzare i dati del novantesimo, novantacinquesimo e novantanovesimo percentile e la deviazione standard nell'analizzatore test di carico nelle tabelle Test, Transazioni e Pagine.
Per impostazione predefinita, la proprietà Intervallo archiviazione dettagli è abilitata per supportare il Grafico attività utente virtuale nella visualizzazione Dettagli del risultato del test di carico, utilizzando l'analizzatore test di carico.
È consigliabile considerare la possibilità di disabilitare la proprietà Intervallo archiviazione dettagli per i test estesi, per due motivi principali.
La quantità di spazio richiesta nel repository dei risultati del test di carico per l'archiviazione dei dati di dettaglio dell'intervallo può essere molto elevata, soprattutto per i test di carico lunghi.
È necessario molto tempo per archiviare questi dati nel repository dei risultati alla fine del test di carico, in quanto tali dati vengono archiviati negli agenti del test di carico fino al termine dell'esecuzione del test di carico.
Se lo spazio disponibile su disco è sufficiente, è possibile attivare la proprietà Intervallo archiviazione dettagli per salvare i dati percentili nel repository dei risultati del test di carico. Per attivare la proprietà Intervallo archiviazione dettagli sono disponibili due opzioni: StatisticsOnly e AllIndividualDetails. Con entrambe le opzioni viene determinato l'intervallo di tutti i singoli test, pagine e transazioni e dai singoli dati di intervallo vengono calcolati i dati percentili. Se si sceglie StatisticsOnly, i singoli dati di intervallo vengono eliminati dal repository dopo il calcolo dei dati percentili. L'eliminazione dei dati riduce la quantità di spazio richiesta nel repository. Se tuttavia si desidera elaborare direttamente i dati dettaglio dell'intervallo utilizzando strumenti SQL oppure abilitare la visualizzazione dei dettagli dell'utente virtuale nel Grafico attività utente virtuale, scegliere AllIndividualDetails in modo da salvare tali dati nel repository.
Per ulteriori informazioni, vedere Analisi dell'attività utente virtuale del test di carico nella visualizzazione Dettagli dell'Analizzatore test di carico e Procedura: configurare i test di carico per raccogliere i dettagli completi per abilitare l'attività utente virtuale nei risultati del test.
Impostazione della proprietà Percentuale di nuovi utenti
Ogni scenario di un test di carico include una proprietà denominata Percentuale di nuovi utenti. Questa proprietà influisce sul modo in cui il motore di runtime del test di carico simula la memorizzazione nella cache che verrebbe eseguita da un browser. Il valore predefinito per Percentuale di nuovi utenti è 0. Ciò significa che ogni utente virtuale gestisce una cache virtuale di richieste dipendenti e un elenco di cookie tra le iterazioni di test. La cache funziona come una cache del browser, pertanto non verranno effettuate richieste successive all'URL, secondo un modello che simula più da vicino il comportamento dei browser Web reali.
Se il valore di Percentuale di nuovi utenti è impostato su 100%, ogni utente sarà effettivamente un "utente che accede un'unica volta" e non ritornerà mai al sito. In questo caso ogni iterazione del test delle prestazioni Web eseguita in un test di carico viene considerata come un nuovo utente del sito Web, che non dispone nella cache del browser di alcun contenuto del sito Web ottenuto con visite precedenti. Vengono pertanto scaricate tutte le richieste del test Web, comprese tutte le richieste dipendenti come le immagini.
Nota
Un'eccezione è rappresentata dal caso in cui la stessa risorsa memorizzabile nella cache venga richiesta più volte in un test delle prestazioni Web.
Utilizzare il valore predefinito 0 della percentuale di nuovi utenti per indirizzare la maggior parte del carico al livello applicazione del sito Web. Non solo questa impostazione simula più da vicino il comportamento dei veri utenti, ma indirizza un carico maggiore al livello applicazione dove si verifica la maggior parte dei problemi di prestazioni. Per ulteriori informazioni, vedere Procedura: specificare la percentuale di utenti virtuali che utilizzano i dati della cache Web.
Abilitazione di Profiler ASP.NET
L'adattatore dati di diagnostica del profiler ASP.NET è una nuova funzionalità di Microsoft Visual Studio 2010 che consente di raccogliere dati del profiler ASP.NET dal livello applicazione durante l'esecuzione di un test di carico. Non è consigliabile eseguire il profiler per i test di carico lunghi, ad esempio i test di carico eseguiti per più di un'ora, in quanto le dimensioni del file del profiler possono aumentare fino a centinaia di megabyte. Eseguire, al contrario, i test di carico più brevi con il profiler ASP.NET che offrirà comunque il vantaggio di ottenere una diagnosi approfondita dei problemi di prestazioni.
Per ulteriori informazioni, vedere Procedura: configurare il profiler ASP.NET per i test di carico tramite impostazioni test.
Abilitazione della registrazione dell'utente virtuale
Questa nuova funzionalità di Microsoft Visual Studio 2010 consente di raccogliere log completi dei test con errori o di specificare una frequenza per la registrazione dei test. La registrazione viene controllata dalle proprietà Salva log su test non superati, Frequenza di salvataggio del log per i test completati e Numero massimo di log di test. Il numero di log raccolti viene controllato dalle impostazioni delle proprietà Numero massimo di log di test e Frequenza di salvataggio del log per i test completati. Per impostazione predefinita viene impedita la raccolta di un numero elevato di log. Per i test di lunga durata, che generano milioni di richieste, non utilizzare l'impostazione Frequenza di salvataggio del log per i test completati, diversamente il numero di log diventerà troppo elevato. Specificare inoltre un numero ragionevole per l'impostazione della proprietà Numero massimo di log di test che in effetti controlla il numero massimo di log per tipo di errore. È consigliabile mantenere queste impostazioni per impedire che vengano raccolte decine di migliaia di log, con il conseguente aumento del tempo richiesto al termine del test per raccogliere i log e dello spazio di archiviazione occupato nel database di test di carico.
Per ulteriori informazioni, vedere Modifica delle impostazioni di registrazione dei test di carico.
Attivazione della traccia SQL
Le impostazioni di esecuzione includono una proprietà denominata Traccia SQL attivata. Questa proprietà consente di abilitare la funzionalità di traccia di Microsoft SQL Server per la durata di un test di carico. Si tratta di un'alternativa all'avvio di una sessione distinta di SQL Profiler durante l'esecuzione di un test di carico per diagnosticare problemi di prestazioni SQL. Se la proprietà è abilitata, i dati di traccia SQL verranno visualizzati nell'analizzatore test di carico, nella pagina Tabelle della tabella Traccia SQL.
Per abilitare questa funzionalità, l'utente che esegue il test di carico deve disporre dei privilegi SQL necessari per eseguire la traccia SQL. Quando un test di carico è in esecuzione in un computer remoto e vengono utilizzati un agente di test e un controller di test, è necessario che l'utente del controller disponga di privilegi SQL. È inoltre necessario specificare una directory, solitamente una condivisione di rete, in cui verrà scritto il file dei dati di traccia. Al completamento del test di carico, il file dei dati di traccia verrà importato nel repository dei test di carico e associato a tale test, in modo che sia possibile visualizzarlo in seguito tramite l'analizzatore test di carico.
Per ulteriori informazioni, vedere Configurazione delle impostazioni esecuzione test di carico e Procedura: integrare i dati di Traccia SQL utilizzando l'Editor test di carico.
Mantenimento di un numero appropriato di computer agente
Se in un computer agente si registra un utilizzo della CPU superiore al 75% o se la memoria fisica disponibile è inferiore al 10%, tale computer risulta sovraccaricato. Aggiungere altri agenti al controller di test per assicurarsi che il computer agente non diventi il collo di bottiglia nel test di carico.
Per ulteriori informazioni, vedere Distribuzione di test di carico in più computer di test utilizzando controller di test e agenti di test e Procedura: specificare agenti di test da utilizzare negli scenari di test di carico.
Vedere anche
Attività
Risoluzione dei problemi relativi ai test di carico
Concetti
Analisi degli errori nei test di carico tramite la tabella degli errori
Altre risorse
Creazione e modifica di carichi di test
Consideration for Load Tests that Contain Web Performance Tests