Come impostare un carico/stress test per un sito web?

Question

Sono stato incaricato di stress/carico testare il nostro sito web aziendale in modo imprevisto e non sapere nulla di farlo. Ogni ricerca che faccio su google per "come caricare test di un sito web" ritorna con varie aziende e software per eseguire fisicamente il test di carico.

Per ora sono più interessato a come impostare effettivamente un test di carico come quello che dovrei prendere in considerazione prima del test di carico, quali pagine del mio sito dovrei testare con carico e quali cose sono Vado a voler monitorare quando si effettua il test. Il nostro sito Web è su un sistema multilivello completo di un server di database separato (IIS 7 Web Server, SQL Server 2000 db). Immagino di voler monitorare sia il server web che il server di database per testare il caricamento, tuttavia, quando si impostano scenari per caricare test del server Web, dovrei usare le pagine che interrogano il database per vedere qualsiasi carico sul server database a lo stesso tempo.

I server Web ei server di database sono generalmente testati simultaneamente o vengono eseguiti come test separati?

Come potete vedere, sono abbastanza all'oscuro dell'intera operazione, quindi qualsiasi incentivo su come procedere sarebbe molto utile.

FYI mi sono stati armeggiare con Pylot ed era in grado di creare ed eseguire uno scenario contro il nostro sito, ma io non sono sicuro di quello che dovrebbe essere alla ricerca nei risultati, o se lo scenario che ho creato è ancora uno scenario degno di misurazione per il nostro sito.

Grazie in anticipo.

Answer 1

Check out JMeter. Ho trovato un po 'complicato iniziare, ma una volta completata la configurazione dei test è facile eseguirla. Hanno un tutorial su come impostare i test distribuiti here.

Answer 2

Ecco un elenco di strumenti che consentono di iniziare con questo. Hai ragione a voler leggerlo prima, lo stress testing può diventare complicato.

http://www.softwareqatest.com/qatweb1.html

Answer 3

primo luogo, avere uno strumento web-stress come Neoload.

Modella un numero di attività utente e bias il test per corrispondere ai modelli utente previsti, quindi ridimensiona il carico come meglio credi. Esecuzione di query sul database e misurazione del tempo di risposta non ti dice nulla sull'esperienza utente. Piuttosto, modellando le attività degli utenti, puoi valutare esattamente come il tuo server/sistema risponderà sotto il carico reale , poiché è quello che genererai.

La modellazione dell'attività dell'utente può diventare piuttosto complessa, ma gli strumenti di stress come Neoload consentono di modellare da vicino il comportamento esatto di qualsiasi macchina che colpisce il server. Idealmente, creerai il traffico di rete proprio come faresti normalmente, quindi assicurati di colpire il tuo bilanciamento del carico se ne hai uno.

Answer 4

In generale, i test di carico vengono eseguiti attraverso scenari comuni con vari carichi utente.

Ad esempio, è possibile impostare un test in cui 50 utenti accedono ogni secondo per 10 minuti e un altro in cui il numero inizia a 5 utenti al secondo e scala fino a 1000/secondo o qualsiasi numero abbia senso per il proprio sito.

modifica:
L'idea è di verificare come si comporta l'applicazione effettiva quando è in uso su tutti i livelli.
Se si sta per testare il carico, investire decisamente (tempo e/o $) in un buon strumento.

Answer 5

Ho trovato la versione di Visual Studio Test più facile da testare (anche se non è gratuita). Puoi registrare una sessione di navigazione come un singolo test e ti permetterà di leggere le statistiche perfmon sia dal tuo server web che dal tuo database abbastanza facilmente.

Il primo passo da fare è guardare i registri di IIS per scoprire cosa sta succedendo lì. Log Parser 2 is the tool Vorrei utilizzare dovrebbe ottenere i registri di IIS in un database.

Interrogazione che ti darà un'idea del carico di punta.

Il passo successivo è formulare un obiettivo o due per il test. Devi assicurarti che il sito web sia in grado di gestire carichi di picco su una singola pagina o due di richieste X al secondo?

Si intende aumentare i clienti del sito, nel qual caso prendere il carico del registro IIS corrente e webtest forumlate in grado di simulare tale intervallo di richieste di pagine, ma caricare per gli utenti concorrenti previsti.

Se si intende modificare la funzionalità sul sito, è possibile eseguire un test di carico di riferimento e confrontare il rendimento dopo eventuali modifiche al sito.

Il vero obiettivo del test di carico è dimostrare che l'applicazione e l'hardware sono in grado di gestire un carico target che l'azienda trova accettabile e restituisce comunque le pagine in un tempo ragionevole.

Answer 6

Come si può vedere dalle risposte a questa domanda, ci sono molti programmi disponibili per il test di carico. Nella mia esperienza ho trovato il Siege il mio preferito. È semplice, fornisce la maggior parte delle opzioni necessarie per eseguire test di carico. Ecco un esempio di utilizzo:

seige -c 10 -t 1M http://www.google.com 

In questo modo verranno inviate 10 richieste simultanee a google.com per 1 minuto. Se vuoi testare più di una pagina puoi anche fornire un file che contiene un elenco di URL.

Si noti che uno strumento come seige è appropriato quando si dispone di un singolo o di una serie di URL che si desidera testare. Se si desidera testare flussi più complicati (ad esempio, l'utente accede, invia la voce, si disconnette), quindi si vorrà utilizzare qualcosa come il selenio.

Answer 7

Il numero di passaggio 1 per un sito esistente o un sostituto per lo stesso è quello di raccogliere e analizzare. Statistiche.

Nessun punto nelle previsioni di modellazione prima se sono al di fuori del limite centrale. (Verranno comunque in modo rigoroso)

E in tutti i casi, dovresti lavorare in concerto con qualcuno del NOC. Le ragioni sono troppo ovvie e il thread qui che supporta un approccio eroe non è positivo per la tua azienda; specialmente come imparerai mentre vai. Per non dire che non si può essere un eroe, ma i NOC sono notoriamente belligeranti per i numeri delle prestazioni che cadono in grembo in una riunione decisionale.