Peterbe.com

I've done some work refactoring the homepage of DoneCal so that it does no logic other than just serving HTML. What it used to do was some basic security checks and stuff so that it says "Hi Peter" and a log out link. Now all of that has been moved to one simple piece of AJAX call.

BEFORE:

# ab -n 1000 -c 10 http://donecal.com/
...
Requests per second:    353.65 [#/sec] (mean)

AFTER:

# ab -n 1000 -c 10 http://donecal.com/
...
Requests per second:    9796.78 [#/sec] (mean)

# ab -n 1000 -c 10 http://donecal.com/auth/logged_in.json
...
Requests per second:    3756.25 [#/sec] (mean)

The reason why loading the index.html can be so fast is because I'm using Nginx directly. In my Nginx config I have to not use the static file if the request isn't a GET request or if it has a query string. I'll need to remove that stuff too and then it means that I can push the index.html file out to my AWS CloudFront CDN using a CNAME.

DoneCal is my first web application that is this Javascript heavy. It raises the bar in terms of optimal HTTP optimization to get the best user experience possible. I love learning this new way of working.

Here's a nice write up about DoneCal on MumbaiMirror

"All in all, DoneCal is one of those Web 2.0 tools that you wouldn’t really miss if it wasn’t around, but once you use it, you can’t go back."

They don't make a link to DoneCal which I suspect is some sort of half assed attempt to avoid too many outgoing links. They've strangely spent time writing about another web page but can't make a link to it. If I've learned anything from Google is that the ultimate mantra of SEO is: don't try to be smarter than us, just write great content and let us worry about ranking.

If these guys are worried about that, why don't they use a rel="nofollowup" attribute on the link?

For the first time in my life I've launched a web site/app that isn't mostly popular in the United States. Yay!(?) Not that I care or that it matters but it's worth noting. For some reason it's currently most popular in France, followed closely by China and United States is not till the 5th place.

Of the United States visitors I'm not surprised the California bunch is more prominent. The service is quite new and quite technically interesting for people in the industry so I guess a lot of those visitors are Silicon Valley type folks.

A couple of days ago I wrote about how blazing fast the DoneCal API can be on HTTP (1,400 requests/second) and how much slower it becomes when doing the same benchmark over HTTPS. It was, as Chris Adams pointed out, possible to run ab with Keep-Alive on and after some reading up it's clear that it's a good idea to switch on shared ssl_session_cache so that Nginx's SSL TCP traffic can cache some handshakes.

With ssl_session_cache shared:SSL:10m :

 Requests per second:    112.14 [#/sec] (mean)

Same cache size but with -k on the ab loadtest:

Requests per second:    906.44 [#/sec] (mean)

I'm fairly sure that most browsers with use Keep-Alive connections so I guess it's realistic to use -k when running ab but since this is a test of an API it's perhaps more likely than not that clients (i.e. computer programs) don't use it. To be honest I'm not really sure but it never the less feels right to be able to use ssl_session_cache to boost my benchmark by 40%.

It's also worth noticing that when doing a HTTP benchmark it's CPU bound on the Tornado (Python) processes (I use 4). But when doing HTTPS it's CPU bound on the Nginx itself (I use 1 worker process).

DoneCal (my simple calendar and time sheet substitute web app) now has HTTPS support. It's not enabled yet as I'm ironing out some more testing. Basically, HTTPS is, at least at the moment, only going be available to premium users. Anyway, this is a performance story and about the difference in speed between HTTP and HTTPS.

I'll let these unscientific benchmarks speak for themselves.

HTTP:

donecal:~# ab -n 1000 -c 10 "http://donecal.com/api/events.json?guid=xxx&start=1292999600&end=1293294812"
...
Document Length:        616 bytes
Failed requests:        0
...
Requests per second:    1432.40 [#/sec] (mean)
...
Transfer rate:          1184.81 [Kbytes/sec] received

HTTPS:

..
Server Port:            443
SSL/TLS Protocol:       TLSv1/SSLv3,DHE-RSA-AES256-SHA,2048,256

...
Document Length:        616 bytes
Failed requests:        0
...
Requests per second:    84.73 [#/sec] (mean)
...
Transfer rate:          70.08 [Kbytes/sec] received

That's quite a huge difference in requests per second. HTTPS 17 times slower than HTTP. Is this the reality of HTTPS? Or something wrong with my cert or something wrong with running HTTPS through ab?

Anyway, this pretty good me thinks anyway. The HTTP version is over 1,400 requests per second and this is a fully database, security and encoding involving application. This particular test data (616 bytes JSON) isn't big but it sure is bigger than some of the "'hello world'" benchmarks you see on the interweb.

UPDATE

See this new entry about enabling ssl_session_cache in Nginx

I've finally had the time to write a little bit about my latest web app project: DoneCal.

Hopefully the banner at the top of this page will yield a bit of traffic. Since my marketing budget for DoneCal is exactly $0.00 I'm going to try to go for nice organic SEO and just generally build a great app so that people don't have to link to it but that they want to link to it.

Let me know if the text makes sense or if it makes you feel confused about what DoneCal is.

All the hard work I've put into DoneCal pre-optimization has paid off: Got a Grade A with 92 percent on YSlow!

What's cool about this is that unlike other sites I've built with high YSlow score this site is very Javascript intense and rendering the home page depends on 9 different Javascript files weighing over 300 Kb which when combined and packed for production use is reduced down to 5 requests and weighing in just over 80Kb. The reason it's still 5 and not just 1 is also important. This is deliberate since it only loads the minimum first to render the calendar and then after the DOM is fully rendered more Javascript is pulled in depending on what's needed.

One annoying thing about YSlow is that it suggests that you use CDNs for Javascript and CSS files. What they perhaps don't appreciate is that most CDNs don't support negotiated gzipping like Nginx does. The ability to gzip is a CSS or Javascript file generally means less waiting for the client than getting it un-gzipped from a CDN. One thing I will work on though is perhaps serving all the images that support the CSS from my Amazon Cloudfront CDN. Gzipping is not applicable to images.