4 ms·

What’s been your experience with Live View? I ask because I’m under the impression that using it comes with some sizable scaling problems, which somewhat defea

What’s been your experience with Live View? I ask because I’m under the impression that using it comes with some sizable scaling problems, which somewhat defeats the point of using Erlang in the first place. I could be wrong though. Would like to learn more.

eclark 4y ago
LiveView has been pretty great. Mostly it's just a couple of `handle_event` methods away and we have a fully reactive UI. I haven't seen any scaling issues for LiveView. Under the hood there's a websocket that push and pull events from a running GenServer for each session. Since each process is independent it's horizontally scalable as long as your able to route websockets to the same process in a cluster. While not the same, I do know that single machine has been able to scale to a couple of million connections ( https://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections https://www.phoenixframework.org/blog/the-road-to-2-million-... ) with phoenix channels. Which are harder to scale than independent live views. Also our use case is for smaller scale than that (Not too many companies have a million people looking at their ml deploy pipelines) so I haven't been too worried.
- tiffanyh 4y ago
  @chrismccord If you’re reading this, would be super interesting to update this 7-year-old benchmark to use Live View (and the latest stack). Thanks for all you do btw.
  - h0l0cube 4y ago
    Could even switch over to Bandit which was on a recent Thinking Elixir podcast > In recent performance tests, Bandit's HTTP/1.x engine is up to 5x faster than Cowboy depending on the number of concurrent requests. When comparing HTTP/2 performance, Bandit is up to 2.3x faster than Cowboy https://github.com/mtrudel/bandit https://github.com/mtrudel/bandit
    - tiffanyh 4y ago
      That’s a great point and Phoenix 1.7 is the first release to support the usage of other web servers. 2-5x speed up would make Erlang surprise Java/Go/etc. https://stressgrid.com/blog/webserver_benchmark/ https://stressgrid.com/blog/webserver_benchmark/
      - h0l0cube 4y ago
        Bandit is written in pure Elixir which is a bit undesirable to integrate with pure Erlang projects. From what I gleaned off the podcast, it's a subset of the HTTP features available in Cowboy, specifically those that are available on the Phoenix side, and cleaving off the unused functionality realized much of the performance benefit.
        mcmatterson 4y ago
        Bandit author here. Correct! The byline of Bandit is ‘a web server for Plug applications’ and being able to focus on that narrowed set of requirements is a large part of where the perf boost comes from (less code, easier to reason about, fewer processes, etc).
    - eclark 4y ago
      I don't think that 1.7 is going to really have bandit fully supported on launch: https://github.com/phoenixframework/phoenix/pull/5071 https://github.com/phoenixframework/phoenix/pull/5071 Once it is supported though, I will be on that for sure.
      - mcmatterson 4y ago
        Bandit author here. We’re fully supported on phx 1.7+; it’s a one line change to your existing app, described on the Bandit readme!
      - mcmatterson 4y ago
        The PR you linked to adds support for generating new phx apps with the relevant change already incorporated; it’s just a generator change. We’re waiting a bit to incorporate this change to ‘soft launch’ Bandit support.
hn92726819 4y ago
> I’m under the impression that using it comes with some sizable scaling problems Interesting. I have the exact opposite impression (I'm not experienced in live view; only written 2 small utilities). Erlang (therefore elixir) is fundamentally distributed, so as you mentioned, it would defeat the purpose. So why gives you that impression? LiveView is just a smart/reactive socket built on Phoenix that behaves just like any other elixir process right? Why would it specifically have scaling issues?
josevalim 4y ago
Each LiveView requires a persistent WebSocket connection to the server. This means it does have a different scaling profile than the usual request/response lifecycle, but the Erlang VM is greatly capable of holding millions of connections at the same time and therefore is a perfect fit for the LiveView model. In fact, LiveView is built on top of the same Phoenix Channels we used to achieve 1 million connections on a single server. So I would say that LiveView fully leverages the Erlang VM strengths. :)
- tiffanyh 4y ago
  Thank you Jose for all you do, create and how you help developers around the world.
- dmix 4y ago
  What situations would face possible issues with the persistent-socket-per-view approach? A sprawling app with hundreds of distinct views that over-use LiveView? Would there also be multiple persistent sockets for each particular page? I can't imagine the type of site that would need that sort of structure. Typically you'd have your highly-interactive primary subset of your app, about <10-25% of the routes/views which gets 75-90% of your traffic. While the other 75%+ of routes are just simple static-y/REST CRUD/server-rendered pages.
  - brightball 4y ago
    In a situation where you hit the scaling limitations of the BEAM, you’re going to have the budget to address it.
  - TylerE 4y ago
    IIRC (don’t claim to be an expert) the main issue is gracefully handling the case where the server end goes away unexpectedly - network issues, reboots, that kind of thing.
    - dmix 4y ago
      Does that include deploys?

eclark 4y ago

LiveView has been pretty great. Mostly it's just a couple of `handle_event` methods away and we have a fully reactive UI. I haven't seen any scaling issues for LiveView. Under the hood there's a websocket that push and pull events from a running GenServer for each session. Since each process is independent it's horizontally scalable as long as your able to route websockets to the same process in a cluster. While not the same, I do know that single machine has been able to scale to a couple of million connections ( https://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections https://www.phoenixframework.org/blog/the-road-to-2-million-... ) with phoenix channels. Which are harder to scale than independent live views. Also our use case is for smaller scale than that (Not too many companies have a million people looking at their ml deploy pipelines) so I haven't been too worried.

tiffanyh 4y ago
@chrismccord If you’re reading this, would be super interesting to update this 7-year-old benchmark to use Live View (and the latest stack). Thanks for all you do btw.
- h0l0cube 4y ago
  Could even switch over to Bandit which was on a recent Thinking Elixir podcast > In recent performance tests, Bandit's HTTP/1.x engine is up to 5x faster than Cowboy depending on the number of concurrent requests. When comparing HTTP/2 performance, Bandit is up to 2.3x faster than Cowboy https://github.com/mtrudel/bandit https://github.com/mtrudel/bandit
  - tiffanyh 4y ago
    That’s a great point and Phoenix 1.7 is the first release to support the usage of other web servers. 2-5x speed up would make Erlang surprise Java/Go/etc. https://stressgrid.com/blog/webserver_benchmark/ https://stressgrid.com/blog/webserver_benchmark/
    - h0l0cube 4y ago
      Bandit is written in pure Elixir which is a bit undesirable to integrate with pure Erlang projects. From what I gleaned off the podcast, it's a subset of the HTTP features available in Cowboy, specifically those that are available on the Phoenix side, and cleaving off the unused functionality realized much of the performance benefit.
      - mcmatterson 4y ago
        Bandit author here. Correct! The byline of Bandit is ‘a web server for Plug applications’ and being able to focus on that narrowed set of requirements is a large part of where the perf boost comes from (less code, easier to reason about, fewer processes, etc).
  - eclark 4y ago
    I don't think that 1.7 is going to really have bandit fully supported on launch: https://github.com/phoenixframework/phoenix/pull/5071 https://github.com/phoenixframework/phoenix/pull/5071 Once it is supported though, I will be on that for sure.
    - mcmatterson 4y ago
      Bandit author here. We’re fully supported on phx 1.7+; it’s a one line change to your existing app, described on the Bandit readme!
    - mcmatterson 4y ago
      The PR you linked to adds support for generating new phx apps with the relevant change already incorporated; it’s just a generator change. We’re waiting a bit to incorporate this change to ‘soft launch’ Bandit support.

hn92726819 4y ago

> I’m under the impression that using it comes with some sizable scaling problems Interesting. I have the exact opposite impression (I'm not experienced in live view; only written 2 small utilities). Erlang (therefore elixir) is fundamentally distributed, so as you mentioned, it would defeat the purpose. So why gives you that impression? LiveView is just a smart/reactive socket built on Phoenix that behaves just like any other elixir process right? Why would it specifically have scaling issues?

josevalim 4y ago

Each LiveView requires a persistent WebSocket connection to the server. This means it does have a different scaling profile than the usual request/response lifecycle, but the Erlang VM is greatly capable of holding millions of connections at the same time and therefore is a perfect fit for the LiveView model. In fact, LiveView is built on top of the same Phoenix Channels we used to achieve 1 million connections on a single server. So I would say that LiveView fully leverages the Erlang VM strengths. :)

tiffanyh 4y ago
Thank you Jose for all you do, create and how you help developers around the world.
dmix 4y ago
What situations would face possible issues with the persistent-socket-per-view approach? A sprawling app with hundreds of distinct views that over-use LiveView? Would there also be multiple persistent sockets for each particular page? I can't imagine the type of site that would need that sort of structure. Typically you'd have your highly-interactive primary subset of your app, about <10-25% of the routes/views which gets 75-90% of your traffic. While the other 75%+ of routes are just simple static-y/REST CRUD/server-rendered pages.
- brightball 4y ago
  In a situation where you hit the scaling limitations of the BEAM, you’re going to have the budget to address it.
- TylerE 4y ago
  IIRC (don’t claim to be an expert) the main issue is gracefully handling the case where the server end goes away unexpectedly - network issues, reboots, that kind of thing.
  - dmix 4y ago
    Does that include deploys?