SMsoft – informatica e dintorni

Effettuare il load/stress test di un web server con Siege e Sproxy

Il load/stress test di un server web è una verifica molto importante, per capire se e come un sito web funziona al crescere delle richieste.
Praticamente viene simulata la navigazione da parte di molti utenti contemporanei, e si verificano i tempi di risposta delle varie pagine web ed anche i codici di risposta per capire se il server inizia a restituire pagine con errori.

Il tool più semplice da poter utilizzare è ab (apache benchmark), fornito con il server web apache. Oggi però parliamo di Siege e di Sproxy.
Siege è il tool vero e proprio per fare il test, mentre Sproxy serve a raccogliere le pagine web che Siege richiamerà durante il test.

Download, compilazione ed installazione di Siege e Sproxy possono essere fatti come segue:
Sproxy

Siege

Raccolta senza usare Sproxy

Eseguire:

dove http://www.miosito.ext è il sito da navigare,
-w: specifica i secondi da attendere tra una richiesta e l’altra
-l: il numero di sottocartelle da seguire (0 significa che non ci sono limiti)

ATTENZIONE: il file urls.txt verrà scritto solo a termine della raccolta, se interrompete prima la procedura, il file urls.txt risulterà vuoto.

Se si è scelto di usare questo sistema, saltare il seguente paragrafo.

Raccolta usando Sproxy

Sproxy è a tutti gli effetti un proxy web che scrive in un file le richieste che gestisce; va quindi avviato e poi va fatta la navigazione del un sito con un qualsiasi browser che dovrà essere configurato per usare il proxy fornito da Sproxy (generalmente 127.0.0.1:9001). Tale procedura però può essere noiosa e lunga. Consiglio una scorciatoia: usare wget per “navigare automaticamente” un sito.
Avviamo Sproxy:

e poi eseguiamo:

dove http://www.miosito.ext è il sito da navigare,
-w: specifica i secondi da attendere tra una richiesta e l’altra
-l: il numero di sottocartelle da seguire (0 significa che non ci sono limiti)

Ora possiamo procedere con il test

In base al numero di pagine presenti nel sito, si dovrà ora attendere un po’ di tempo. Completata questa fase, possiamo ripulire il file con l’elenco degli url, togliendo i doppioni:

ed infine possiamo avviare Siege, per testare il nostro server web:

I parametri usati sono:
-v visualizza più informazioni durante il test
-c il numero totale degli utenti simulati
-i richiama gli url in modalità random
-t specifica il tempo di esecuzione di siege (si può usare S – secondi -, M – minuti – o H – ore-)
-f il file con gli url da richiamare
-d il tempo massimo di ritardo delle richieste simulate

Questa richiesta simula la navigazione da parte di 50 utenti per 3 minuti, che richiamano le url presenti nel file uniq_urls.txt in modo random e con un intervallo che va da 1 a 10 secondi. Il risultato potrebbe essere qualcosa simile a:

Le informazioni restituite sono abbastanza esplicative. I parametri chiave sono Availability (che deve essere prossimo al 100%), Transaction rate (che indica le richieste servite al secondo), Response time (che indica il tempo medio per le risposte), Failed transactions (che deve essere prossimo a 0) e Longest transaction (che indica il tempo massimo per la restituzione di una pagina e che deve essere il più possibile vicina a 0 secondi, ma ovviamente può arrivare anche a diversi secondi se il test è molto aggressivo).

Per avere informazioni interessanti, si dovrebbe eseguire siege più volte, con un numero sempre maggiore di utenti (50,100,200,500,1000) ed un tempo di più minuti (almeno 15-30). Questo permetterà di capire come il server risponde, analizzando anche il load e l’occupazione di ram/swap durante il test.

Ecco una semplice formula da utilizzare, per calcolare il numero di utenti in base alla durata del test ed al totale delle richieste che si pensa di avere in un’ora:
utenti = (pagine_totali_richieste_per_ora * minuti_durata_test) / (60 * numero_pagine_richieste_per_utente)

Nota bene

Il test fatto con siege e generalmente più aggressivo della reale navigazione dello stesso numero di utenti impostati, perché il tempo di click tra le varie pagine e generalmente più lungo e soprattutto perché la maggior parte dei browser degli utenti fa cache delle richieste (questo può essere configurato modificando ~/.siegerc ed impostando cache = true).

enjoy!




Se hai trovato utili le informazioni su questo blog,
Fai una donazione!
Clicca sul bottone qui sotto o almeno clicca sul banner pubblicitario :-)
*

Commenti

Page optimized by WP Minify WordPress Plugin