why did gitlab 6 switch back to unicorn?

Question

Gitlab 6.0 was released yesterday. I am curious to know why they switched to Unicorn from Puma. Versions prior to 5 were using Unicorn. I thought switch to Puma was for the better.

Is there a technical reason for this switch?

Bruce

Answer 1

GitLab B.V. CEO here, I agree with Hongli his comment that "If there are issues then they are likely in Gitlab's code.". We tried to fix them but GitLab is one of the largest open source Rails applications and the issues where hard to reproduce. So in the end we opted for the most pragmatic solution, switching back to Unicorn. We love Puma, Unicorn and Passenger and think they are all fantastic pieces of software.

Citrate

Just a quick note that GitLab made the final move to Puma: about.gitlab.com/blog/2020/07/08/migrating-to-puma-on-gitlab – Raccoon

Answer 2

Update April 2020, GitLab 12.10:

Puma will become the default application server

GitLab will be switching default application servers from Unicorn to Puma in 13.0.

And with GitLab 13.0 (May 2020):

Reduced memory consumption of GitLab with Puma

Read the last sections below.

---

Original answer 2013

The commit 3bc484587 offers some clues from Mathieu 'OtaK' Amiot:

We switched from Puma in GitLab 5.4 to unicorn in GitLab 6.0.

why switch back to Unicorn again?

Puma caused 100% CPU and greater memory leaks when running mult-ithreaded on systems with many concurrent users.
That's because people used MRI. You MUST use JRuby or Rubynius when using Puma. Or else the world breaks apart.

Mathieu adds in the comments:

Yes, Unicorn is better (but more memory-eager) on MRI setups.
Puma is better on Rubinius & JRuby, that's all.

They can't force people to use other implementations of the Ruby Runtime, so they just fell back to the best setup for most setups :) –

---

Light controversy ensues around:

• Puma: Hongli comments:

Puma's multithreading works just fine with MRI.
I say this as one of the authors behind Ruby Enterprise Edition, so I know Ruby's threading system inside-out.
Evan Phoenix, Puma's author, has also stated that using Puma with MRI works just fine.

If there are issues then they are likely in Gitlab's code.

That being said, in Apr. 2020, Puma is now available as an alternative web server to Unicorn with GitLab 12.9
^{(mentioned by mbomb007 in the comments)}

• Phusion Passenger Enterprise:

Mathieu 'OtaK' Amiot comments:

Passenger is not as stable as most people think. A nginx + Unicorn is more stable IMHO. –

Hongli answers:

We have lots and lots of large users using Phusion Passenger, both open source and Enterprise, on a daily basis with great stability and success.
Think New York Times, 37signals, Motorola, UPS, Apple, AirBnB. Some of them even switched away from Unicorn in favor of Passenger (either open source or Enterprise)

---

Update August 2014: there is an article on "Running GitLab 7.1 using Puma instead of a Unicorn"

---

Update April 2020, GitLab 12.10:

Puma will become the default application server

GitLab will be switching default application servers from Unicorn to Puma in 13.0.
Puma is a multithreaded application server, allowing GitLab to reduce it’s memory consumption by about 40%.

A> s part of the GitLab 13.0 upgrade, users who have customized Unicorn settings will need to manually migrate these settings to Puma.
It will also be possible to remain on Unicorn, by disabling Puma and re-enabling Unicorn until Unicorn support is removed in a future release.

This is thanks to Dmitry Chepurovskiy, who has made a major contribution adding the Puma web server to the GitLab unicorn Helm chart (soon to be the webservice chart).

This work provides users of the GitLab Helm chart with the option to use Puma instead of Unicorn.
In testing, we have observed a 40% reduction in memory usage when using Puma as the web server.

See Epic.

---

With GitLab 13.0 (May 2020):

Reduced memory consumption of GitLab with Puma

Puma is now the default web application server for both the Omnibus-based and Helm-based installations. Puma reduces the memory footprint of GitLab by about 40% compared to Unicorn, increasing the efficiency of GitLab and potentially saving costs for self-hosted instances.

Installations which have customized the number of Unicorn processes, or use a slower NFS drive, may have to adjust the default Puma configuration.
See the Important notes on upgrading and GitLab chart improvements for additional details.

See documentation and Epic.

Steak

Guess you are right. But then I couldn't find any reasoning for switch from Unicorn to Puma in version 5.1.0. – Bruce

They switched to Puma because it uses less memory than Unicorn. In practice, Unicorn and Puma both have their own pros and cons, neither of them is strictly better than the other. If memory and stability is a concern then the user may also use Phusion Passenger Enterprise which uses less memory and is more stable (source). – Bergeron

I'm the author of this comment, That's because people used MRI. You MUST use JRuby or Rubynius when using Puma. Or else the world breaks apart. And yes, Unicorn is better (but more memory-eager) on MRI setups. Puma is better on Rubinius & JRuby, that's all. They can't force people to use other implementations of the Ruby Runtime, so they just fell back to the best setup for most setups :) – Expertism

@Mathieu'OtaK'Amiot thank you for this comment. I have included it in the answer for more visibility. – Steak

Thanks @hongli for your comments. Phusion Passenger Enterprise is a commercial product, may not suite a product like Gitlab (for masses). I understand Phusion uses Gitlab, I probably should not ask this, but I would like to believe you run it on Passenger. Would you be open sourcing your Gitlab+Passenger install/upgrade recipe? – Bruce

@ShireeshJ Indeed, PPE is commercial, and for OSS projects such as Gitlab, is not suitable unless both parties are making an agreement. Moreover, Passenger is not as stable as most people think. A nginx + Unicorn is more stable IMHO. – Expertism

@ShireeshJ: our recipe with Phusion Passenger Enterprise is basically the as the one we described here: blog.phusion.nl/2012/04/21/…. Just replace Phusion Passenger open source with Phusion Passenger Enterprise – Bergeron

@Mathieu'OtaK'Amiot: We have lots and lots of large users using Phusion Passenger, both open source and Enterprise, on a daily basis with great stability and success. Think New York Times, 37signals, Motorola, UPS, Apple, AirBnB. Some of them even switched away from Unicorn in favor of Passenger (either open source or Enterprise). Perhaps you've had bad experience with Phusion Passenger in the past? If so, could you tell us more about your problems? We'd be happy to help. We guarantee that it's stable, and if it's not for you, we'll fix it. – Bergeron

As for the "That's because people used MRI. You MUST use JRuby or Rubynius when using Puma. Or else the world breaks apart." comment - that is false. Puma's multithreading works just fine with MRI. I say this as one of the authors behind Ruby Enterprise Edition, so I know Ruby's threading system inside-out. Evan Phoenix, Puma's author, has also stated that using Puma with MRI works just fine (news.ycombinator.com/item?id=5995142). If there are issues then they are likely in Gitlab's code. – Bergeron

@Mathieu'OtaK'Amiot I kind of agree with Hongli with respect to stability of Passenger. We use all three - passenger, unicorn and puma. Though all are stable, I find passenger easy to manage. One of our websites www.elitmus.com runs on Passenger OSS and has an alexa rank of 13000. Thats fairly good traffic it handles. We hardly ever had problems managing traffic growth with Passenger (since version 2.0.x till now). – Bruce

@Bergeron I'll give it another try then, last time I used it was with Phusion REE (rubyenterpriseedition.com) and it was really, literally, hell. Thanks for the info :) And my bad for the bad-mouthing if I'm wrong :( – Expertism

No worries. Please feel free to contact our support forum if you run into anything. We're always interested in making things better. – Bergeron

Another update: Puma is available in 12.9 – Adel

@Adel Thank you. I have included your comment in the answer for more visibility. – Steak