Live data from Hacker News

Elixir saves Pinterest $2M a year in server costs

paraxial.io

121–130 of 481 posts

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

#121

Earlier quoted context omitted.

> 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…

They rewrote, which is known to help too. Going from 30 to 15 instances is not bad but it's very likely that a Java-to-Java rewrite would have helped go down too. The big one however is going from 200 Python servers to 4 Erlang ones: a 50x reduction is quite something and a Python-to-Python rewrite would not have allowed to achieved a 50x gain: > All this is possible because Elixir, and the Erlang platform underneath…

> The big one however is going from 200 Python servers to 4 Erlang ones

If your rewrite or refactor gives you a 10X in performance, that's not an optimization, but a bugfix. Unless you are a researcher who have just found a revolutionary algorithm.

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

#122
post #102

And then they take that $2M and bribe someone at Google to ensure 59% of the image search results are from Pinterest.

Is this based on something or just a random conspiracy?

79% of statistics are made up.

Yes it's a joke... just like Google's results in 2023.

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

#123
post #64

Earlier quoted context omitted.

The advantages of Elixir are not performance-related. There is a lot of focus on raw performance on web-related services, when in reality most of their running time is spent waiting for IO. If there are two things the BEAM excels at, is IO and turning almost any problem into half a dozen processes that are scheduled and run in parallel, if not geographically-distributed, with 1/50th the effort of any other language.…

Those naive sequential services don't really exist in prod though. It would be a dark day to discover my AWS t1.337metal was blocking 63 cores on I/O when nearly every modern lang has a wealth of async functionalities just awaiting to be exploited.

You would be shocked if you opened perf and built a statemap. It probably is.

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

#124
post #109

Earlier quoted context omitted.

I think Node is still single core by default? Elixir (or rather the Beam) will handle core utilisation so if you start a load of Elixir processes they’ll be spread across multiple cores.

[flagged]

It doesn't effectively do that. It does about 10% of that, ineffectively.

Instead of running a single VM with full knowledge of how to run lightweight processes, designed to fully take advantage of modern multi-core CPUs with multiple guarantees enforced by the runtime you have multiple single-threaded VMs awkwardly communicating with each other over a bolted-on API

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

#126
post #109

Earlier quoted context omitted.

I think Node is still single core by default? Elixir (or rather the Beam) will handle core utilisation so if you start a load of Elixir processes they’ll be spread across multiple cores.

[flagged]

Yeah but then you have to handle a lot of the synchronization of memory. It is hard to make you realise what is possible on the erlang vm without having tried it.

In particular, it is preemptive. This... Makes a lot of stuff easier.

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

#127

Earlier quoted context omitted.

They rewrote, which is known to help too. Going from 30 to 15 instances is not bad but it's very likely that a Java-to-Java rewrite would have helped go down too. The big one however is going from 200 Python servers to 4 Erlang ones: a 50x reduction is quite something and a Python-to-Python rewrite would not have allowed to achieved a 50x gain: > All this is possible because Elixir, and the Erlang platform underneath…

> The big one however is going from 200 Python servers to 4 Erlang ones If your rewrite or refactor gives you a 10X in performance, that's not an optimization, but a bugfix. Unless you are a researcher who have just found a revolutionary algorithm.

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.

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

#128

Earlier quoted context omitted.

> 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…

Elixir is slower than plain PHP according to the techempower benchmarks. I'm not even sure how that's possible but it is. By like a factor of 2 iirc. I'm not sure how elixir is that slow since it's compiled.

The techempower benchmark are... Quite infamous in the elixir community.

Long story short, they are running in debug mode, badly written, not optimised, with bad OS level settings. And every time the community have tried to contribute fixes, the experience has been... Really bad.

So we stopped trying. If things have changed we could try again but ... We just wrote them off

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

#129
post #100
post #64

Earlier quoted context omitted.

The advantages of Elixir are not performance-related. There is a lot of focus on raw performance on web-related services, when in reality most of their running time is spent waiting for IO. If there are two things the BEAM excels at, is IO and turning almost any problem into half a dozen processes that are scheduled and run in parallel, if not geographically-distributed, with 1/50th the effort of any other language.…

[flagged]

It’s not even remotely similar. Node’s cluster is just bog-standard OS subprocesses running their own event loop.

To spread work over multiple cores with the cluster (or even worker-threads) modules you have to do so explicitely and manually. It’s essentially the same model you get with pthreads, or java, or python.

BEAM is a completely different model, the “processes” are internal tasks, which the runtime will schedule appropriately over available cores (the scheduler has been multithreaded for 15 years or so), spawning processes is as common as spawning tasks in JS, except each of these is scheduled on an SMP runtime.

beam will literally send processes between machines erlang) more easily than node will balance load over cores.

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

#130

> José: Why did you choose Elixir? > Steve: We chose Elixir because we were looking for a system that was easy for programmers to understand and could take better advantage of our servers. I was intrigued at Elixir’s combination of friendly syntax, powerful metaprogramming features, and incorporation of the Actor model. Am I wrong or is this guy in some sort of bubble where only functional languages are taught?

Elixir and Erlang are functional, but not in the Haskell sense. They are pragmatic languages that prefer results over theory and purity.
Post reply on HN