Speed testing your website with Siege: Part two

Speed testing your website: part two

Speed testing more than one url

If you need to test more than one URL then you will need to tell Siege to use a file to load the URL’s from. Simply create a text file called urls.txt and add each URL you want to test on a separate line.

To tell Siege to use your urls.txt you need to use the -f parameter.

As you can see, Siege has requested both URL’s from the file at random intervals.

Speed testing a web page with all it’s assets (JavaScript,CSS, Images etc)

Everything we have done so far has been testing single html files which is useful for testing page generation. But what if we need to find out the speed of a whole web page including all the images, javascript, css files, video etc? Simple, you put all the URL’s of all the webpage assets into the urls.txt file. However, doing this by hand can be quite painful. Fortunately we can use a proxy tool to create the URL’s for us.

Introducing sproxy

The author of Siege, Jeffrey Fulmer (see the siege website) has also written a companion program to Siege called ‘sproxy’. Quite simple, sproxy logs all urls to a text file for use with Siege. To do this you need to tell your web browser to connect to the proxy and then simply load your webpage.

Installing sproxy on Ubuntu (and derivatives)

Unlike Siege, sproxy doesn’t appear to be packaged for Ubuntu, so we need to compile and install it.

Once sproxy is installed you should configure your browser to use the proxy. In Firefox, go to Preferences > Advanced > Network and click the ‘settings’ button. Then select ‘Manual Proxy Configuration’ and enter ‘’ in the ‘HTTP Proxy:’ field, and ‘9001’ in the Port Field. Once you have done this, click ‘OK’ and close your Preferences dialog. [screenie]

Go to your terminal and launch sproxy. By default it will bind to the localhost and use port 9001. Now go to your browser and load a single page on your website. When it has finished loading, go back to your terminal and quit sproxy using CTRL-C.

Now view your urls.txt file and you should see the URL’s of all images,css and javascript (and any other assets) that your web page contains. Check the file through and remove any URL’s you don’t want to test such as Google Analytics.

Once you’ve cleaned your urls.txt file you can then siege it as we did previously. This time we’ll simulate one user making one request of the whole web page, assets and all.

Simulate Browser Caching

Siege, by default, requests each URL from the server regardless of any expiry headers sent by the server. This allows us to simulate a page load with an empty cache but we can also configure Siege to request the URLs and respect any expires headers that are sent. To do this, open your ~/.siegerc file in your text editor and find the Cache revalidation section (around line 101 in my file). Simply change the line to ‘cache = true’, save it and re-run your test, this time with the -v flag.

  • Adam F

    I’m experiencing a problem on Ubuntu 11. After an error-free compilation and installation, when I attempted to run “sproxy”, I got this:

    Can’t locate URI.pm in @INC (@INC contains: /usr/local/bin/../lib/sproxy/x86_64-linux-gnu-thread-multi /usr/local/bin/../lib/sproxy /usr/local/bin /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at (eval 5) line 2.
    Compilation failed in require at /usr/local/bin/../lib/sproxy/HTTP/Request.pm line 5.
    Compilation failed in require at /usr/local/bin/../lib/sproxy/LWP/UserAgent.pm line 12.
    BEGIN failed–compilation aborted at /usr/local/bin/../lib/sproxy/LWP/UserAgent.pm line 12.
    Compilation failed in require at /usr/local/bin/sproxy line 10.
    BEGIN failed–compilation aborted at /usr/local/bin/sproxy line 10.