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).
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).
.)
What does this mean for the performance tester?
Well, I think this may be a bit of a headache for vendors creating protocol adaptors (particularly if there are multiple versions of the SPDY protocol). Traffic is now weaved into the same streams, servers can ‘hint’ and push content – which make the request behaviour of the client bowser implementation specific and difficult to emulate for performance testing. Client behaviour logic (e.g listener instances) may have to be hooked into script logic, communication is now asynchronous with a server side push ability. It may also mean that the performance tester will have to dual test and code HTTP and SPDY protocols. Servers will inevitably be serving both types of protocol. All in all, it could amount to a fair amount of re-engineering on the performance scripting side for advanced SPDY communication.
.
Is this going to be Adopted?
I think yes. Chrome/Amazons Silk Browser already implement this. Apache already has a plugin for this. Significant resources are now being poured into making the web faster for the savy end consumer. The benefits are so large I fail to see how it won’t be adopted by commercial organisations. Also, in the arms race that is the browser wars – IE will have to follow suit if FF picks this up. I’m pleased to hear its open source as the project will get the benefits of uninhibited inovation. Even Google, with its mighty resources, realise they can benefit from the knowledge of the collective. No doubt they will use this as an opportunity to recruit the bright sparks that make this tick better. I’ll also be surprised if CDN’s or the magic ‘black boxes’ (e.g. Torbit/Strangeloop) are not already looking into leveraging this for Chrome clients.
.
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.
Links:
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/