5 ms·

TL;DR: this is a toy example, so it doesn't require BEAM VM Hard to take this seriously without the loadtest with the the large number of concurrent users. Fo

TL;DR: this is a toy example, so it doesn't require BEAM VM Hard to take this seriously without the loadtest with the the large number of concurrent users. For a number of users concurrently reading a long-tail blog post - you will get good results even using DotCom era HTTP polling. --- See: Django LiveView vs Phoenix LiveView: a real benchmark https://en.andros.dev/blog/80134668/django-liveview-vs-phoenix-liveview-a-real-benchmark/ https://en.andros.dev/blog/80134668/django-liveview-vs-phoen...

JSR_FDED 1mo ago
What is there to take seriously? Sending a ~50 bytes to ~200 listeners over a websocket about once a second is trivial even for a Raspberry Pi.
- nivertech 1mo ago
  It pretends to be serious with 5 tables / charts: Django LiveView vs Phoenix LiveView: a real benchmark https://en.andros.dev/blog/80134668/django-liveview-vs-phoenix-liveview-a-real-benchmark/ https://en.andros.dev/blog/80134668/django-liveview-vs-phoen...
  - rkangel 1mo ago
    Yeah, maximum concurrent clients being 50 is nothing and you're already seeing a large gap. That is the whole point of the BEAM - it scales well with concurrent stuff which is important with web in general and very important for LiveView.
    - andros 1mo ago
      50 is the hardware limit, not a personal choice. The code is free and accessible from the article itself. If you can run tests with more, I'd be happy to update the graphs and the conclusion.
      - nivertech 1mo ago
        > 50 is the hardware limit this can't be true, If that hardware can run Django and Phoenix, it for sure can handle orders of magnitudes more concurrent clients than 50 even before you start tuning the OS and the runtime. > Playwright headless Chromium maybe you mean you're unable to generate more than 50 concurrent clients using Playwright+Chromium - but that's the wrong tool for loadtesting. Loadtest should run from a different machine or cluster of machines/VMs. You can generate up to ~ 64K outgoing connections per IP address / alias. With 17 IP addresses/aliases you can generate up to C1M.
        andros 1mo ago
        You're giving me statements and advice without knowing either the hardware I use or the tools. I don't have the resources to do this kind of massive testing; if you're up for doing it yourself, I'd be happy to update the data.
  - andros 1mo ago
    How would you have approached it?
    - nivertech 1mo ago
      Your "Concurrency" benchmark ends at 50 concurrent clients. Continue testing at C1K, C10K, C100K, C1M, C2M, etc. That's for a single node. Then try multiple nodes / cluster - C1M, C2M, C10M, etc. Also, all concurrent clients should send periodic pings / keepalives and do something useful (e.g. some CPU work, not just being idle). Then you'll have to change your conclusion from: > The data answers my original question: yes, Django LiveView holds up against Phoenix LiveView. In day-to-day operations they are practically equal. to > The data answers my original question: yes, under *toy* load Django LiveView holds up against Phoenix LiveView. For *toy* operations they are practically equal.
      - andros 1mo ago
        Since you seem so knowledgeable about this, why don't you do it yourself? The code is available in the repository. I'm sure you'll do much better than I can.

JSR_FDED 1mo ago

What is there to take seriously? Sending a ~50 bytes to ~200 listeners over a websocket about once a second is trivial even for a Raspberry Pi.

nivertech 1mo ago
It pretends to be serious with 5 tables / charts: Django LiveView vs Phoenix LiveView: a real benchmark https://en.andros.dev/blog/80134668/django-liveview-vs-phoenix-liveview-a-real-benchmark/ https://en.andros.dev/blog/80134668/django-liveview-vs-phoen...
- rkangel 1mo ago
  Yeah, maximum concurrent clients being 50 is nothing and you're already seeing a large gap. That is the whole point of the BEAM - it scales well with concurrent stuff which is important with web in general and very important for LiveView.
  - andros 1mo ago
    50 is the hardware limit, not a personal choice. The code is free and accessible from the article itself. If you can run tests with more, I'd be happy to update the graphs and the conclusion.
    - nivertech 1mo ago
      > 50 is the hardware limit this can't be true, If that hardware can run Django and Phoenix, it for sure can handle orders of magnitudes more concurrent clients than 50 even before you start tuning the OS and the runtime. > Playwright headless Chromium maybe you mean you're unable to generate more than 50 concurrent clients using Playwright+Chromium - but that's the wrong tool for loadtesting. Loadtest should run from a different machine or cluster of machines/VMs. You can generate up to ~ 64K outgoing connections per IP address / alias. With 17 IP addresses/aliases you can generate up to C1M.
      - andros 1mo ago
        You're giving me statements and advice without knowing either the hardware I use or the tools. I don't have the resources to do this kind of massive testing; if you're up for doing it yourself, I'd be happy to update the data.
- andros 1mo ago
  How would you have approached it?
  - nivertech 1mo ago
    Your "Concurrency" benchmark ends at 50 concurrent clients. Continue testing at C1K, C10K, C100K, C1M, C2M, etc. That's for a single node. Then try multiple nodes / cluster - C1M, C2M, C10M, etc. Also, all concurrent clients should send periodic pings / keepalives and do something useful (e.g. some CPU work, not just being idle). Then you'll have to change your conclusion from: > The data answers my original question: yes, Django LiveView holds up against Phoenix LiveView. In day-to-day operations they are practically equal. to > The data answers my original question: yes, under *toy* load Django LiveView holds up against Phoenix LiveView. For *toy* operations they are practically equal.
    - andros 1mo ago
      Since you seem so knowledgeable about this, why don't you do it yourself? The code is available in the repository. I'm sure you'll do much better than I can.