So one of the issues with Git is that just about any Git related command ends up being very chatty in terms of disk IO, i.e. a git show whatever isn’t just a single IO operation, it’s a whole bunch of them. When you end up running a forge for many users, this can wreak havoc in terms of performance and outages. Loading non-Git data (e.g. issues) from Git makes this even worse, especially if a project the size of say Kubernetes were to use it (e.g. they have about 50 000 issues in total).
How would Haxy handle that? That’s not some sort of “haha gotcha!” question, rather I’m seeing new forges pop up over the last two years or so but few of them seem to actually try to plan ahead/learn from all the scaling horror stories of GitHub, GitLab and others, so I’m curious if Haxy is any different in that regard.
So one of the issues with Git is that just about any Git related command ends up being very chatty in terms of disk IO, i.e. a
git show whateverisn’t just a single IO operation, it’s a whole bunch of them. When you end up running a forge for many users, this can wreak havoc in terms of performance and outages. Loading non-Git data (e.g. issues) from Git makes this even worse, especially if a project the size of say Kubernetes were to use it (e.g. they have about 50 000 issues in total).How would Haxy handle that? That’s not some sort of “haha gotcha!” question, rather I’m seeing new forges pop up over the last two years or so but few of them seem to actually try to plan ahead/learn from all the scaling horror stories of GitHub, GitLab and others, so I’m curious if Haxy is any different in that regard.
score 1 · canonical