librelist archives

« back to archive

load testing a websocket

load testing a websocket

From:
Josh Adams
Date:
2013-09-07 @ 13:38
Figured I'd take this discussion to its own thread, for ease of discovery
in archives and so we don't get confused discussion on the other 'main'
planning thread.

Alright, so did some digging (by which I mean i asked erlangers that I know
from NashFP) and here's what has come up so far in terms of the load
testing tools at our disposal:


   - Basho Bench -
   http://docs.basho.com/riak/latest/ops/building/benchmarking/
      - This doesn't support websockets out of the box.  You can write a
      new driver for it in around 200 lines of erlang.  Might be
interesting, but
      there's a better tool.  Figured I'd include this for completeness.
   - Tsung - http://tsung.erlang-projects.org/
      - This does support websocket load testing out of the box (the main
      feature list doesn't mention them, because they're newish - but
they're in
      the changelog from may on the homepage)
      - They claim to support opening hundreds of thousands of connections
      from a single box (or millions, if it's beefy enough)
      - It's erlang, so it's hella easy to distribute across multiple
      machines in case one machine can't saturate our app.
      - You can use it for system resource monitoring, which seemed
      slightly odd to me but ok.
      - You define a 'user type' in xml, and then you can spin up different
      numbers of different types of users.
      - html report generation during load testing to view response times,
      etc.

Once we've got some baseline number with a load test, then we would want to
optimize.  These are the tools I'm aware of at present:

   - concurix - http://concurix.com/
   - fprof - http://www.erlang.org/doc/man/fprof.html
      - Here's a writeup of using fprof to optimize a mysql driver -
      http://blog.process-one.net/optimizing-erlang-applications-emysql/
      - The OTP In Action book is supposed to have a good chapter on fprof,
      that might be more in depth than that writeup.  I've got it on my safari
      books online bookshelf.

Here's a diagram from OTP in Action that I thought was a pleasant
refinement of a performance tuning process. -
http://dl.dropbox.com/u/179045/Selection_001.png

Anyway, think this email has gotten long enough.  I'm planning on playing
with tsung in a minute.  I'll deploy our current codebase to
chromechat.isotopecloud.com (I'm using dokku to provide heroku-like
services on that domain btw) and load test it there.  It's a relatively
low-powered machine on digital ocean, but it's easy enough to ramp it up as
well.


-- 
*Josh Adams*
CTO | isotope|eleven <http://www.isotope11.com>
[cell] (205) 215-3957
[work] (877) 476-8671 x201