Speed of DoneCal API (over 1,400 request/sec) and HTTPS (less than 100 request/sec)

27 December 2010   4 comments   DoneCal

Mind That Age!

This blog post is 7 years old! Most likely, its content is outdated. Especially if it's technical.

Powered by Fusion×

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.


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


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.


See this new entry about enabling ssl_session_cache in Nginx


Chris Adams
HTTPS is considerably slower for time to first request because you have SSL session negotiation: if you test ab with and without -k you should see an enormous boost when reusing the same connection.

In practice this is fine as long as you have your SSL session cache configured (http://wiki.nginx.org/HttpSslModule#ssl_session_cache) since client browsers won't negotiate a new session every time. At that point you're left hoping everyone adopts some of the performance tweaks for avoiding extra round-trips (e.g. http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html) but it's usually manageable for non-realtime apps.
Peter Bengtsson
Thanks for the tip Chris! I'm reading up on it now.
Peter Bengtsson
Hi Chris,
Check out my update regarding ssl_session_cache
Chris Adams
Nice! Seeing that jump does make me wonder if the defaults should be changed, though, as it's pretty impressive for a one-liner.
Thank you for posting a comment

Your email will never ever be published

Related posts

To code or to pdb in Python 20 December 2010
ssl_session_cache in Nginx and the ab benchmark 31 December 2010
Github Pull Request Triage tool 06 March 2014
How much faster is Nginx+gunicorn than Apache+mod_wsgi? 22 March 2012
DoneCal homepage now able to do 10,000 requests/second 13 February 2011
ssl_session_cache in Nginx and the ab benchmark 31 December 2010
How I made my MongoDB based web app 10 times faster 21 October 2010
My tricks for using AsyncHTTPClient in Tornado 13 October 2010
Local Django development with Nginx 11 October 2010
Review: Django 1.1 Testing and Debugging 20 May 2010
To assert or assertEqual in Python unit testing 14 February 2009
WSSE Authentication and Apache 13 December 2007