gygitlab

Thanks for sharing this. I'm part of the team within GitLab's Quality Engineering group that is tasked with performance testing GitLab. We've been working on vastly increasing our performance testing and visibility for about just under a year now.

We know there's work to be done with GitLab's performance and it's a top priority for us moving forward. We've blogged recently on our (Quality) efforts here - https://about.gitlab.com/blog/2020/02/18/how-were-building-u... and you can also see all the issues we've got here - https://gitlab.com/gitlab-org/gitlab/-/issues?label_name[]=Q....

I've been digging into these results today as a priority. While we're using different tooling (k6 and SiteSpeed respectively) and a different methodology (SourceHut is running tests with simulated low bandwidth) our tests are indeed generally showing the same pattern and I've confirmed we have issues raised to cover the problem areas.

Alongside this we identified a few gaps in our performance testing that we wanted to address immediately:

* Our File Blame page (and API) in particular was sobering to witness and we've added that into our tool's tests today (that you should be able to see in our results from tomorrow - https://gitlab.com/gitlab-org/quality/performance/-/wikis/Be...). We've raised 2 top priority issues for that area that will hopefully get tackled soon.

* Our file view page, with larger files, is also not as good as it should be. We've pivoted our tooling to test the worse case scenario today with a much larger file and raised an issue for it also for our dev teams.

As part of the company wide effort to improve our performance I'm always keen to see new tests being done or highlights of areas we haven't been able to cover yet so thanks again for highlighting this and hopefully you'll see our numbers continuing to improve soon!

Many thanks indeed for calling this out. Performance is certainly a key goal for us and as part of the Quality group we've been increasing our performance test efforts over the last year and prioritising performance fixes with our dev teams.

We've investigated and confirmed the controller that's looks to be the cause of this and raised an Issue here - https://gitlab.com/gitlab-org/gitlab/-/issues/214681. Many thanks again.

Hey thanks for the nice comments. I'm the blog's author.

So yeah you're absolutely right there. Rendering performance is equally important. We use a different tool for this - SiteSpeed (that we also offer as an option for users to use in CI - https://docs.gitlab.com/ee/user/project/merge_requests/brows...). We run SiteSpeed pretty much constantly against gitlab.com but this is more for monitoring I believe. We (Quality) are wanting to explore running it in a more general sense against our test environments to start rendering performance testing. Hopefully we'll have more to share on this in the future.

With GPT though we actually updated it recently to increase Web endpoint coverage and this has lead to some pages getting some big performance fixes (the Merge Request Changes page should be rendering a lot faster today than a few months back for example). With the tool we now hit more of these endpoints at scale that deliver the page source, etc... but we can't render with it as it's not a browser (way to heavy to run at scale) hence us looking at starting rendering performance tests as well.

In the meantime I'd love to hear what pages specifically give your old laptop grief?