Hacker News Reader

Comment by merb | Hacker News Reader

Sadly I think the problem of GitLab's sloweness is not the UI framework :( We are 3-5 users on gitlab ce and use 3GB of memory + 4 CPU cores (vCPUs from XEN) and it still feels slow. Even big Java Applikations use less memory, for that amount of users.

View on HN

I recently needed a simple self-hosted git web interface for about 3 people, and I only have a cheap 2GB RAM VPS that also runs other things. After looking at gitlab's requirements, I didn't even try.

Setting up the gitea docker container was so easy (https://docs.gitea.io/en-us/install-with-docker/) and it only takes like 160 MB of RAM plus it's super fast.

Then again, I only needed the more basic features, so I doubt that's gitlab's target audience anyway.

There's also gitbucket built in scala. The UI is much nicer than gitea.

https://gitbucket.github.io/gitbucket-news/gitbucket/2017/01...

running it is simply java -jar gitbucket.war

I don't know, that UI looks a little too "mobile first" to me (for something I would only use on my computer).

EDIT: also, the colors seem quite dull from those screenshots

heh heh.. no real way to win. https://gitlab.com/gitlab-org/gitlab-ce/issues/6057

Nothing wrong with responsive UI, just don't create something meant for phones and then just scale it up to a larger screen. Which is what bootstrap, material design etc. often end up looking like.

For the uninformed (like myself) Gitea is a fork of Gogs.

Hey, thanks for joining in on the conversation.

We agree. It's not just the front-end. We had problems with bot the front-end and back-end. But we're working hard on making things better / more performant on all fronts.

We have an issue specifically about this. https://gitlab.com/gitlab-com/infrastructure/issues/947

My bad there. I though you were referring to GitLab.com

We're planning a bunch of performance improvements for 9.0, which is intended to make GitLab faster for everyone. https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...

I run a private gitlab used by 2-4 users regularly and a few others irregularly.

The biggest issue is the sidekiq process. I've had so much trouble with it hanging that I'm starting to wonder if it's a problem with my VM. But it's one VM in a big vSphere environment and no one else is having problems.

Have you noticed Sidekiq hanging? When it hangs it often says it's using all its jobs, and you can't shut it down without forcing a kill signal.

Are you running the Omnibus packages? They should help by monitoring the Sidekiq process for you.

Yeah, being unable to host Gitlab under 512MB is just too bloaty for me. I know Gogs doesn't have this issue for the same features I use. I still use Gitlab though because it's the mainstream.

well we use it because alternatives that costs money always takes years to finish a simple feature and tell people that they can extend it via their plugin repository.

and we also use it for their CI integration. It's just simpler than setting up a Jenkins instance for simple jobs (well gitlab ci is slower but not so much that it is painful)

GitLab CI is even slower than Jenkins? It's been on my list of alternatives to evaluate, but I guess I'll just push it further down the stack...

I'm not sure why anyone would say GitLab CI is slow. You run it on any machine you want, so it's fully dependent on that.

The script that authenticates and picks up the job is a small Golang app. That's all. GitLab executes CI jobs immediately.

See the architecture and related links here: https://about.gitlab.com/gitlab-ci/#architecture

well gitlab ci is slower on our machine than jenkins. also push based ci might be better for performance when having many workers. while gitlab ci is pull based which can net in negative performance. of course pull based is way less painful when nodes go down/etc..

actually the biggest problems of slowness also comes from docker and caching. I think our docker setup for jenkins/gitlab-ci is not equal. for some jobs we will probably migrate away from docker, as soon as we are able to have a good story for running parallel tests.

It's not noticeably slower, and it's really easy to roll out more workers and expand capacity.

Sorry for the bad experience :(

We're constantly working on improving GitLab's performance, and we have a bunch of issues open for performance fixes/improvements we'll be doing for the upcoming 9.0 release: https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...

Totally agree, maybe they would need UI polishing to make it more user-friendly a la "GitHub". But first priority definitely should be backend speed improvements, not frontend.

Also good backup strategy. :)

Reply on news.ycombinator.com