Installing weighttp on AWS/EC2: ev library not found

when installing weighttp on AWS EC2 using the Amazon Linux AMI you might get errors such as:

• "ev library not found." when running ./waf configure or
• libev.so.4 not being found

This series of steps fixed it for me:

Sutton with analytics

Sutton: a website to test performance & seo has not reach #1 yet :-)

The next stage is to get more information about visits, before adding google analytics the page performed something like this:

					Document Complete			Fully Loaded
	Load Time	First Byte	Start Render	DOM Elements	Time	Requests	Bytes In	Time	Requests	Bytes In
First View	0.355s	0.321s	0.383s	31	0.355s	1	3 KB	0.597s	3	8 KB
Repeat View	0.279s	0.240s	0.259s	31	0.279s	1	3 KB	0.290s	2	3 KB

After adding it looked performed like this:

					Document Complete			Fully Loaded
	Load Time	First Byte	Start Render	DOM Elements	Time	Requests	Bytes In	Time	Requests	Bytes In
First View	0.364s	0.331s	0.393s	36	0.364s	2	16 KB	0.687s	5	22 KB
Repeat View	0.338s	0.225s	0.369s	36	0.338s	2	4 KB	0.498s	3	4 KB

Overall its looks ok (a few extra KB - hopefully that users have already loaded from visiting other sites), however the repeat view time has crept up by nearly 0.200s, something that is not too surprising with the need to force the client to fetch a non-cacheable tracking image (GET /__utm.gif?...).

Comparing S3 with EC2 micro instance with go

Created the same page on both S3 and on an EC2 micro instance running linux & go.

Using Google's web master tools as a bench-marker: the S3 instance is for Croydon:

And on EC2 micro instance for New Malden:

Time spent downloading a page (in milliseconds)

Looks pretty good - this is the instance that bench-marked well.

All assets etc are the same, so should be a fair comparison, I'll give it a few days to get a good average.

Perfomance of Go as a web server on Amazon AWS

Continuing the series on performance and exploring the Go language I wanted to see how many requests/second I could get out of an Amazon micro instance.

I used Siege for the testing of the "Sutton" server, and using the same code that gives us this sort of response:

					Document Complete			Fully Loaded
	Load Time	First Byte	Start Render	DOM Elements	Time	Requests	Bytes In	Time	Requests	Bytes In
First View	0.355s	0.321s	0.383s	31	0.355s	1	3 KB	0.597s	3	8 KB
Repeat View	0.279s	0.240s	0.259s	31	0.279s	1	3 KB	0.290s	2	3 KB

I also added some caching on the server side, to stop it regenerating the content every time.

Using Siege from a large instance (a small instance could not generate enough requests) I got the following results:


$ siege -c 40 -t 20s -d0 http://wimbledon.chart.is


Lifting the server siege...      done.
Transactions:       28178 hits
Availability:      100.00 %
Elapsed time:       19.78 secs
Data transferred:       68.07 MB
Response time:        0.03 secs
Transaction rate:     1424.57 trans/sec
Throughput:        3.44 MB/sec
Concurrency:       37.69
Successful transactions:       28178
Failed transactions:           0
Longest transaction:        1.51
Shortest transaction:        0.00

So over 1,000 requests/second on the smallest AWS instance! the server is running at 100% CPU so some simple performance analysis could yield some significant improvements. Also some more effort around making the benchmark more trustworthy, especially with higher numbers of concurrent requests.

Hosting favicon.ico on a different server (Amazon S3)

To increase the performance of our very simple Where is Croydon test site static assets are hosted on S3.

One of the assets that is requested for a site is favicon.ico the icon is used against the site name in browsers (normally to make spotting it among many tabs easier). By default this is requested from the root of the site, however this can be changed by adding:

<link rel="shortcut icon" href="http://static.chart.is/favicon.ico" />

to each page (head element) on the site.

To host it on S3 requires a bucket matching the domain name, and mapping a CNAME to point to the amazon end-point. In this case using a "static" sub-domain to host these kinds of static assets. Note: if you get "Access Denied" from these its probably because of permissions for "Everyone" to open/download are not set (per asset).

Doing this means the browser can use a separate connection to retrieve the icon, and therefore process the download in parallel with other content. Its worth considering multiple sub-domains if you have many static assets. This also has the benefit of reducing requests to your site's servers, and improving server-side cache hits as well.

During testing of this a little "feature" of chrome was discovered, it requests "/favicon.ico" from you site if you do a "view page source" - even if you specify a different location.

Google Ads Async (asynchronous)

Making Google Ads asynchronous seems to be critical to achieving better performance, in this post in the continuing series on optimization of sites (Performance: the effect of google ads and Go Faster Stripes for site performance and google ads), a simple idea has some interesting implications.

The current ad code for Where is Croydon looks like this:

&lt;script type="text/javascript"&gt;&lt;!--
google_ad_client = "pub-7600935420912685";
google_ad_slot = "7690333966";
google_ad_width = 336;
google_ad_height = 280;
//--&gt;
&lt;/script&gt; 
&lt;script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js"&gt; 
&lt;/script&gt; 


And performs like this:

					Document Complete			Fully Loaded
	Load Time	First Byte	Start Render	DOM Elements	Time	Requests	Bytes In	Time	Requests	Bytes In
First View	1.939s	0.289s	0.426s	187	1.939s	12	52 KB	2.438s	14	53 KB
Repeat View	1.054s	0.228s	0.574s	182	1.054s	2	6 KB	1.054s	2	6 KB

Document complete in about 2 seconds is not good enough, (given our page has nothing on it), and the advert script is going to slow down any other asset downloads (by putting the browser into serial mode).

So how can we fix this? a bit of re-plumbing should fix this, our ad script becomes:


&lt;script type="text/javascript"&gt;&lt;!--
google_ad_client = "pub-7600935420912685";
google_ad_slot = "7690333966";
google_ad_width = 336;
google_ad_height = 280;
//--&gt;
&lt;/script&gt; 
&lt;script type="text/javascript"&gt;&lt;!--
// dynamically Load Ads out-of-band
setTimeout((function ()
{
// placeholder for ads
        var eleAds = document.createElement("ads");  
        // dynamic script element
        var eleScript = document.createElement("script");  
        // remember the implementation of document.write function
        w = document.write;
        // override and replace with our version
        document.write = (function(params)
        {
// replace our placeholder with real ads
eleAds.innerHTML = params;
// put the old implementation back in place
document.write=w;
        });
        // setup the ads script element
        eleScript.setAttribute("type", "text/javascript");
        eleScript.setAttribute("src", "http://pagead2.googlesyndication.com/pagead/show_ads.js");
        // add the two elements, causing the ads script to run
        document.body.appendChild(eleAds);              
        document.body.appendChild(eleScript);           
}), 1);
                //--&gt;
        &lt;/script&gt; 


How does this work? Google's Ad script is quite "nasty" as it uses document.write, generally not a good idea  as it can only be used during page creation. So this script does two things:

1. it dynamically inserts the Google ad script, allowing this to be separate from the main page render, hence the rest of the page can load without waiting for the adverts
2. it re-plumbs the document.write function to instead add the ads to a placeholder element. If this is not done then the Google code will try to call document.write and it won't output anything as the document is already complete. For completeness the code re-plumbs document.write after the first call, but really there should be no other code calling it.

Now this code is far from bullet proof, or tested (WOMM), but it shows the basic principle - it works only because its specific to the Google code, a more generic solution might need to follow this approach.

What does all this effort yield us:

					Document Complete			Fully Loaded
	Load Time	First Byte	Start Render	DOM Elements	Time	Requests	Bytes In	Time	Requests	Bytes In
First View	0.484s	0.332s	0.584s	191	0.484s	1	3 KB	2.353s	13	55 KB
Repeat View	0.347s	0.211s	0.611s	186	0.347s	1	0 KB	1.185s	2	6 KB

Fully loaded has not changed (as expected, we are still loading the same amount), but document complete is massively improved - from 2 seconds to less than half a second. Whilst this might seem to be moving numbers around, it means that the browser can render the rest of the page before adverts, and since adverts can be very very slow, this can make the site appear much faster.

And for those of you who do want to cheat performance numbers, then changing the  "}), 1);" line to "}), 4000);" gives you this. A page that is "fully loaded" in 0.39 seconds - this is of course cheating, the adverts appear 4 seconds later, but https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/quick-start-quide#TOC-Fully-Loaded: looks for 2 seconds of no activity to judged fully loaded time.