Very poor performance creating merge request, regression in 9.0 - often hits 60 seconds timeout on small requests
Summary
Our developers are often unable to create merge requests for particular sets of changes, getting a 502 error. We have to manually review & merge from the command line instead (after manually updated protected branch settings to allow this).
Steps to reproduce
(Chris in gitlab support has credentials to access our githost.io instance. I'm happy for other gitlab staff to do so.)
What is the current bug behavior?
Often get a 502 error after 60 seconds saying:
502
Whoops, GitLab is taking too much time to respond.
Try refreshing the page, or going back and attempting the action again.
Please contact your GitLab administrator if this problem persists.
gitlab support have previously increased our timeout to 5 minutes, and that was sufficient to avoid the issue, however the URLs still took "go away and make a cup of tea" lengths of time to load - and the workaround was lost during an instance upgrade.
I think the performance may actually have got worse in recent versions, as we're hitting this problem multiple times a week in the last few weeks. (I have no idea at what stage the 5 minute timeout workaround would have been lost from our instance.)
What is the expected correct behavior?
Operation should complete in seconds, it should not be necessary to increase the timeout.
The example url given is a 3,500 line diff, so (given the 60 seconds timeout) gitlab is taking over 10ms to process each line, which is a huge amount of time.
Relevant logs and/or screenshots
See support ticket, https://support.gitlab.com/hc/en-us/requests/46108?page=1 for more details.
Output of checks
I don't know what this means?
Results of GitLab environment info
Instance is hosted on githost.io so I can't do this.
The instance is currently running GitLab Enterprise Edition 8.17.0-ee 22400e67 and this issue is reproducible.
Results of GitLab application Check
Instance is hosted on githost.io so I can't do this.
Possible fixes
Unknown