How are your LiveView production servers doing?

One concern that comes up a lot is how LiveView stores and runs a lot of data server-side.

I’ve always seen this a good thing.

First off, I really appreciate sites/apps that are nice to my phone’s battery as well as my laptop’s memory. Even users who don’t actively care about this passively care without realizing it. Next, if you have intellectual property to protect then it’s obviously better to have as much of it server-side as possible. I once saw some Hack News folk carrying on about how they hate people who reverse engineer obfuscated JS. “Well stop putting sensitive stuff in client-side JS, you ding dongs” was my thought, but I digress*

As far as costs go, If I’m running a dedicated server anyway then I’ve already paid for my memory so go ahead and max it out. If I need to scale up or out, then I have more users who are theoretically offsetting the extra costs exponentially.

Of course, I don’t have actual experience with this. I did briefly work for a company that ran a LiveView widget in production, but I never dug into the financials with them (our servers seemed fine, though!)

So my very open-ended question to small-to-medium business folk running LiveView: what’s your experience been like with this?

Thanks to any willing to share!


(*) I do realize that there are certain classes of web applications that must be heavily client-side. I’m just being cheeky, ok?

4 Likes

It’s incredibly cheap given you have „ordinary“ liveviews and don’t do extremely challenging computation in your event handlers.

A single (multicore, few gigs RAM) instance can be able to run even a large business. Without breaking a sweat. Even if you do encounter exceptionally high load, the very nature of the beam will prioritize short functions (like user interactions, page loads, …) over heavy background jobs, so the overall system remains snappy until severe overloaded.

(Background: did. this in the past with bigger companies and Black Friday was boring for us technicians!)

4 Likes

Small app between 150-200 concurrent connections which uses about 3.5 GB of ram over 6 instances.

3 Likes