Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Erlang 22 series support #336

Closed
michaelklishin opened this issue May 15, 2019 · 12 comments · Fixed by #340
Closed

Erlang 22 series support #336

michaelklishin opened this issue May 15, 2019 · 12 comments · Fixed by #340

Comments

@michaelklishin
Copy link
Contributor

This is not an issue but rather a heads-up and a place to discuss how we want to support Erlang 22.x which is now GA.

This image currently provides a single (latest) version of Erlang. If we want to continue this way, should we wait for a few 22.0.x patch releases? Should we consider supporting two major versions?

@gerhard

@gerhard
Copy link
Contributor

gerhard commented May 15, 2019

This image currently provides a single (latest) version of Erlang

As it currently stands, Erlang/OTP versions are already pinned to v21 and follow the official Which Erlang - Max supported version. This feels right from all perspectives.

Should we wait for a few 22.0.x patch releases?

Yes. Out of experience, it's always best to wait out at least 2 patches for a new major release before upgrading, especially production.

Should we consider supporting two major versions?

I don't see sufficient benefits in supporting multiple major versions. A single Erlang/OTP version feels adequate.

The plan for Erlang/OTP 22 is to start battle-testing it as early as next week. Most of this will be via rabbitmq-prometheus. The new metrics are insightful in more than one way, I am confident that we have everything we need to make the right decisions. FWIW, the Dockerfile is already based on the official Ubuntu one, it's an easy way of sharing relevant learnings.

Any thoughts @tianon & @yosifkit ?

@tianon
Copy link
Member

tianon commented May 17, 2019

Sounds reasonable! We'll look forward to the results of your testing. 👍

gerhard added a commit to rabbitmq/rabbitmq-prometheus that referenced this issue May 20, 2019
Picking up the latest 3.8.0 alpha while at it.

It's time to start stress-testing OTP 22 re docker-library/rabbitmq#336

[#166037004]
@gerhard
Copy link
Contributor

gerhard commented May 24, 2019

This week was busier than usual, will follow-up next week. 🌆

@gerhard
Copy link
Contributor

gerhard commented May 31, 2019

The only nit-pick that I've come across in OTP 22 this week is ERL-959. It is possible that this yet-to-be-acknowledged bug is present in prior versions (e.g. 21, 20, etc.), I wouldn't worry too much about it in the context of the Docker image.

Considering that we are now publishing OTP 22 packages for both deb & rpm, as well as officially supporting OTP 22.0.x since 3.7.15, it's safe to update the OTP pinning to 22 in all Docker images 👍

I plan to continue with OTP 22 next week, will update this thread if anything comes up.

Btw, there are a few good comments on RabbitMQ compatibility with Erlang 22.0 GA in this rabbitmq-users mailing list thread by @michaelklishin

@tianon
Copy link
Member

tianon commented May 31, 2019

Given the notes about HiPE in that thread, should we also remove our HiPE support from the image?

amd64 | i386 | ppc64el) hipe='--enable-hipe' ;; \

amd64 | i386 | ppc64el) hipe='--enable-hipe' ;; \

hipe_compile

@gerhard
Copy link
Contributor

gerhard commented May 31, 2019

Yes, definitely.

This is from OTP 22 release notes:

In OTP 22, HiPE (the native code compiler) is not fully functional. The reasons for this are:

Search for OTP-15596 in the above notes to see the rest.

Also, in OTP HiPE docs:

HiPE and execution of HiPE compiled code only have limited support by the OTP team at Ericsson. The OTP team only does limited maintenance of HiPE and does not actively develop HiPE. HiPE is mainly supported by the HiPE team at Uppsala University.

@gerhard
Copy link
Contributor

gerhard commented Jun 3, 2019

Nice!

Btw, ERL-959 is not a bug. It was a matter of learning something new - see that issue for full context.

@avihil1
Copy link

avihil1 commented Nov 10, 2020

Yes, definitely.

This is from OTP 22 release notes:

Does it mean that RabbitMQ will be slower now, without HiPE compiling ? @gerhard

@gerhard
Copy link
Contributor

gerhard commented Nov 11, 2020

In the scenarios that HiPE was making RabbitMQ faster, then yes, RabbitMQ will be slower without HiPE.

In real-world scenarios, disks, network contention or lower-frequency CPUs (e.g. AMD Epyc) will have a higher impact on RabbitMQ than HiPE did. Client configuration (e.g. publisher confirms, multi confirm, etc.) will also have a significant impact on RabbitMQ's perceived speed.

It would be interesting to know what impact (if any) disabling HiPE in your production has (everyone's production is different). Care to share the performance that you are expecting out of RabbitMQ @avihil1?

Erlang Jit that is expected to ship in OTP 24 (summer 2021) - erlang/otp#2745 - is the HiPE replacement that I am looking forward to 😉

You may find https://www.rabbitmq.com/blog/2020/06/04/how-to-run-benchmarks/ & https://github.com/rabbitmq/workloads useful. There are some good recent posts on our blog on this topic: https://www.rabbitmq.com/blog/category/performance-2/

@avihil1
Copy link

avihil1 commented Nov 11, 2020

Thanks !

We didn't benchmark our production, we had issues in the past, wanted to make sure that if we upgrade to non-HiPE version, issues won't pop up

@gerhard
Copy link
Contributor

gerhard commented Nov 11, 2020

My recommendation would be to not upgrade until you are satisfied with the benchmark results.

Don't benchmark production. Setup an identical environment and simulate the traffic that production is expected to handle. It doesn't get any easier than this: https://github.com/rabbitmq/tgir/blob/S01E07/s01/e07/k8s/rabbitmq/default-metrics.yml. For extra context: https://github.com/rabbitmq/tgir/tree/S01E07/s01/e07

Everything that I mentioned above is from years of experience with under-performing production RabbitMQ deployments. I have more specifics in this RabbitMQ Summit 2018 talk: Real-world RabbitMQ deployments

@avihil1
Copy link

avihil1 commented Nov 11, 2020

Thanks! very helpful

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants