Erlang (or elixir) performance (requests per second) is slow vs jruby?

Question

Being a rubyist, I decided to take on erlang for high performance, reliable backend. The setup is quite simple: get a post request, write stuff to redis, return statistics. All json. this is also why I care so much about requests per second.

Tools of choice: webmachine, jiffy for json encoding/decoding, poolboy for connection pool, and eredis for redis communication.

Machine used: macbook pro, i5 2.4Ghz, 8GB memory.

My erlang got about 5000 requests per second, and the jruby/torqbox got about 12,0000. (look here for a complete ruby performance test setup)

I realize I could use ets in erlang to save time, and leave the redis for 'background processing' to be written after the response, but this will have little impact. even a simple test of 'hello world' erlang legs behind.

Any suggestions? Am I doing it wrong?

Answer 1

• Webmachine - I don't know. It is pretty heavy weight for mine taste and I don't use it.
• jiffy - Good choice. Pretty fast and I use it a lot.
• poolboy - I don't heard about it and I'm around Erlang for several years. I definitely would use cowboy for anything which I would expect high-performance or yaws for some more rock solid but still performing good. For your benchmark is cowboy right choice, it is top performance-wise.
• eredis - I don't know how mature and how it is efficient. ets is more appropriate for benchmark. For your macbook test it doesn't matter but for for big server (tens of CPUs) I would check if ti is not bottleneck and partition table.
• most importantly check your VM parameters. At least you should have +K true +A 100 for this kind of load.

Your result for Erlang seem simply too low compared to mine experience. You should get almost ten times bigger. There also can be problem with your payload generating tool.

And mostly important, this can be considered not only micro benchmark for Erlang world but may be nano or atto benchmark. The real strength will reveal when you will try something way harder and more complicated. Something where concurrent request should affect each other in very complicated way and you have to deal with eventual consistency and implement it much more scalable and need use asynchronous inter process communication.