I love efficiency. It has a direct impact on speed and performance. I’ve been busy on other projects so my blogging has taken a back seat; however I’m attempting to write at least one a week to keep the site fresh and (hopefully) interesting.
I recently came across a Tweet indicating Firefox may implement SPDY. This is big news. For those of you that don’t know what SPDY (pronounced “SPeeDY”) is – It’s a networking protocol created by Google to ‘complement’ HTTP. It has been specifically designed to significantly decrease the load times of web pages – and does so by an average of 50%. This is mainly achieved by multiplexing and compression. I’ll outline what I’ve read and attempt to surmise the benefits and impacts:
- Compression: This has been has been designed into the protocol at a session layer. There are obvious benefits to compression – and a surprising number of sites out there do not implement this.
- Multiplexing: This is a more significant change as it allows a single connection to be established between the client and server and also allows the transport of several files across one TCP/IP session. Most browsers open up several connections to load multiple resources to circumnavigate the inherent issues with HTTP (it can only fetch one resource at a time).
- Request Prioritisation – SPDY can assign a priority to each resource requests and one of the obvious applications of this is to ‘black box’ the User Perceived Page Load time more intelligently.
- Server Push Content: Another goal of the protocol is to enable the server to initiate communication with the client and push content. Wow! How great is that!? I’m not sure how that would work alongside HTTP, so I’m guessing the client – server application – would have to be specifically using SPDY to implement that.
- Server Hint: Not pushing, just a ‘hint’ from the server that the client is going to require resources it doesn’t yet know about. This is similar to someone finishing off your sentence for you. This, of course, means the server can pre-fetch everything it thinks you need and serve you quickly.
- OSI Application Layer Improvements: Google looked at the inherent issues with TCP/IP and decided to leave that alone (good choice) for now. Their sight scope was aimed on the Application Layer protocol HTTP. From what I read, the basic options of SPDY support HTTP Post and Get. However the more advanced options will not.
Let’s remember – a 50% reduction in page load time does not mean a 50% reduction in traffic. But there should be a significant amount of traffic reduction (TODO: Find some accurate figures for this – I think ‘only’ 32%). This is an invisible and seismic transformation. How much greener will the infrastructure that serves the web be? How many less server instances HGH will be required on the application tiers? I’m excited! However, there must be a downside; the only ones I can think of are that the Server Hint and Push will be prone to breaking in edge cases. I also suspect SPDY will have to naturally refine, improve and change over time – this may mean different versions for SPDY protocols and all the headaches this will bring with it. SPDY while efficient, may increase the CPU Spike load on server resources, meaning servers may be subject to more extreme load. Front facing server infrastructure focussed on Layer7 may be need reprogrammed so they are equipped to deal with SPDY (e.g. load balancers).
Of course, we all know what happens when things become more efficient – we fill the spared capacity with the next ‘needed’ thing wiping out the initial efficiency gains 🙂
Jason
PS It would be great to get your feedback on this, and other significant impacts and areas I may not have covered.
A must see for performance testers: a blog post that evaluates the performance of SPDY enabled servers:
http://www.neotys.com/blog/performance-of-spdy-enabled-web-servers/