4 ms·

I'm surprised to see that GitLab is using Unicorn. Isn't Unicorn grossly inefficient, because each of the worker processes can only handle one request at a time

I'm surprised to see that GitLab is using Unicorn. Isn't Unicorn grossly inefficient, because each of the worker processes can only handle one request at a time. Are web application processes actually CPU-bound these days? I don't know much about the Ruby web server landscape, but might Puma (http://puma.io/ http://puma.io/) be better?

nik736 10y ago
I was wondering the same. For my projects Puma has been awesome and better than Unicorn.
- sytse 10y ago
  Puma is great. We tried it years ago and multithreading caused problems. This is likely due to problems in our application and its dependencies, not Puma. We reverted it in https://github.com/gitlabhq/gitlabhq/commit/3bc4845874112242d6e885731c033ffe85ee98dd https://github.com/gitlabhq/gitlabhq/commit/3bc4845874112242...
bpicolo 10y ago
For "grossly inefficient" I imagine it depends. If you're loading most of the app prefork then the memory overhead for more processes is pretty low. (Disclaimer: Dunno much about ruby deployments)
- mwcampbell 10y ago
  But the number of Unicorn processes that GitLab runs is "virtual cores + 1". It seems to me that this only makes sense if web application request handling is actually CPU bound. Maybe it is if you have a really good caching implementation and hardly ever have to query the DB.
YorickPeterse 10y ago
Puma is something we want to eventually run, but right now it's not really a priority. Instead we're focusing on response timings and memory usage. See the following links for more information: https://gitlab.com/gitlab-org/gitlab-ce/issues/3592 https://gitlab.com/gitlab-org/gitlab-ce/issues/3592 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/1899 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/1899