A new release of heliod is available, version 0.3.
Pre-built binaries for a few platforms are available: https://github.com/jvirkki/heliod/releases/tag/v0.3
The main driver for this release is that I needed a 64 bit build for debian, as I’ve been meaning to upgrade my server for a long while but was held back by the lack of a 64 bit Linux build in 0.2.
It’s unfortunate to downgrade from mercurial to git but overall should be for the better.
I have moved the heliod source code from its previous home to github here: https://github.com/jvirkki/heliod
I also copied the release-0.2 binaries (built on debian-6, Solaris 10×86 and Solaris 10 SPARC) to the github release files: https://github.com/jvirkki/heliod/releases
If for some reason you want to download the release-0.1 binaries, they are still available on sourceforge here: http://sourceforge.net/projects/heliod/files/
The Internet is ablaze with talk about the OpenSSL vulnerability nicknamed Heartbleed (CVE-2014-0160). It is, arguably, one of the worst SSL vulnerabilities in recent memory given how trivial it is to exploit. Attackers can, without leaving any trace and with zero effort, read up to 64K of data from the server (or client) address space. What’s there will vary, but may, if you get (un)lucky include private keys, passwords or other sensitive info.
Of course, it is not an SSL protocol vulnerability. It is a bug in the OpenSSL implementation. Those of you (us) running the heliod web server have had nothing to do this week since heliod fortunately does not use OpenSSL (it uses NSS). It is a relief, after running around at work to address the Heartbleed vulnerability, that I don’t have to do anything to fix my personal web servers which wisely run heliod!
If you’d also like to run the best performing and most secure web server around, check out heliod.
In my previous article I covered the benchmark results from static file testing of various web servers. One interesting observation was how much difference there was in CPU consumption even between servers delivering roughly comparable results. For example, nginx, apache-worker and cherokee delivered similar throughput with 10 concurrent clients but apache-worker just about saturated the CPU while doing so, unlike the other two.
I figured it would be interesting to look at the efficiency of each of these servers by computing throughput per percentage of CPU capacity consumed. Here is the resulting graph:
In terms of raw throughput apache-worker came in third place but here it does not do well at all because, as mentioned, it maxed out the CPU to deliver its numbers. Cherokee, previously fourth, also drops down in ranking when considering efficiency since it also used a fair amount of CPU.
The largest surprise here is varnish which performed very well (second place) in raw throughput. While it was almost able to match heliod, it did consume quite a bit more CPU capacity to do so which results in relatively low efficiency numbers seen here.
Lighttpd and nginx do well here in terms of efficiency – while their absolute throughput wasn’t as high, they also did not consume much CPU. (Keep in mind these baseline runs were done with a default configuration, so nginx was only running one worker process.)
I’m pleasantly surprised that heliod came on top once again. Not only did it sustain the highest throughput, turns out it also did it more efficiently than any of the other web servers! Nice!
Now, does this CPU efficiency index really matter at all in real usage? Depends…
If you have dedicated web server hardware then not so much. If all the CPU is doing is running the web server then might as well fully utilize it for that. Although there should still be some benefit from a more efficient server in terms of lower power consumption and lower heat output.
However, if you’re running on virtual instances (whether your own or on a cloud provider) where the physical CPUs are shared then there are clear benefits to efficiency. Either to reduce CPU consumption charges or just to free up more CPU cycles to the other instances running on the same hardware.
Or… you could just use heliod in which case you don’t need to choose between throughput vs. efficiency given that heliod produced both the highest throughput (in this benchmark scenario anyway) and the highest efficiency ranking.
If you were to look at the HTTP response headers from this site, you’d see it is being handled by:
Server: heliod-web-server/0.1
Which is a web server you’ve probably never heard of before… Or I should say, you most likely have, but with various different names.
Way back when, this was the Netscape Enterprise Server. Which later became iPlanet Web Server (during the Sun|Netscape alliance). Under Sun alone, it was renamed several times to SunONE Web Server and Sun Java System Web Server (and maybe some other name variants I forget now). Naming nonsense aside, it’s been the same evolving code base all along, best known for high performance and even higher scalability.
Thankfully, Sun open sourced the code in 2009 under the BSD license. Most of it, anyway. Unfortunately a few parts were left out, mainly the administration support, installer and the embedded Java servlet engine. The open source code was kept in sync with the commercial releases until January 2010 (7.0 update 8, using the commercial release version numbering). After that, the open source repository has not seen any activity (not coincidentally, January 2010 was also when Oracle acquired Sun, so this is not surprising).
Surprisingly, the source repository is still available:
hg clone ssh://anon@hg.opensolaris.org/hg/webstack/webserver
The source as published can be tricky to build and it does not produce an installable package. When I was setting up this site last year I ended up forking this code into http://sourceforge.net/projects/heliod/. The code is the same but I added a rudimentary install script to make it easier to get going. You can download binaries for Solaris (x86) and Linux from the sourceforge page so you don’t have to build it yourself if you prefer not to.
(Update: The source is now in github here: https://github.com/jvirkki/heliod)