<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>test &#8211; SMsoft &#8211; informatica e dintorni</title>
	<atom:link href="https://blog.smsoft.it/tag/test/feed/" rel="self" type="application/rss+xml" />
	<link>https://blog.smsoft.it</link>
	<description>consigli settimanali su MacOS, GNU/Linux ed Open Source</description>
	<lastBuildDate>Tue, 08 Jan 2013 09:28:17 +0000</lastBuildDate>
	<language>it-IT</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=72636</generator>
	<item>
		<title>Effettuare il load/stress test di un web server con Siege e Sproxy</title>
		<link>https://blog.smsoft.it/2013/01/08/effettuare-lo-stress-test-di-un-web-server-con-siege-e-sproxy/</link>
					<comments>https://blog.smsoft.it/2013/01/08/effettuare-lo-stress-test-di-un-web-server-con-siege-e-sproxy/#respond</comments>
		
		<dc:creator><![CDATA[admin]]></dc:creator>
		<pubDate>Tue, 08 Jan 2013 09:28:17 +0000</pubDate>
				<category><![CDATA[Debian]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[MacOS]]></category>
		<category><![CDATA[Open Source]]></category>
		<category><![CDATA[Sicurezza]]></category>
		<category><![CDATA[ab]]></category>
		<category><![CDATA[apache]]></category>
		<category><![CDATA[load test]]></category>
		<category><![CDATA[siege]]></category>
		<category><![CDATA[sproxy]]></category>
		<category><![CDATA[stress test]]></category>
		<category><![CDATA[test]]></category>
		<category><![CDATA[web]]></category>
		<category><![CDATA[wget]]></category>
		<guid isPermaLink="false">http://blog.smsoft.it/?p=2179</guid>

					<description><![CDATA[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 ... <a title="Effettuare il load/stress test di un web server con Siege e Sproxy" class="read-more" href="https://blog.smsoft.it/2013/01/08/effettuare-lo-stress-test-di-un-web-server-con-siege-e-sproxy/" aria-label="Per saperne di più su Effettuare il load/stress test di un web server con Siege e Sproxy">Leggi tutto</a>]]></description>
										<content:encoded><![CDATA[<p>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.<br />
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.</p>
<p>Il tool più semplice da poter utilizzare è ab (apache benchmark), fornito con il server web apache. Oggi però parliamo di <a href="http://www.joedog.org/siege-home/" target="_blank" rel="noopener noreferrer">Siege</a> e di <a href="http://www.joedog.org/sproxy-home" target="_blank" rel="noopener noreferrer">Sproxy</a>.<br />
Siege è il tool vero e proprio per fare il test, mentre Sproxy serve a raccogliere le pagine web che Siege richiamerà durante il test.<br />
<span id="more-2179"></span><br />
Download, compilazione ed installazione di Siege e Sproxy possono essere fatti come segue:<br />
Sproxy</p><pre class="urvanov-syntax-highlighter-plain-tag">wget http://download.joedog.org/sproxy/sproxy-latest.tar.gz
tar xzvf  sproxy-latest.tar.gz
./configure
make
make install</pre><p></p>
<p>Siege</p><pre class="urvanov-syntax-highlighter-plain-tag">wget http://download.joedog.org/siege/siege-latest.tar.gz
tar xzvf  siege-latest.tar.gz
./configure
make
make install</pre><p></p>
<h2>Raccolta senza usare Sproxy</h2>
<p>Eseguire:</p><pre class="urvanov-syntax-highlighter-plain-tag">wget --spider --force-html -r -l0 -w1 http://www.miosito.ext 2>&1| grep '^--' | awk '{ print $3 }' >> urls.txt</pre><p>dove http://www.miosito.ext è il sito da navigare,<br />
-w: specifica i secondi da attendere tra una richiesta e l&#8217;altra<br />
-l: il numero di sottocartelle da seguire (0 significa che non ci sono limiti)</p>
<p><strong>ATTENZIONE:</strong> il file <strong>urls.txt</strong> verrà scritto solo a termine della raccolta, se interrompete prima la procedura, il file <strong>urls.txt</strong> risulterà vuoto.</p>
<p><em><strong>Se si è scelto di usare questo sistema, saltare il seguente paragrafo</strong></em>.</p>
<h2>Raccolta usando Sproxy</h2>
<p>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 &#8220;navigare automaticamente&#8221; un sito.<br />
Avviamo Sproxy:</p><pre class="urvanov-syntax-highlighter-plain-tag">sproxy</pre><p>e poi eseguiamo:</p><pre class="urvanov-syntax-highlighter-plain-tag">wget -r -o verbose.txt -l 0 -t 1 --spider -w 1 -e robots=on -e "http_proxy = http://127.0.0.1:9001" "http://www.miosito.ext"</pre><p></p>
<p>dove http://www.miosito.ext è il sito da navigare,<br />
-w: specifica i secondi da attendere tra una richiesta e l&#8217;altra<br />
-l: il numero di sottocartelle da seguire (0 significa che non ci sono limiti)</p>
<h3>Ora possiamo procedere con il test</h3>
<p>In base al numero di pagine presenti nel sito, si dovrà ora attendere un po&#8217; di tempo. Completata questa fase, possiamo ripulire il file con l&#8217;elenco degli url, togliendo i doppioni:</p><pre class="urvanov-syntax-highlighter-plain-tag">sort -u -o uniq_urls.txt urls.txt</pre><p></p>
<p>ed infine possiamo avviare Siege, per testare il nostro server web:</p><pre class="urvanov-syntax-highlighter-plain-tag">siege -v -c 50 -i -t 3M -f uniq_urls.txt -d 10</pre><p>I parametri usati sono:<br />
-v visualizza più informazioni durante il test<br />
-c il numero totale degli utenti simulati<br />
-i richiama gli url in modalità random<br />
-t specifica il tempo di esecuzione di siege (si può usare <strong>S</strong> &#8211; secondi -, <strong>M</strong> &#8211; minuti &#8211; o <strong>H</strong> &#8211; ore-)<br />
-f il file con gli url da richiamare<br />
-d il tempo massimo di ritardo delle richieste simulate</p>
<p>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:</p><pre class="urvanov-syntax-highlighter-plain-tag">Transactions:		         116 hits
Availability:		      100.00 %
Elapsed time:		       59.10 secs
Data transferred:	        0.05 MB
Response time:		        0.00 secs
Transaction rate:	        1.96 trans/sec
Throughput:		        0.00 MB/sec
Concurrency:		        0.00
Successful transactions:         116
Failed transactions:	           0
Longest transaction:	        0.01
Shortest transaction:	        0.00</pre><p></p>
<p>Le informazioni restituite sono abbastanza esplicative. I parametri chiave sono <strong>Availability</strong> (che deve essere prossimo al 100%), <strong>Transaction rate</strong> (che indica le richieste servite al secondo), <strong>Response time</strong> (che indica il tempo medio per le risposte), <strong>Failed transactions</strong> (che deve essere prossimo a 0) e <strong>Longest transaction</strong> (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).</p>
<p>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&#8217;occupazione di ram/swap durante il test.</p>
<p>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&#8217;ora:<br />
<strong>utenti</strong> = (<strong>pagine_totali_richieste_per_ora</strong> * <strong>minuti_durata_test</strong>) / (60 * <strong>numero_pagine_richieste_per_utente</strong>)</p>
<h2>Nota bene</h2>
<p>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 <strong>~/.siegerc</strong> ed impostando <strong>cache = true</strong>).</p>
<p>enjoy!</p>
]]></content:encoded>
					
					<wfw:commentRss>https://blog.smsoft.it/2013/01/08/effettuare-lo-stress-test-di-un-web-server-con-siege-e-sproxy/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
