### UPDATE ###
After more tests and a closer look at the ApacheBench sources, we now know that this problem stems from a race condition in ApacheBench.
### END UPDATE ###
While doing my AWS vs node.js test I stumbled on a somewhat weird issue: Sometimes AWS returned too many bytes.
I reported this to the AWS authors, who came back with this response:
This looks very very bad and does not correspond to any experience I have had with AWS. I’m really concerned by these results. How does your AWS server look like?
Luckily I’d tested this using both my homegrown AWS powered web-framework, and the demos/hello_world example from the AWS source package. Both exhibit the same behavior.
I did some more tests, this time using both 32 and 64 bit systems, and I even threw in a virtualized Slackware (VirtualBox 3.2.12) for completeness. I then reported back to the AWS maillist.
This is a very odd issue indeed, and I truly hope the AWS developers can figure out the what and why, but until that happens, I’ll soldier on. AWS is no less of a marvelous piece of software because of this minor glitch.
As some of you might be aware of, I’m in the process of moving all my PHP/XSLT code to Ada/AWS. The is a huge project that not only entails porting several 100KLOC to Ada, but it also means I have to learn to use AWS to its fullest.
So far that has been a mostly pleasant experience. AWS is a very nice piece of software.
But then yesterday I read this on the AWS mailing list:
This was written by Emmanuel Briot as a reply to a post where I had presented some early benchmarks of an AWS setup. In his post he showed that a node.js HTTP server was _faster_ than AWS.
Naturally I could not let that one sit unchallenged, so I grabbed myself a copy of node.js (both 0.2.6 and 0.3.6) and set out to do my own comparison.
The results of that little adventure can be found here, and I’m pleased to say that order has been restored to the universe. 🙂