Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elixir saves Pinterest $2M a year in server costs

paraxial.io

Post reply on HN
Print view View original

251–260 of 481 posts

Re: Elixir saves Pinterest $2M a year in server costs

#251

Post by throwawaymaths »

zaphar wrote: post #238
Thaxll wrote: post #199

Earlier quoted context omitted.

I wrote the same kind of tool in both Elixir and Go, the performance difference was huge between the two, Elixir / Erlang is pretty slow overall.

The go runtime has similar capabilities as the BEAM runtime when it comes to concurrent workloads. Go has the benefit of being a typesafe compiled language which gives it speed benefits. But using either one of them instead of Java is probably going to be a huge win for most teams on concurrent workloads.

Does it have similar capabilities in fault tolerance?

Re: Elixir saves Pinterest $2M a year in server costs

#252

Post by atraac »

winter_blue wrote: post #191
miroljub wrote: post #171

Earlier quoted context omitted.

Second system syndrome. They did savings by re-implementing their services and attribute those savings to the new tool / programming language. I wonder what the saving would look like if they chose another tool for the second / optimized system. I doubt it would differ much if they went with Go, Java or stayed with Python.

This is a pretty realistic balanced real-world benchmark of web frameworks (and languages): https://www.techempower.com/benchmarks/ It shows that Python with Django is literally 40 times slower than the fastest framework. Python with uvicorn is 10 times slower. The use of languages like Python and Ruby literally results in >10x the servers being used; which not only results in higher cost, but also greater electricit…

> This is a pretty realistic balanced real-world benchmark of web frameworks (and languages): https://www.techempower.com/benchmarks/

Did you even ever see implementation behind techempower benchmarks? There's NOTHING realistic in them. Those applications literally hardcode static content length header values to be faster. They are pretty good show of how low you can get to squeeze out performance but not one sane person will write code like that.

Re: Elixir saves Pinterest $2M a year in server costs

#253

Post by neeleshs »

threeseed wrote: post #17
coldtea wrote: post #3

By the title alone, this means nothing. How much would it cost otherwise? What is the percentage savings? In TFA, it gets better though: "Steve: That’s pretty easy. When I started on the spam team, we had close to 1,400 servers running. When we converted several parts to Elixir, we reduced that by around 95%. One of the systems that ran on 200 Python servers now runs on four Elixir servers (it can actually run on two…

> When our notifications system was running on Java, it was on 30 c32.xl instances. When we switched over to Elixir, we could run on 15. Would be curious to know how they tried to optimise the Java stack. Because on every benchmark I've seen the JVM is faster in every which way than Elixir. Except for memory where often people will over-provision the JVM rather than look at where their code might be over-allocating o…

Yep. We got a 10x improvement on throughput for our backend runtime, which was in Java, by moving to a better architecture for performance hotspots.. using Java again.

In a rewrite with a different design/architecture, that new design typically accounts for most gains, rather than language.

A language may make some parts of that rewrite simpler.

Re: Elixir saves Pinterest $2M a year in server costs

#254

Post by fidotron »

pdimitar wrote: post #247
fidotron wrote: post #241

Earlier quoted context omitted.

There are entire github repos dealing with it. Frankly the Elixir ecosystem, which is not without merit, is more interested in perpetuating the myth of magic scalability by virtue of the beam.

Frankly I am seeing that as a myth, you seem to have made up your mind some time ago or judged by 1-2 occasions. I am on ElixirForum every day and worked with Elixir for 7 years and have never seen anyone "perpetuate myths". I've seen some people willing to "increase adoption" which was always met with resistance by the wider community -- we believe growth should be organic. Pretty sad stance from you though, I have…

> If you are not willing to try it, that's fair. Say that. Claiming you know stuff about the ecosystem while a guy who is there every day comes across as... strange. Biased. And not arguing in good faith. :(

I am not willing to drag others, such as those that wrote the repos, into a technical discussion with people out to act as you are.

Re: Elixir saves Pinterest $2M a year in server costs

#255

Post by Difwif »

btreecat wrote: post #176
coldtea wrote: post #127

Earlier quoted context omitted.

Or you just used a crappy inefficient architecture or algorithsm etc. Just because they were slow doesn't make them bugs, nor does using something faster in a rewrite means it's a bugfix.

They could be design bugs as in it was broken/buggy by design.

Or it was quick and cheap to build, by design. It's perfectly acceptable to optimize for time to market first if you can eat the other costs.

Re: Elixir saves Pinterest $2M a year in server costs

#256

Post by throwawaymaths »

fidotron wrote: post #210
pdimitar wrote: post #196

Earlier quoted context omitted.

There is a reason: the BEAM is almost not prone to huge GC pauses. Bigger load results in every actor responding very slightly slower. Nothing else. Many other systems don't have this property. They fall down under pressure. Gosh, a huge chunk of HN is always so dismissive. At least read up a bit beforehand, man. The criticisms should be informed and benefit the readers, not only express a generic skepticism.

The beam just garbage collects each actor separately, and it so happens that much of the time your actor has finished before a gc happened so you never see the cleanup. The beam also has a spectacular failure mode: OOM whenever messages come in at a higher rate than they are processed. The lack of backpressure mechanisms mean a huge amount of beam language developers spend way too much time recreating their own way f…

I think that's developers using GenServer.cast when they should be using call. Call gives you back pressure mechanism.

Re: Elixir saves Pinterest $2M a year in server costs

#258

Post by Adkron »

btreecat wrote: post #176
coldtea wrote: post #127

Earlier quoted context omitted.

Or you just used a crappy inefficient architecture or algorithsm etc. Just because they were slow doesn't make them bugs, nor does using something faster in a rewrite means it's a bugfix.

They could be design bugs as in it was broken/buggy by design.

Could those design-bugs be in the language's runtime?

Re: Elixir saves Pinterest $2M a year in server costs

#259

Post by throwawaymaths »

pdimitar wrote: post #228
fidotron wrote: post #210

Earlier quoted context omitted.

The beam just garbage collects each actor separately, and it so happens that much of the time your actor has finished before a gc happened so you never see the cleanup. The beam also has a spectacular failure mode: OOM whenever messages come in at a higher rate than they are processed. The lack of backpressure mechanisms mean a huge amount of beam language developers spend way too much time recreating their own way f…

I can see how you would think that, yes. In practice I haven't noticed it except in super rare cases where processes (actors) hold on to huge binaries / strings -- which is one of the weak points of BEAM's GC.

The big offenders is serializing huge jsons and chucking small binaries slices from that into an ets table.

Also concatenating binaries. Don't do that, use an iolist

Post reply on HN