Just over two weeks ago, Heroku announced (the long-awaited) experimental support for WebSockets. Just like you would expect from Heroku, getting set up is painless and there's good documentation and good sample code to help you.
I was curious to see what kind of performance one could expect, so I did a quick performance test to find out. (I used Heavy Artillery to generate the load)
For comparison, an entry-level box from Digital Ocean (512MB RAM, Ubuntu 13.10) can handle 350+ new connections/sec, and seems to max out at around 7,200 open connections.
Here is the code for the server:
As you can see, it does nothing apart from accepting connections.
The client sessions were very simple: connect and do nothing until disconnected by the server.
Draw your own conclusions whether the numbers above are good or not.
I ran 7 tests in total.
The first one created 1000 connections/second for 30 seconds - that obviously didn't go well. The other 5 were me doing a binary search to find the number of connections/second one could make without seeing H11 errors pop up. I got bored between 160 (okay) and 175 (H11's start popping up).
I will be updating this post with more numbers as I run more benchmarks. Scaling WebSocket-based apps is a subject dear to my heart.
I presented at ScotlandJS last Friday on Heyso's Node.js/Sockjs/Redis-based backend and load-testing properly (i.e. not by
curling the same URL in a loop or sending the same WebSocket message over and over)
I am not publishing the slides since they won't make much sense on their own, but I'm hoping to publish a series of blog posts on topics covered in my talk, SOON.
Thank god for Red Bull - it just wouldn't've happened without it.
Sometimes you just don't have the time to do things properly. For a side project I'm hacking on, my deployment process is this:
ssh into the server
And that's it (Mochiweb's
reloader reloads the code on the fly).
Erlang is running under
screen so I can always poke around in the shell and do some good old printf debugging when I need to.
It works well and will serve me fine until I know I need to make it more robust.
Slides from my talk at Edinburgh Techmeetup.
and a photo:
The code is on Github: Music Hipster.
Here goes my 4th attempt at keeping a blog. Posts from Posterous to be moved when I can be bothered. I have also salvaged two posts that might be of interest to someone from my previous Jekyll blog.
This would also mean that:
Common Lisp is not going to get mainstream for three reasons:
PLT Scheme is not a contender either, because it’s perceived as little more than a Lisp for teaching, which isn’t true, but the community isn’t doing much to shatter this perception.
Update discussion over at Hacker News
Erlang is not a functional programming language.
Erlang is a language that makes it easier to write fault-tolerant applications. (And OTP is the platform that makes it even easier, but not “easy” of course.)
From day one, the goal of the project that resulted in Erlang as we know it today was to come up with something that made it cheaper and faster to develop telephony systems — ATM switches and the like. There was a lot of tinkering, rewriting, and questioning everything — even the most basic of assumptions. There was a solid business requirement, which the Erlang team at Ericsson’s CS Lab understood well. They were experienced hackers, with expertise in Prolog, C, Lisp and other programming languages. They were also experienced in building fault-tolerant systems, and ruthlessly pragmatic. It was simple: if something helped them get closer to their objective, it went into the language. If it didn’t, it got thrown out.
It turned out that discouraging mutable state brought the language closer to the goal. Cheap lightweight isolated processes at the core of the language did too. Currying, algebraic data types and many other features didn’t.
Erlang is highly pragmatic, and this seems to get overlooked by many newcomers to the language. It may be considered functional, and it may also be considered object-oriented, but that does not really matter. (Some people also call it concurrency-oriented, which is my favorite classification of Erlang.)
This paper helps understand Erlang better. It sheds light on why Erlang is the way it is, and explains why it’s by far the best choice for solving certain problems.