Steve Vinoski's Blog

My latest Internet Computing column, Server-Sent Events with Yaws (PDF), is now available. It discusses the fact that developers are increasingly building Web applications that rely on notifications from the server, such as updates from social networks, alerts from application monitors, or information from sensor networks. But given that HTTP is a request-response protocol, such notifications can be challenging, giving rise to techniques such as long polling and to entirely new protocols such as WebSocket. These challenges can be especially significant for mobile applications due to intermittent client connectivity and device battery-life issues. This column explores how the Yaws Web server, written in the Erlang programming language, supports the W3C Server-Sent Events notification approach.

I’m looking forward to speaking about Erlang/OTP in the “Functional Programming Everywhere” track and also running the “Concurrency in the Large” track at QCon NYC, June 18-22. If you register using code VINO100 you’ll get $100 off your registration fee and the conference will donate $100 to a New York educational charity.

See you there!

For the “Functional Web” column in the Jan/Feb 2012 issue of Internet Computing, I wrote about Wriaki, an Erlang sample application my Basho colleague Bryan Fink wrote that implements a wiki on top of Webmachine and Riak. Wriaki is a nice, clean, and easy to understand example of how to write Webmachine applications. Here’s the PDF.

The July/August 2011 issue of Internet Computing is out, and this time my column (pdf) covers the Erlang Yaws web server. Since Yaws has too many features to detail in just one column, I wrote it as an introductory piece, covering only those features that are most commonly used.

You might also take a look at my slides from my “A Decade of Yaws” talk (pdf) from Erlang Factory London 2011.

In my previous blog entry I questioned the value of most web server benchmarking, particularly as related to Erlang. Typical benchmarks are misleading, inaccurate, and poorly executed. Perhaps worse, the intent of publishing them seems to be to assert that the fastest web server (at least according to the tests performed) is of course also the best web server. You’d think the flaws of this fallacy would be so obvious that nobody would fall for it, but think again: watching the delicious “erlang” tag over the past few days revealed the benchmarks my blog post referred to to be one of the most bookmarked Erlang-related pages during that timeframe.

Not surprisingly, though, it looks like I’m not the only one bothered by poor benchmarking practices. Over on his blog, Mark Nottingham just published a brilliant set of rules for HTTP load testing. It’s quite instructive to take your favorite set of published web server benchmarks and see just how many of Mark’s rules they violate.

Like I hinted last time, if you want benchmarks, you are best off by far if you run them yourself. That way, their relevance to the problems you’re addressing will be much more likely, and you can run them in a similar, or even the same, environment on which you plan to deploy. You can also gear the benchmarks to much more closely resemble your applications and the loads you require them to handle. Doing the benchmarking work yourself will give you valuable hands-on experience with the servers and frameworks you’re considering, allowing you to get a feel for important factors such as feature completeness and correctness, ease of development, flexibility, and ease of deployment and runtime management/monitoring, none of which can be gauged by someone else’s performance benchmarks. Finally, by doing your own benchmarking you can also help ensure the validity and usefulness of your results by following Mark’s load testing rules.