7 ms·

We've moved all of our backend offerings from Rails to Elixir/Phoenix. Despite some questioning the value of anything below 100ms response times there is a lot

We've moved all of our backend offerings from Rails to Elixir/Phoenix. Despite some questioning the value of anything below 100ms response times there is a lot of data backing up the idea that Elixir/Phoenix can lead to a more maintainable and more economical solution. I spoke about this recently at RailsConf: https://www.youtube.com/watch?v=OxhTQdcieQE https://www.youtube.com/watch?v=OxhTQdcieQE Don't get me wrong, I think Rails is an amazing technology but it doesn't fit the use cases and demands our clients have today.

davidw 10y ago
> more maintainable I get that the Erlang VM is really nice for some things (I made my first contribution to it in 2004!), but I'm curious about the above statement, as I haven't had the time to dig into Elixir/Phoenix yet.
- dmix 10y ago
  I find working with functional languages and type systems (w/ dialyzer in this case) makes my projects more maintainable in general. Might just be a personal bias towards them though. Note: I haven't used Phoenix but I'm a fan of Erlang.
- rozap 10y ago
  I think most folks are finding that distribution in an erlang based application is a lot simpler, because you don't need to pull in things like redis for pubsub, memcached for caching, etc etc. erlang solves a bunch of problems in a rather elegant way that are solved in the java/python/ruby world through gobs of duct tape.
  - davidw 10y ago
    Good point, but I'd see the actual codebase on a single node as the most important thing for most people. Even with Rails you can do a lot with one server.
  - Scarbutt 10y ago
    Performance wise, I wouldn't put Java next to ruby and python, in what workload would the erlang vm beat the jvm?
    - rozap 10y ago
      I'm talking more about concurrency and distribution models, not raw performance.
    - felixgallo 10y ago
      low jitter, low latency, high concurrency workloads.
- bcardarella 10y ago
  This is mostly an observation I've had of imperative programming vs functional programming. Going back and creating the state of the application in my head is easier when I don't have to find out what else the code is affecting.
- bratsche 10y ago
  I'm still fairly new with Elixir/Phoenix (as I think most of us still are), but so far I feel intuitively that it's more maintainable and I admit that I don't have the experience or numbers to back that up yet. There are some things that you simply must use other tools for in Rails, because it can't maintain state like Erlang can. Once you start adding in these other things, you're no longer just a "Rails app" but you're really creating an entire system. Now you've got different things you potentially need to test, and you're adding in extra stuff to your system to monitor and measure the different parts of your system. You might do the same thing in Erlang/Elixir, but you also might not. You can potentially keep your entire "system" inside Erlang, either in one node or distributed. So right away simply having that option sounds like a huge improvement in maintainability. You've got everything running in Erlang, monitored and supervised in Erlang/Elixir, more easily testable using ExUnit or whatever. And I think @bcardella talked about this in his RailsConf presentation (linked somewhere in the comments here).. but the performance you get from Elixir/Phoenix is potentially a huge improvement in maintenance. How much time have people spent in NewRelic or whatever measuring and tuning their Rails apps, getting the caching and everything working just right? People are writing Phoenix apps with zero caching that are performing better than Rails with caching. When people aren't having to go debug and diagnose these kinds of performance problems they get to work on actual features. Again, some of this is just my intuition on it more than real experience to back it up. I've built a couple apps with Phoenix and I do enjoy it more. They're not big enough for the performance to really matter, but I do feel strongly that they're simpler because I'm keeping everything in Elixir code and not having to use, for example, Sidekiq in order to do anything async.
  - davidw 10y ago
    I would love to see someone take a deep dive into why their Phoenix thing is "so much faster" than with Rails. I mean really look at the whole stack from the VM, to different pieces of the framework like views and DB interaction. Erlang definitely does concurrency well, but it is not that much faster than Ruby in terms of "raw speed". I'd be fascinated to see someone actually do the work and look at where Phoenix is eking out those gains.
    - 10y ago
hartator 10y ago
I have tried it only once, what do you think about the management of web sockets compared to the new Rails cable?
matthewrudy 10y ago
I think performance is compelling, But the bigger win is concurrency. We run 100s of dynos for our service, but could probably run just a couple if we moved to elixir/otp.
bdcravens 10y ago
Every time I've explored alternatives to try to get those kinds of numbers, it seem the bottleneck is more in the database than the application server.
- rjbwork 10y ago
  A lot of super scalable apps don't necessarily use a "database". They use a heterogeneous set of data stores that are most appropriate for their particular use case. Or maybe they shard, or run a distributed cluster, etc.
- nirvdrum 10y ago
  How granular are your measurements? I'm certainly not calling your experience into question. But I wanted to relay a cautionary tale of my own. On one project my team was convinced that Redis was our bottleneck. Profiling was showing that Redis calls were where the most time was spent. I spent some time looking at the redis-rb source and it does a lot of block nesting (4 or 5 levels for every call, IIRC). So, I tried replacing the redis-rb client with something a bit lower level and our throughput doubled. It turned out that all that block processing cost as much as the network call did. I suppose this isn't all that new: many performance issues are really a "death by 1,000 cuts" situation. Oftentimes your profiler can lead you astray.
  - ShaneOG 10y ago
    What did you replace redis-rb with, if you don't mind me asking?
    - nirvdrum 10y ago
      In this case we first moved to JRuby (after verifying a similar performance profile to MRI) and once on JRuby we used jedis [1]. I simplified the tale a bit -- apologies if I got your hopes up on MRI. [1] -- https://github.com/xetorthio/jedis https://github.com/xetorthio/jedis
  - eric_h 10y ago
    The performance problems I've had with redis-rb were largely due to my accidentally using it in an improper environment (an event machine based asynchronous service). Replacing it with em-hiredis (and refactoring to use callbacks) drastically improved throughput for us. In situations where a blocking redis client like redis-rb doesn't interfere with other running code (synchronous web requests), I've found zero performance issues with redis-rb (latency caused by redis is measured in single digits, usually < 5ms).
deleted 10y ago
[deleted]
KurtMueller 10y ago
This is the equivalent to Kanye interrupting Swift: "Rails, Imma let you finish, but Elixir/Phoenix is really where it's at right now."

davidw 10y ago

> more maintainable I get that the Erlang VM is really nice for some things (I made my first contribution to it in 2004!), but I'm curious about the above statement, as I haven't had the time to dig into Elixir/Phoenix yet.

dmix 10y ago
I find working with functional languages and type systems (w/ dialyzer in this case) makes my projects more maintainable in general. Might just be a personal bias towards them though. Note: I haven't used Phoenix but I'm a fan of Erlang.
rozap 10y ago
I think most folks are finding that distribution in an erlang based application is a lot simpler, because you don't need to pull in things like redis for pubsub, memcached for caching, etc etc. erlang solves a bunch of problems in a rather elegant way that are solved in the java/python/ruby world through gobs of duct tape.
- davidw 10y ago
  Good point, but I'd see the actual codebase on a single node as the most important thing for most people. Even with Rails you can do a lot with one server.
- Scarbutt 10y ago
  Performance wise, I wouldn't put Java next to ruby and python, in what workload would the erlang vm beat the jvm?
  - rozap 10y ago
    I'm talking more about concurrency and distribution models, not raw performance.
  - felixgallo 10y ago
    low jitter, low latency, high concurrency workloads.
bcardarella 10y ago
This is mostly an observation I've had of imperative programming vs functional programming. Going back and creating the state of the application in my head is easier when I don't have to find out what else the code is affecting.
bratsche 10y ago
I'm still fairly new with Elixir/Phoenix (as I think most of us still are), but so far I feel intuitively that it's more maintainable and I admit that I don't have the experience or numbers to back that up yet. There are some things that you simply must use other tools for in Rails, because it can't maintain state like Erlang can. Once you start adding in these other things, you're no longer just a "Rails app" but you're really creating an entire system. Now you've got different things you potentially need to test, and you're adding in extra stuff to your system to monitor and measure the different parts of your system. You might do the same thing in Erlang/Elixir, but you also might not. You can potentially keep your entire "system" inside Erlang, either in one node or distributed. So right away simply having that option sounds like a huge improvement in maintainability. You've got everything running in Erlang, monitored and supervised in Erlang/Elixir, more easily testable using ExUnit or whatever. And I think @bcardella talked about this in his RailsConf presentation (linked somewhere in the comments here).. but the performance you get from Elixir/Phoenix is potentially a huge improvement in maintenance. How much time have people spent in NewRelic or whatever measuring and tuning their Rails apps, getting the caching and everything working just right? People are writing Phoenix apps with zero caching that are performing better than Rails with caching. When people aren't having to go debug and diagnose these kinds of performance problems they get to work on actual features. Again, some of this is just my intuition on it more than real experience to back it up. I've built a couple apps with Phoenix and I do enjoy it more. They're not big enough for the performance to really matter, but I do feel strongly that they're simpler because I'm keeping everything in Elixir code and not having to use, for example, Sidekiq in order to do anything async.
- davidw 10y ago
  I would love to see someone take a deep dive into why their Phoenix thing is "so much faster" than with Rails. I mean really look at the whole stack from the VM, to different pieces of the framework like views and DB interaction. Erlang definitely does concurrency well, but it is not that much faster than Ruby in terms of "raw speed". I'd be fascinated to see someone actually do the work and look at where Phoenix is eking out those gains.
  - 10y ago

hartator 10y ago

I have tried it only once, what do you think about the management of web sockets compared to the new Rails cable?

matthewrudy 10y ago

I think performance is compelling, But the bigger win is concurrency. We run 100s of dynos for our service, but could probably run just a couple if we moved to elixir/otp.

bdcravens 10y ago

Every time I've explored alternatives to try to get those kinds of numbers, it seem the bottleneck is more in the database than the application server.

rjbwork 10y ago
A lot of super scalable apps don't necessarily use a "database". They use a heterogeneous set of data stores that are most appropriate for their particular use case. Or maybe they shard, or run a distributed cluster, etc.
nirvdrum 10y ago
How granular are your measurements? I'm certainly not calling your experience into question. But I wanted to relay a cautionary tale of my own. On one project my team was convinced that Redis was our bottleneck. Profiling was showing that Redis calls were where the most time was spent. I spent some time looking at the redis-rb source and it does a lot of block nesting (4 or 5 levels for every call, IIRC). So, I tried replacing the redis-rb client with something a bit lower level and our throughput doubled. It turned out that all that block processing cost as much as the network call did. I suppose this isn't all that new: many performance issues are really a "death by 1,000 cuts" situation. Oftentimes your profiler can lead you astray.
- ShaneOG 10y ago
  What did you replace redis-rb with, if you don't mind me asking?
  - nirvdrum 10y ago
    In this case we first moved to JRuby (after verifying a similar performance profile to MRI) and once on JRuby we used jedis [1]. I simplified the tale a bit -- apologies if I got your hopes up on MRI. [1] -- https://github.com/xetorthio/jedis https://github.com/xetorthio/jedis
- eric_h 10y ago
  The performance problems I've had with redis-rb were largely due to my accidentally using it in an improper environment (an event machine based asynchronous service). Replacing it with em-hiredis (and refactoring to use callbacks) drastically improved throughput for us. In situations where a blocking redis client like redis-rb doesn't interfere with other running code (synchronous web requests), I've found zero performance issues with redis-rb (latency caused by redis is measured in single digits, usually < 5ms).

deleted 10y ago

[deleted]

KurtMueller 10y ago

This is the equivalent to Kanye interrupting Swift: "Rails, Imma let you finish, but Elixir/Phoenix is really where it's at right now."