41–50 of 114 posts
Did you consider trying NewSQL DBs that would let you scale horizontally with much less complexity? Curious to see if the performance is comparable yet.
Are you talking about NoSQL databases, like Mongo and Redis?
for anyone new to gitlab, it is a bear. even their own cluster/HA documentation is mostly just a thin roadmap to a final goal. a statement of intent if you will. There are just far too many moving parts in this software and the glaring problem of "ruby doesnt scale well" is everpresent. packaged releases depend entirely on a bundled chef installation to get everything out the door and running. The software tries to d…
> and the glaring problem of "ruby doesnt scale well" is everpresent GitLab has many performance problems (and many have been solved over the years), but Ruby has thus far not been one of them.
For anyone needing a small Git Web UI, I suggest https://github.com/go-gitea/gitea.
EDIT: Oh, you're that guy ^^;.
Anyway, my rant was probably a bit harsh. I know that GitLab isn't really written for hardware comparable to a Raspberry Pi and that it's used by small and large teams all over the world. But on my hardware Gitea renders pages in 20-100 ms, which is orders of magnitude faster than GitLab. I'm sure part of this is the fault of the language.
Its just that Postgres may need a little more coding and is less automatic than MySQL that people shy away from it..
I do like the time and information spent about spreading load accross database servers and not nearly enough people are considering splitting reads and writes from a master/slave setup.
Its just that its frustrating to me that engineers view databases as some sort of mysterious black box that you need to solve by working around it or replacing it entirely.
Other options available: - CockroachDB 1.1 - AWS RDS Aurora PostgreSQL-compatibility [1] https://news.ycombinator.com/item?id=15458900 [2] https://news.ycombinator.com/item?id=13072861
CockroachDB is a really cool product, but I think by all accounts it is still nowhere near performant enough to be used in production.
Earlier quoted context omitted.
> and the glaring problem of "ruby doesnt scale well" is everpresent GitLab has many performance problems (and many have been solved over the years), but Ruby has thus far not been one of them.
I remember installing GitLab on a small NAS-type box. It was a while ago, but on each start-up it ran a nodejs tool to pre-compile some assets, I suppose. On that machine, it took 10-15 minutes to start. Afterwards, the unicorn workers kept getting killed because the default memory limit (128 MB) wasn't enough to process more than literally a couple of requests. It did work, but pages took 2-5 seconds to load, which…
Earlier quoted context omitted.
> and the glaring problem of "ruby doesnt scale well" is everpresent GitLab has many performance problems (and many have been solved over the years), but Ruby has thus far not been one of them.
I remember installing GitLab on a small NAS-type box. It was a while ago, but on each start-up it ran a nodejs tool to pre-compile some assets, I suppose. On that machine, it took 10-15 minutes to start. Afterwards, the unicorn workers kept getting killed because the default memory limit (128 MB) wasn't enough to process more than literally a couple of requests. It did work, but pages took 2-5 seconds to load, which…
Apparently I should stop using gitlab.com By choosing to not shard your data you have basically put a cap on scalability... or at least one which will be reached faster than if you were to decide to shard.
It's interesting to see what parts of the product GitLab is struggling with compared to GitHub, e.g. https://githubengineering.com/stretching-spokes/
Earlier quoted context omitted.
No, because it probably would have required a complete rewrite of GitLab to make it work.
User mentioned "trying". With an app that gets this much use, it might be reasonable to take a small piece and fork all writes to both the current + an experimental DB and then A/B test the reads. If this type of abstraction requires "a complete rewrite of GitLab" for "trying NewSQL DBs" then something is amiss.
Earlier quoted context omitted.
CockroachDB is a really cool product, but I think by all accounts it is still nowhere near performant enough to be used in production.
Alternative is Google Spanner. Also still new, but already in GA for 5 months now.