suprememoocow
Joined 15 years ago
Karma
171
Submissions
49
Member since
Dec 2
Andrew Newdigate, GitLab. Former: Co-founder, CTO at Gitter.
View on Hacker NewsRecent submissions
Comment · 8 years ago
> There is a cookie setting you can use to get some features early on GitLab.com but I can't find a link right now.
Andrew from the Infrastructure team at GitLab here: non-team members are welcome to use our canary service, provided they understand that service may at times we downgraded (they can always switch back to production when this happens).
Details of how to toggle the canary environment can be found in our handbook: https://about.gitlab.com/handbook/engineering/#canary-testin...
Comment · 9 years ago
Repo tree rendering is a known issue that we're currently looking into: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14680
We hope to make improvements in this area soon. Hopefully you'll notice them!
Comment · 9 years ago
I'm the Gitaly Lead at GitLab. Gitaly is a GitLab project to move all the git operations out of the GitLab Ruby monolith into a Git RPC service.
https://gitlab.com/gitlab-org/gitaly/
We're hoping to complete this by the end of the year. Once it's done, we'll be able to end our reliance on NFS, which should greatly improve performance and uptime on GitLab.com and other large GitLab instances. In fact, we're already seeing some big performance payoffs as we bring services online.
> Please please don't get complacent. Not yet.
I can confirm that this is not the case. We're focused and working really hard to improve performance and we're also working hard to improve our metrics, so that we can target optimizations where we can gain greatest benefit.
It's also worth pointing out that routinely experiencing 5+ second render times on browsing a repo homepage is outside our 99th percentile latencies for that route. I'd be interesting in digging into it further. Would you mind creating an issue in https://gitlab.com/gitlab-org/gitaly/issues/new (mark it as confidential if you wish) and ping me `@andrewn`.
Comment · 9 years ago
I'm totally open to that.
I'm not going to be changing anything around the suggestions any time soon, but who should I get in touch with when I do?
Comment · 9 years ago
All public rooms are archived and searchable:
https://gitter.im/gitterHQ/gitter/archives/all https://gitter.im/gitterHQ/gitter/archives/2017/06/14
I agree that chat isn't as digestible as SO, but it is definitely archived.
Comment · 9 years ago
We currently use docker-compose for the development environment. I'm currently simplifying this to allow developers to get started with minimal effort:
https://gitlab.com/gitlab-org/gitter/webapp/blob/feature/mon...
Going forward, I agree that we could offer a more production-like docker-compose setup and/or Kubernetes Helm Charts.
Comment · 9 years ago
We update on a batch[1] fairly infrequently (daily iirc). We don't need exact room membership since the results are aggregated.
> If the application crashes everyone would be kicked out of the channels anyway no
No, Gitter's room membership is persistent (between restarts, crashes and sessions)
1: https://gitlab.com/gitlab-org/gitter/webapp/blob/master/scri...
Comment · 9 years ago
Glad to hear and thank you very much!
Comment · 9 years ago
We haven't done much benchmarking at that end of the scale, but I can't think of any reason why you wouldn't be able to run it on a single server.
Comment · 9 years ago
The big problem with the way we use neo4j is around huge rooms with ~100K users. The number of possible rooms that neo4j has to traverse (even a shallow traversal) for a user in a big room is huge.
Thanks for your recommendations. I'll definitely check them out.
Comment · 9 years ago
Gitter co-founder here: we use neo4j for suggesting rooms.
So, if you're in room A and room B, and most people in those two rooms are also in room C, then we suggest that you join room C.
As I mentioned elsewhere, we also use some non-neo4j based methods for suggestions (including your GitHub graph). One of the problems we've had with neo4j is that we haven't been able to make it scale. It frequently burns up from being overloaded.
This is almost certainly down to the way we use neo4j but at some point I'd like to ditch it for a clustered suggestion algo that uses batch processes to cluster rooms together.
Comment · 9 years ago
From the project page, choose Repository | Charts.
Beware though, it's pretty slow right now.
It might be quicker to just look at a screenshot of it instead http://imgur.com/a/qBGVf
For reference:
JavaScript 86.45 %
CSS 6.79 %
HTML 4.79 %
Shell 1.07 %
Lua 0.82 %
Makefile 0.05 %
Groovy 0.03 %
Python 0.01 %Comment · 9 years ago
Fair enough: this is exactly what we've moved to on Gitter on Gitter since open-sourcing the product.
Comment · 9 years ago
(Gitter Co-founder here)
Unfortunately our neo4j setup as it stands really doesn't scale. At an application-level we're built error-handling to gracefully handle the frequent outages we experience running it.
These are probably our fault, rather than a failing in the product, but I've wanted to replace the current neo4j-based suggestion algo with a new one that uses batching/clustering for a while. As soon as I get a chance, I would like to remove the dependency we have on neo4j.