This post summarizes the results of my initial experimentation with SPDY protocol. In summary the results did not show any dramatic improvement in speeding up loading of my test web page. My test scenario was with the server on my server grade laptop (NodeJS server, SPDY over SSL) in Pune, India and the client Google Chrome browser running on a machine in Sunnyvale, CA, USA. The test page loaded the same 1million pixel image side by side, one side from a SPDY server and the other side from a NON-SPDY server. Everything except for the transport was equivalent for both servers. Test results are visual. So here you go, my test screen capture video (all thanks to VLC Media Player.)
The test showed only marginal increase in speed for SPDY based fetch. Now there are some factors that would make this test non conclusive. Foremost of which is that it at the most only shows that NodeJS’s SPDY wrapping is not high performing. There are other servers (Notably HTTPD) which supports SPDY and ‘might’ give better results. I will test it and report back. On extremely slow connections however there was dramatic speed gains with SPDY with it performing three times as fast as plain HTTP connection. But with a bandwidth as little as 1Mbps, the difference in speed gains were to the magnitude of 10%.
EDIT:
One of my colleagues was nice enough to put together a test rig that tested parallel loading of 50 , 512px x 512px JPEG tiles over SPDY and normal HTTP. Results showed a lot more improvement over my previous scenario where I was loading one large image. Again she kept the test servers in US West Coast and clients in Pune, India to simulate a large round trip. Her tests showed a minimum of 25% better performance with SPDY. Under increased load (4 users each on SPDY and HTTP) the performance gains for SPDY were close to 50%. Thank you Prof Tony O’Hagan for suggesting this alternate test scenario that showed some real performance gains.
SPDY (pronounced SP-EE-DY) has promise of speeding up our internet experience. It is a protocol actively developed and promoted by Google over the last few years as part of chromium. It has already found serious early adopters in heavy weights such as facebook, twitter and wordpress. Gmail and various applications from Google are also served over SPDY whenever possible. If you are using any of these websites on Chrome or on recent versions of Firefox you are already accessing data over SPDY. On the server side Apchae HTTPD, Tomcat, Jetty, Python, Ruby and NodeJS has implementations that can stream data over SPDY as an alternative. Libraries in almost all popular languages and platforms are also out there – such as JAva Client., iOS client, C, Android Client and the usual suspects such as PHP, Ruby and JavaScript. The observed speedup is in the tune of 60% when compared with HTTP. This is huge. The basic premise of implementation strategy is that by using HTTP a lot of time is wasted in Round Trips between client and Server. While some round trips cannot be avoided, SPDY gives developers a chance to minimize the impact of these round trips on end user experience. This minimization is ensured through some clever practical solutions.
- Ability to PUSH content preemptively to client. For example while loading index.html that has four <IMG> tags, HTTP will first load and parse the HTML and then make four separate server requests to fetch back the four <IMG> images. Now, if the server can start pushing the image content right when index.html is requested, and that through the more efficient protocol such as SPDY, then over all load time of index.html should reduce considerably.
- Ability to HINT to the client to request for certain resources before an HTML page mandates its need. This is a more conservative take on point 1.
- Provision to set the frame sizes for data pushes to client. This is great since now depending on the bandwidth server can decide on sending data across in as few pushes as possible.
- Multiplexed Streams : SPDY does not restrictions on number of parallel HTTP requests to the servers. In Asynchronous web this make a lot of sense. Even on the most modern web browsers today the number of concurrent server connections is capped at 6. Not too good.
- SPDY uses TCP more efficiently.
The server I am using for this test is once again written in JavaScript and is running with NodeJS (v0.8.16) and Node-SPDY (1.4.5). It uses a 1 million pixel image generated using a simple Java code. Running it locally might not be most ideal. If you have access to geographically separated machines please feel free to deploy test and report back. Source code is published here.
Code to create large test image.
public void creareLargeJpeg() throws Exception{ int width = 1000; int height = 1000; BufferedImage bi = new BufferedImage(width, height, BufferedImage.TYPE_INT_RGB); Graphics g = bi.getGraphics(); Random r = new Random(System.currentTimeMillis()); for (int x = 0 ; x < width; x+=10){ for (int y = 0 ; y < height; y+=10){ Color c = new Color(r.nextInt(255),r.nextInt(255),r.nextInt(255)); g.setColor(c); g.fillRect(x, y, 10, 10); } } g.dispose(); File output = new File("target/output.jpg"); ImageIO.write(bi, "JPEG", new FileOutputStream(output)); }
Code for the SPDY and plain HTTP server (server.js)
var express = require('express'); var app = express(); var app1 = express(); var spdy = require('spdy'), fs = require('fs'); app.use(express.static(__dirname + '/public')); app.listen(3000); var options = { key: fs.readFileSync('keys/spdy-key.pem'), cert: fs.readFileSync('keys/spdy-cert.pem'), ca: fs.readFileSync('keys/spdy-csr.pem'), windowSize: 1024, // Server's window size }; app1.use(express.static(__dirname + '/public')); var server = spdy.createServer(options, app1); server.listen(3333); console.log("HTTP Server at PORT: 3000 and SPDY Server on 3333");
The client HTML Code (index.html)
<head> </head> <body> <table> <tr> <th>WITH SPDY</th> <th>NO SPDY</th> </tr> <tr> <td> <img src="https://loclhost:3333/images/galaxy.jpg" width="500"/> </td> <td> <img src="http://localhost:3000/images/galaxy.jpg" width="500"/> </td> </tr> </table> </body>
loading one file is not a good test, moron
That is absolutely correct. I should test with more data.
SPDY is all about reducing the number of concurrent TCP connections that frequently occur in a *real* web page where you’re downloading multiple resource files that with SPDY can use a single TCP socket. Using just one big file to download you will see little if any improvement.
Google Whiteaper
http://www.chromium.org/spdy/spdy-whitepaper
Simple overview
http://blog.nodejitsu.com/what-is-node-spdy
I have updated the post with results from the type of test you suggested. It was a good suggestion. Thanks.
@bonigv , man, tough crowd. Thanks for the post!
Thanks Boni for post! I used your code to perform another test with SPDY. I was trying to load 250 images in Single request(Index.html). Each image is unique. Test scenario is exactly similar as you mentioned. Observed that browser is requesting around 50 images at the same time(Awesome multiplexing!!). However on the HTTP channel, it was requesting only 6 images at a time. Found 30 to 50% consistent performance improvement over SPDY channel against HTTP.
Looks like NodeJS is having good implementation of Multiplexing Stream. However not the same story with Jetty9 Server. I have preform same test with Jetty9. Results were really disappointing. I’ll share ‘SPDY with Jetty9′ code and test results soon.