It looks like that GitLab got the Featuritis. Instead of adding tons of unready and half baked feature it should focus on stability and performance.
Personally, I'm not a big fan of "open core" systems for this reason. I'd really prefer that companies like GitLab concentrated on actual services rather than trying to sell software. Having an "open core" can in some ways poison the core for outside development because you usually have to allow your code in the enterprise versions (or maintain your own forked copy). This is one of the reasons why Ghostscript never got the outside help that it really deserved (let's face it -- who uses a free software system and doesn't use Ghostscript?) The fact that nobody pays for it -- or even contributes -- was at one point a pretty sore issue for the author.
I love the fact that GitLab contributes useful free software to the world. I am disappointed that their business plan relies on selling proprietary software. I honestly believe they would be in a better place if they took a different approach, but they have always very politely disagreed with me when I've mentioned it ;-).
We tried charging for services: donations, paid feature development, and paying for support. None of them scaled and we moved to open core which allowed us to spend much more time on performance, security, installation, and dependency upgrades.
We want to make sure that the open source version of GitLab is just as performant and has an equally good UX as the enterprise version. There is no difference in the UX and there are no proprietary performance optimizations in the enterprise version.
There are some things that we see as a feature but that you could see as a performance item. An example is the SSH lookup in a database that used to be in enterprise and landed in the open source version in this release.
Here is a link to our current CSS Refactor plan which will reduce the size of our CSS significantly and reduce render times. https://gitlab.com/gitlab-org/gitlab-ce/issues/42325.
We've got a lot in the pipeline. In the process we won't be shipping any new features, unless you call blazing speed a feature.
> Benefits: We will have files separated. It’s going to be better.
The plan is:
1. Split up the files.
2. Get rid of the as much of the dispatcher.js as we can and have web pack do the routing dynamically. That would eliminate most of 1 large confusing file (dispatcher.js). JS is still cached for the pages you visit but it isn't 1.5mb of JS it would be ~20kb of JS.
Kamil, GitLab CI/CD Lead
Docker socket timeouts have been floating around for a long time with no resolution: https://gitlab.com/gitlab-org/gitlab-runner/issues/2408
Intermittent HTTP auth errors causing build failures: https://gitlab.com/gitlab-org/gitlab-ce/issues/30670
More generally, tuning the runner's polling interval to minimize latency is also tricky, especially with multiple independent runners, and the runner doesn't handle 429s well in my experience (getting stuck in a tight retry loop without backing off sensibly, thus continuing to exceed its request limit).
Thanks for taking the time to solicit feedback.
I run a very small installation with only a couple of projects and some hundred issues on a 4 GB machine. It eats up 2 GB (sigh!!!) - and often still feels extremely slow. I mean 2 Gigabytes!! What for? That's a multitude of all the data I have in the DB there. And then it's not even used for something useful like caching. Some pages take several seconds to load. As a developer that's totally unacceptable to me.
Is ruby really such a mess that it's impossible to run an app with reasonable memory consumption?
There are a bunch of these small project/git-hosts, and while they're easy to manage they're less featureful than the gitlab offering. Gitlab does have some great features, such as the whole integrated CI system, built upon runners & docker.
The downside is complexity, and resource-usage. I know gitlab is free, and I could install it, but the added resources and potential security issues make it a non-starter.
Yes.
Any non-trivial Ruby app will quickly eat up 500MB, and any non-trivial Rails app will soon balloon to 1GB, with things getting worse over time due to memory fragmentation†. Since there is no parallelism your only option is to either have more unicorn workers, for which prefork and COW are hardly working to save you from duplicating memory, especially over time, or have puma threads and use JRuby, which is a memory hog of its own and often slower than MRI.
There have been arguments made that developer time trumps CPU time [0] but there are some workloads and problem domains and uncontrollable events for which this works at the beginning yet later on you find having yourself painted into a corner as suddenly things are not sustainable because you just can't throw more hardware at the issue without going belly up[1]. Once the low hanging fruits have been reaped you're being challenged just to make your app behave within established parameters with diminishing returns, which I'm sure you'd rather spend on solving actual problems for your customers. At that point you might just as well spend the money on rewriting part or all of your app in a more frugal ecosystem and mindset[2].
† Switching to jemalloc may or may not help. Over here it did not.
[0]: https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-...
[1]: https://twitter.com/migueldeicaza/status/950054181045440518
Any cloud provider will provide a VM that can comfortably run it for a very reasonable price.
I'm using the gitlab-omnibus one.
Being a PHP developer myself it's really hard to believe that resource consumption is obviously treaded with so little priority in the rails/ruby world.
And some attitudes here like "who cares? memory/cpu is cheap nowadays" are in my opinion part of the problem. I'd say, well written software should use as little resources as possible. Probably a habit that comes from my early days on a C64 back in the 80s.
It's about priorities. IMO if using as little resources as possible is priority number 1, then something is amiss.
For example, the average response time of an issue page has come down from 2.5s to 750ms over the last 6 months.
We still have a lot to do, but we're getting there.
> Yeah, and they've promised to work on performance for ages now with almost
> no improvement.
A specific GitLab.com issue in December 2015 vs January 2018 (I can't seem to find what the exact URL is):
2015: http://stats.gitlab.com/1902794/2015/12
2018: http://stats.gitlab.com/1902794/2018/01
Apart from that you can take a look at any of the past release posts or merge requests tagged with "performance" [1][2] and you'll see that plenty of improvements have been made over time.
> Is ruby really such a mess that it's impossible to run an app with
> reasonable memory consumption?
[1]: CE improvements: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope...
[2]: EE improvements (some of these may be merges from CE): https://gitlab.com/gitlab-org/gitlab-ee/merge_requests?scope...
Unfortunately this is almost never the case: Sometimes the pages load even slower. In the best case there's not much difference. Same goes for memory consumption.
But I understand now that this will always be a problem with rails.
Fortunately, gogs is a thing.
We've also got an entire team dedicated to porting our Git layer to Go with Gitaly[1], which has been a major bottleneck that we've started resolving over the last year or so.
[0]: https://gitlab.com/groups/gitlab-org/-/merge_requests?label_... [1]: https://gitlab.com/gitlab-org/gitaly