Figment Engine

Not quite the blink of an eye: 300ms vs 100ms

2013-05-12T21:54:00.003+01:00

One of my key architectural considerations is how to make Figment Engine as fast as possible - really my goal is 100ms (the blink of an eye). Now of course this is a stretch target, its incredibly difficult to obtain and even more so for mobile users. At the moment its about 300ms and takes advantage of a CDN for everything.

The current design keeps the number of requests very low, and ultimately the assets of the page are quite small. I've avoided graphics of any sort so far (except favicon.ico).

I will need to compress files, especially the JavaScript as it grows and think about inlining some of the core CSS. I will also need to look at lazy loading, to avoid the first render being held up by downloads of assets that are not needed for that render.

					Document Complete			Fully Loaded
	Load Time	First Byte	Start Render	Speed Index	Time	Requests	Bytes In	Time	Requests	Bytes In
First View	0.342s	0.184s	0.299s	300	0.342s	4	6 KB	0.484s	4	7 KB
Repeat View	0.321s	0.000s	0.189s	200	0.321s	3	1 KB	0.321s	3	1 KB

More code, but technical debt is building

2013-05-11T22:48:00.001+01:00

So having fun adding the ability to cope with multiple commands in my command line interface - and since I know this is an early spike to get it moving I can do things that make the code functional, but also pretty ugly.

There's a few things already need fixing (some would argue I should have done them before doing anything, but I find it becomes a barrier if I try too early):

put some TDD in place, theres only ~80 odd lines of code so its still easy to do
make the code more structured (in JS land that means more objects)
separate the UI code from the logic code - so how to add a new command entry vs how to render it in HTML

One approach I like is not having lots of HTML element creation code, and a neat way round this is to clone an existing node - it probably should be a UI pattern in JavaScript. So in the example of a command line interface, where each new entry is very similar - rather than having lots of code to recreate the same structure each time: you can simply clone the first node at load time - and then clone that each time to add the same type of HTML item (with children). This also abstracts the HTML structure away from the code, so its easier to evolve the structure and appearance separate from the code. This approach can be generalized for most interfaces with multiple items that are the same (so notes, entities etc) - with the prototype UI object either being the first blank item, or hidden.

So next is probably a bit of refactoring for TDD - and I guess that means I need to find a good TDD library (and good for me means very simple and no dependencies on JQuery etc)

Writing code beats watching TV

2013-05-10T21:25:00.001+01:00

So I've started to pull together some ideas, concepts and architectures - all of which I've pushed back hard on to just start building an MVP, trying hard to focus on something that does rather than something that is..

Amazingly I still managed to spend too long thinking of domain names, without a line of code written - I guess this is the curse of new ideas, spending too much time trying to find a unique name and (critically) domain name that reflects your idea - rather than working on the idea itself. Given a MVP approach this is pretty dumb, as its unlikely that what you envisage will be the final product anyway..

Each evening this week I've written some client-side portions, be it structure (html: 30 lines), style (css: 54 lines) and some behaviour (javascript: 43 lines) - all without any server side code. I like this approach as I can focus on the user experience (what it does for you), rather than how it does it. Of course soon I will need some server help to give me the system I want, but I'm happy to follow this route for now.

One of the slightly weird things about doing this has been looking at the TV and seeing that it offers little interest compared to writing code - its more interesting to create than consume, but still it surprises me.

I'm also super happy about the expressiveness of the modern platform, 127 lines of codes gives me a bare-bones CLI - of course the JavaScript needs refactoring, but its a start ;-)

finally I put the code into git, I kind of wish I did this from the first day - but I guess I was being lazy. now whats on TV?

Xenon website

2013-01-03T22:48:00.003Z

One thing I'm adopting from the start is to release as often as possible, even if its not even MVP.

So the first step is to get a base website up. http://xenon.figmentengine.com/ is the holding location, to make this work I've done a few things:

Used Git for source control (with GitHub)
Vim for editing
S3 for static site hosting
DYN for DNS (as figmentengine.com nameservers are DYN)
Used http://www.favicon.cc/ to create a favicon (to stop 404 errors)

Disclosure: I work for Amazon Web Services, this blog however is personal and does not reflect my employer's views. I will be using AWS services as I know them well (and used them before working at AWS).

Generally I'm planning to build most of the code myself, rather than relying on libraries etc - this will change as I need to focus on the core concepts.

I will also be keeping track of the page performance, so the base website benchmarks at

Load: 0.7s, TTFB: 0.29s, Start Render: 0.57s, Doc Complete: 0.7s, Fully Loaded: 0.7s

Next steps will be to put in place a CDN (CloudFront) to reduce global latency, and switch to Route 53 for DNS hosting. These two changes will also enable a slightly different approach to building websites, a mainly static website which is enriched with dynamic content.

Project code name 'xenon'

2013-01-01T22:28:00.001Z

As with all my personal projects this one starts life with a name from the periodic table - this stops me spending too much time coming up with a name when I should be focused on the core idea.

However, my approach this time differs from my usual route, in that its much more undefined - I don't have a specific product in mind, or a defined end goal. It will however bring together a number of threads I've been thinking about for a number of years.

So watch this space for xenon featuring emergence, AI, visualization and an alternative computational model.

btw I do have a cool name for xenon, but I want to validate it matches what I actually build. My design is blank so far, so I don't want to create an artificial constraint.

TMUX on Amazon Linux (EC2)

2012-04-27T16:56:00.000+01:00

Installing TMUX 1.6 on Amazon Linux: a fix if you get

cmd-load-buffer.o cmd-load-buffer.c
cmd-load-buffer.c: In function ‘cmd_load_buffer_exec’:
cmd-load-buffer.c:93: warning: implicit declaration of function ‘bufferevent_enable’
cmd-load-buffer.c: In function ‘cmd_load_buffer_callback’:
cmd-load-buffer.c:170: warning: implicit declaration of function ‘EVBUFFER_LENGTH’
cmd-load-buffer.c:170: error: dereferencing pointer to incomplete type
cmd-load-buffer.c:175: warning: implicit declaration of function ‘bufferevent_read’
cmd-load-buffer.c:183: warning: implicit declaration of function ‘evbuffer_add_printf’
cmd-load-buffer.c:184: error: dereferencing pointer to incomplete type
make: *** [cmd-load-buffer.o] Error 1

Installing weighttp on AWS/EC2: ev library not found

2011-12-23T09:35:00.001Z

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

2011-11-19T21:23:00.001Z

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

2011-09-01T10:26:00.001+01:00

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

2011-08-30T18:14:00.000+01:00

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)

2011-08-17T12:36:00.003+01:00

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:

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)

2011-08-12T15:59:00.005+01:00

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:

<script type="text/javascript">
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>

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:

<script type="text/javascript">
</script>
<script type="text/javascript">
</script>

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:

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
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.

Go Faster Stripes for site performance and google ads

2011-08-09T16:17:00.002+01:00

Carrying on our performance experiments with Amazon AWS and Go..

Repeating the same experiments, but comparing EC2 with S3.

S3 looked like this last time:

					Document Complete			Fully Loaded
	Load Time	First Byte	Start Render	DOM Elements	Time	Requests	Bytes In	Time	Requests	Bytes In
First View	0.518s	0.391s	0.000s	14	0.518s	1	1 KB	0.518s	1	1 KB
Repeat View	0.363s	0.237s	0.000s	14	0.363s	1	0 KB	0.363s	1	0 KB

Document complete in under half a second, with TTFB of 0.391s and document complete 0.518s

These look pretty respectable, but now compare with an EC2 instance (t1.large linux) using Google Go language as a HTTP server

					Document Complete			Fully Loaded
	Load Time	First Byte	Start Render	DOM Elements	Time	Requests	Bytes In	Time	Requests	Bytes In
First View	0.342s	0.212s	0.000s	14	0.342s	1	1 KB	0.342s	1	1 KB
Repeat View	0.389s	0.224s	0.000s	14	0.389s	1	1 KB	0.389s	1	1 KB

Faster across the board - TTFB has halved to 0.212s and this is time saved off document complete and fully loaded. I was expecting that S3 would be very fast at serving static content, and its looks reasonable, but compared to this single server (large admittedly) its a fair % slower.

Now what happens with Google adverts? we get a similar google ads penalty to last time, 1.5s penalty on document complete and fully loaded:

					Document Complete			Fully Loaded
	Load Time	First Byte	Start Render	DOM Elements	Time	Requests	Bytes In	Time	Requests	Bytes In
First View	1.582s	0.283s	0.411s	175	1.582s	10	51 KB	1.582s	10	51 KB
Repeat View	1.184s	0.210s	0.523s	175	1.184s	2	6 KB	1.184s	2	6 KB

Whats hidden in these numbers is a little gem - the ~0.200s saved using the EC2 instance is still there, i.e. this performs ~0.200s faster than S3 even when using Google Ads.

So even if you have a very heavy page, and are using CDN or other techniques to speed things up, you really need to see if you can get your TTFB down - and that may mean looking at async HTTP servers such as Go or Node.js

Here is the Go code for this example (the HTML is literal using back-quotes `), based on one of the Go examples:

package main

import (
"fmt"
"http"
)

func Hello(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w,
`
<!doctype html>
<html lang="en-GB">
<head>
<meta charset="utf-8">
<title>Croydon</title>
<meta name="description" content="Croydon">
</head>
<body>
<article>
<p>Croydon</p>
<p>Information on Croydon: shops, restaurants, property, schools, council &amp; government</p>
</article>
<script type="text/javascript">
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>
</body>
</html>`)
}

func main() {
http.HandleFunc("/", Hello)
http.ListenAndServe(":8080", nil)
}

Note that the previous tests were rerun to ensure no significant variance in timings. The next set of test will be to see if we can keep sub-0.300s for template based content (as opposed to hard-coded HTML)

Don't use Google Mail to test email aliases: sent mails vanish

2011-08-01T12:18:00.003+01:00

If you setup a new email alias and want to test it then don't use Google Mail.

In order to save space gmail does not store duplicate messages, so messages sent to an alias that are redirected to your gmail account (via pop etc) simply vanish.

If you check the gmail logs (settings, accounts and import, view history) you can see it fetched the email, but then it simply discards it.

So its best to send the email using a separate client (such as swaks), this problem also appears with sub-domains

Performance: the effect of google ads

2011-07-29T16:09:00.002+01:00

I've created a test page (on the subject of croydon) that is hosted on Amazon's S3 as a static site. This is part of a series of tests I'm doing to see how best to use AWS and other technologies (mongoDB & Go), and how performance effects ranking (more on this in a later blog).

I'm expecting some delays due to the DNS setup, but the first test looks pretty good

					Document Complete			Fully Loaded
	Load Time	First Byte	Start Render	DOM Elements	Time	Requests	Bytes In	Time	Requests	Bytes In
First View	0.518s	0.391s	0.000s	14	0.518s	1	1 KB	0.518s	1	1 KB
Repeat View	0.363s	0.237s	0.000s	14	0.363s	1	0 KB	0.363s	1	0 KB

Document complete in under half a second, and fully loaded about the same! - this shows how fast Amazon's AWS is for this kind of simple site (and it took minutes to set up as well)

Now looks what happens when we add some google JavaScript for the second test

					Document Complete			Fully Loaded
	Load Time	First Byte	Start Render	DOM Elements	Time	Requests	Bytes In	Time	Requests	Bytes In
First View	2.251s	0.382s	0.703s	173	2.251s	11	51 KB	2.251s	11	51 KB
Repeat View	1.046s	0.264s	0.552s	173	1.046s	2	6 KB	1.046s	2	6 KB

Document complete is now over 2 1/4 seconds, that seems a heavy price in performance to pay - and as a website owner there is little you can do about this, an irony as Google ranks faster performing sites higher.

XML for UML State diagrams

2011-04-28T09:35:00.001+01:00

W3C again...

"..Harel State Tables are a state machine notation that was developed by the mathematician David Harel [Harel and Politi] and is included in UML [UML 2.3]. They offer a clean and well-thought out semantics for sophisticated constructs such as a parallel states. They have been defined as a graphical specification language, however, and hence do not have an XML representation. The goal of this document is to combine Harel semantics with an XML syntax that is a logical extension of CCXML's state and event notation.."

State Chart XML (SCXML): State Machine Notation for Control Abstraction

I like the microwave example:

<scxml datamodel="ecmascript" initial="off" version="1.0" xmlns="http://www.w3.org/2005/07/scxml">

  
  <datamodel>
    <data expr="5" id="cook_time">
    <data expr="true" id="door_closed">
    <data expr="0" id="timer">
  </data></data></data></datamodel>

  <state id="off">
    
    <transition event="turn.on" target="on">
  </transition></state>

  <state id="on">
    <initial>
        <transition target="idle">
    </transition></initial>
    

    <transition event="turn.off" target="off">
    <transition cond="timer >= cook_time" target="off">

    <state id="idle">
      
      <transition cond="door_closed" target="cooking">
      <transition event="door.close" target="cooking">
        <assign expr="true" location="door_closed">
        
      </assign></transition>
    </transition></state>

    <state id="cooking">
      <transition event="door.open" target="idle">
        <assign expr="false" location="door_closed">
      </assign></transition>

      
      <transition event="time">
        <assign expr="timer + 1" location="timer">
      </assign></transition>
    </state>

  </transition></transition></state>

</scxml>

The Ubiquitous W3C: Battery standards

2011-04-28T09:16:00.001+01:00

Batteries? wow!

I saw this release from the W3C and it made me sit up:

"The Device APIs and Policy Working Group has published the First Public Working Draft of Battery Status Event Specification. This specification provides tools for developers to access device battery status (charge level, time remaining, etc.) within Web Applications. This specification defines a new DOM event type that provides information about the battery status of the hosting device and associated auxiliary devices. Learn more about theUbiquitous Web Applications Activity."

why? because I thought - why is the W3C publishing standards about batteries at all? W3C stands for "World Wide Web Consortium", yet here we are looking at how to monitor battery status within a web page.

it just show you how Ubiquitous they are trying to be!

OCD

2011-04-15T16:55:00.000+01:00

love these

http://www.adaptcreative.co.uk/2010/08/mental-disorder-posters/

Print before reading

2011-04-15T16:51:00.000+01:00

especially when you print an email out, and you get an extra page with "please think about the environment before you print this..."

I wonder how much energy is waster by sending these extra bytes around the internet...

Spare us the e-mail yada-yada

http://www.economist.com/node/18529895
“IF THIS e-mail is received in error, notify the sender immediately.” “This e-mail does not create an attorney-client relationship.” “Any tax advice in this e-mail is not intended to be used for the purpose of avoiding penalt...

If it's complex it can't work until it's empty

2011-04-15T14:11:00.000+01:00

Amazing quote

An aside, what made all these things work so well is that they were empty inside. Almost skeletal. Hard to believe there isn't more to it. I asked one of my mentors how this could be and he said it has to be that way. If it's complex it can't work until it's empty. These days we have another way to describe this, my friend and former colleague David Weinberger called it Small Pieces, Loosely Joined. I've never heard a better description of the architecture of the Internet.

http://scripting.com/stories/2011/04/15/letsBuildANewInternetInAca.html#p6247

must be a line from blade runner...

Cloud Providers the new war: It Depends

2011-04-15T09:29:00.000+01:00

Some interesting reading about rackspace vs AWS in terms of price/performance

http://gasoftwareblog.com/home/2011/3/31/amazon-ec2-vs-rackspace-are-all-cloud-hosting-services-the-s.html

http://scripting.com/stories/2011/04/14/rackspaceBeatsEc2ByALot.html

http://news.ycombinator.com/item?id=2448812

reading the hacker news thread I can see that beginning of a new religion - which cloud provider do you use? its going to be one of those windows/linux, firefox/IE wars... and ultimately there no real way to say which one is best, as it depends on what you need.

I moved my hosting from a dedicated server (windows) to a AWS micro instance (linux fedora). Its only been running for two weeks, but its only cost $10 compared to $50 - of course I had a physically dedicated machine before, but the micro instance seems happy enough running email (postfix). I'll write a post about setting it up later. So the cloud will save me $1000/year - not bad!

Connected world irony

2011-04-14T17:45:00.002+01:00

Before the Internet individual computers were used to accomplish general tasks: such as word processing; spreadsheets etc.

The Internet allowed computers to be massively interconnected, allowing a user to access many other computer's resources.

Now the Cloud is moving these basic tasks to work on the Web, allowing users to work on their documents etc from any computer.

Image: jscreationzs / FreeDigitalPhotos.net

The irony of the Cloud is that an unconnected computer becomes useless, as all documents etc are in the cloud. The advent of the cloud has turned a useful general purpose tool into a type-writer with no ribbon.

This train of thought was caused my me being in Ireland, in the country side with no Internet access or mobile signal. Happily I was writing code (64bit assembly on Fedora), and I suddenly thought:

"are programmers the only people have a use for a disconnected computer any-more?"

I'm backing this watch

2011-02-05T14:55:00.001Z

this seems so smart...
http://kck.st/hyrZpz

New blogger app for android

2011-02-05T14:49:00.001Z

my first post using my phone. The main limiting factor seems to be that insert picture does not allow a web address, which is a bit daft.

stating the (un)obvious

2011-01-09T17:30:00.001Z

Red Gate