13 ms·

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.

romanovcode 9y ago
They got this disease long time ago. Instead of focusing 110% on UI and performance they just push more features.
- NicoJuicy 9y ago
  Things have changed and seem to be measured. Change too much and your existing customer base won't like it
pzduniak 9y ago
They're improving performance and UI though, the new features only go to EE* versions. The new features are only a reason for them to get new Enterprise subscribers.
mikekchar 9y ago
This may be completely unfair, but I think it's a drawback of the business model they have. When you have an "open core" that you don't charge for, you have to have something that you can charge for. If you make the "enterprise edition" performant with good UX and the "community edition" slow and clunky then you threaten to kill off your potential user base. On the other hand, if you spend all your time improving the core, then there is nothing for people to buy. The prudent thing to do is to do as little as possible on the "core" because it is essentially a marketing expense. You need to invest as much as possible in the extensions that bring in revenue. 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 ;-).
- sytse 9y ago
  I'll try to very politely disagree :) 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.
  - tyldum 9y ago
    I was a fan, and we got an Enterprise license when it was the only tier offered. Now there's two tiers above EES with insane price jumps. I can only assume there will be even more tiers introduced so we decided not to upgrade. We use GitLab as a platform for the whole company, but only a handful will use EEP/EEU features. An upgrade would be inhibitivly expensive or we must reduce the number of licenses to a fraction of the employees.
  - mikekchar 9y ago
    Hey, you guys are running a business and I'm running a commentary :-) This stuff is hard enough that what-ifs and naysayers are going to crop up. One of these days I should just put my money where my mouth is. I think the scaling issue is definitely a huge problem and even Cygnus said they found it extremely difficult. I'm not sure it's possible to get the ROI you need if you accept VC, so given your current position, it's not really fair for me to criticise.
jakecodes 9y ago
Hey there! Jacob, Frontend leads here. At GitLab we've put together a team of 5 Frontend Engineers (including myself) to focus solely on performance and stability issues. We are focusing on reducing the size of our JS and CSS. We are currently focusing on splitting our one giant JS file into many smaller JS files. Here's our current issue for code splitting the JS. https://gitlab.com/gitlab-org/gitlab-ce/issues/41341 https://gitlab.com/gitlab-org/gitlab-ce/issues/41341 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 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.
- kingosticks 9y ago
  What real-world speedup will you see? There's no data in that issue to support the idea that this is worth doing. Surely someone hacked up a split version and ran some benchmarks, right? Maybe you could include that data somewhere as the closest thing to that I can find is: > Benefits: We will have files separated. It’s going to be better.
  - jakecodes 9y ago
    I'll add our benchmarks into that issue shortly. Our biggest slowdowns are parsing, layouts, and memory. Without this splitting every file is imported, functions are instantiated but not used. With our new method only files needed are bundled and most of the dispatcher.js file is removed. Removing error prone string matching from switch statements to having it automatically done by webpack. 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.
- mwj 9y ago
  Jacob that stuff really has no effect on the stability of the CI system and private runners, which is the real problem.
gtirloni 9y ago
It's a side effect of what they are calling "Complete DevOps" https://about.gitlab.com/2017/10/11/from-dev-to-devops/ https://about.gitlab.com/2017/10/11/from-dev-to-devops/
mh-cx 9y ago
Yeah, and they've promised to work on performance for ages now with almost no improvement. 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?
- foepys 9y ago
  Maybe you are already committed to gitlab and its workflow but Gogs and Gitea are small and fast GitHub clones written in Go if you need something light-weight.
  - Kihashi 9y ago
    I'd switch to using one of those, but my team relies on the code review of gitlab.
  - stevekemp 9y ago
    Personally I run gitbucket, which is a small and self-contained java-based "github alternative". 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.
- lloeki 9y ago
  > Is ruby really such a mess that it's impossible to run an app with reasonable memory consumption? 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-years-afff4a54abc7 https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-... [1]: https://twitter.com/migueldeicaza/status/950054181045440518 https://twitter.com/migueldeicaza/status/950054181045440518 [2]: https://twitter.com/lloeki/status/950079609051152384 https://twitter.com/lloeki/status/950079609051152384
user15672 9y ago
They've been promising to fix performance and the UI for years now, so I wouldn't hold out much hope. It's a shame, but there are better open source products so it's not like there are no other options for self hosted.
- jhasse 9y ago
  IMHO the UI did get better over the years.
  - sytse 9y ago
    Thanks. We do think it got a lot better last year https://about.gitlab.com/2017/07/17/redesigning-gitlabs-navigation/ https://about.gitlab.com/2017/07/17/redesigning-gitlabs-navi...
- connorshea 9y ago
  For what it's worth, in the last year (since January 23, 2017) we've merged ~440 merge requests labeled "performance"[0]. It's not perfect right now and there's still plenty of work to do, but compared to when I started at GitLab almost two years ago it's night-and-day. 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_name%5B%5D=performance&scope=all&sort=created_date&state=merged https://gitlab.com/groups/gitlab-org/-/merge_requests?label_... [1]: https://gitlab.com/gitlab-org/gitaly https://gitlab.com/gitlab-org/gitaly
cweagans 9y ago
Absolutely this. The amount of RAM that I need in order to run Gitlab is greater than the RAM requirements of all of the projects that I would host in a Gitlab instance combined. Fortunately, gogs is a thing.

romanovcode 9y ago

They got this disease long time ago. Instead of focusing 110% on UI and performance they just push more features.

NicoJuicy 9y ago
Things have changed and seem to be measured. Change too much and your existing customer base won't like it

pzduniak 9y ago

They're improving performance and UI though, the new features only go to EE* versions. The new features are only a reason for them to get new Enterprise subscribers.

mikekchar 9y ago

This may be completely unfair, but I think it's a drawback of the business model they have. When you have an "open core" that you don't charge for, you have to have something that you can charge for. If you make the "enterprise edition" performant with good UX and the "community edition" slow and clunky then you threaten to kill off your potential user base. On the other hand, if you spend all your time improving the core, then there is nothing for people to buy. The prudent thing to do is to do as little as possible on the "core" because it is essentially a marketing expense. You need to invest as much as possible in the extensions that bring in revenue. 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 ;-).

sytse 9y ago
I'll try to very politely disagree :) 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.
- tyldum 9y ago
  I was a fan, and we got an Enterprise license when it was the only tier offered. Now there's two tiers above EES with insane price jumps. I can only assume there will be even more tiers introduced so we decided not to upgrade. We use GitLab as a platform for the whole company, but only a handful will use EEP/EEU features. An upgrade would be inhibitivly expensive or we must reduce the number of licenses to a fraction of the employees.
- mikekchar 9y ago
  Hey, you guys are running a business and I'm running a commentary :-) This stuff is hard enough that what-ifs and naysayers are going to crop up. One of these days I should just put my money where my mouth is. I think the scaling issue is definitely a huge problem and even Cygnus said they found it extremely difficult. I'm not sure it's possible to get the ROI you need if you accept VC, so given your current position, it's not really fair for me to criticise.

jakecodes 9y ago

Hey there! Jacob, Frontend leads here. At GitLab we've put together a team of 5 Frontend Engineers (including myself) to focus solely on performance and stability issues. We are focusing on reducing the size of our JS and CSS. We are currently focusing on splitting our one giant JS file into many smaller JS files. Here's our current issue for code splitting the JS. https://gitlab.com/gitlab-org/gitlab-ce/issues/41341 https://gitlab.com/gitlab-org/gitlab-ce/issues/41341 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 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.

kingosticks 9y ago
What real-world speedup will you see? There's no data in that issue to support the idea that this is worth doing. Surely someone hacked up a split version and ran some benchmarks, right? Maybe you could include that data somewhere as the closest thing to that I can find is: > Benefits: We will have files separated. It’s going to be better.
- jakecodes 9y ago
  I'll add our benchmarks into that issue shortly. Our biggest slowdowns are parsing, layouts, and memory. Without this splitting every file is imported, functions are instantiated but not used. With our new method only files needed are bundled and most of the dispatcher.js file is removed. Removing error prone string matching from switch statements to having it automatically done by webpack. 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.
mwj 9y ago
Jacob that stuff really has no effect on the stability of the CI system and private runners, which is the real problem.

gtirloni 9y ago

It's a side effect of what they are calling "Complete DevOps" https://about.gitlab.com/2017/10/11/from-dev-to-devops/ https://about.gitlab.com/2017/10/11/from-dev-to-devops/

mh-cx 9y ago

Yeah, and they've promised to work on performance for ages now with almost no improvement. 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?

foepys 9y ago
Maybe you are already committed to gitlab and its workflow but Gogs and Gitea are small and fast GitHub clones written in Go if you need something light-weight.
- Kihashi 9y ago
  I'd switch to using one of those, but my team relies on the code review of gitlab.
- stevekemp 9y ago
  Personally I run gitbucket, which is a small and self-contained java-based "github alternative". 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.
lloeki 9y ago
> Is ruby really such a mess that it's impossible to run an app with reasonable memory consumption? 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-years-afff4a54abc7 https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-... [1]: https://twitter.com/migueldeicaza/status/950054181045440518 https://twitter.com/migueldeicaza/status/950054181045440518 [2]: https://twitter.com/lloeki/status/950079609051152384 https://twitter.com/lloeki/status/950079609051152384

user15672 9y ago

They've been promising to fix performance and the UI for years now, so I wouldn't hold out much hope. It's a shame, but there are better open source products so it's not like there are no other options for self hosted.

jhasse 9y ago
IMHO the UI did get better over the years.
- sytse 9y ago
  Thanks. We do think it got a lot better last year https://about.gitlab.com/2017/07/17/redesigning-gitlabs-navigation/ https://about.gitlab.com/2017/07/17/redesigning-gitlabs-navi...
connorshea 9y ago
For what it's worth, in the last year (since January 23, 2017) we've merged ~440 merge requests labeled "performance"[0]. It's not perfect right now and there's still plenty of work to do, but compared to when I started at GitLab almost two years ago it's night-and-day. 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_name%5B%5D=performance&scope=all&sort=created_date&state=merged https://gitlab.com/groups/gitlab-org/-/merge_requests?label_... [1]: https://gitlab.com/gitlab-org/gitaly https://gitlab.com/gitlab-org/gitaly

cweagans 9y ago

Absolutely this. The amount of RAM that I need in order to run Gitlab is greater than the RAM requirements of all of the projects that I would host in a Gitlab instance combined. Fortunately, gogs is a thing.