<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=345482) </details> <!--IssueSummary end--> The following discussion from !74058 should be addressed: - [ ] @reprazent started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/74058#note_728047459): > All of these endpoints are dependant on the size of the blob in question. All of the endpoints besides the `show` one aren't very busy. So those are fine to lower the urgency. > > The `BlobController#show` however is quite busy, but it's not performing all that bad. The past 7 days, it had a success ratio of 99.8% for a 1s threshold. This is below the 99.95% target, so it weighs on the budget because it's so busy. I think the most of the time spend is likely also syntax highlighting. (Based on the `cpu_is` in https://log.gprd.gitlab.net/goto/7c42d2f426419589f1951f42ae7f600b). > > It looks like this endpoint is actually doing different things depending on the format: https://log.gprd.gitlab.net/goto/aa6f4400c3a08bb6cbf98413d3e8e0a1 > > The `json` version seems to perform much better than the html variant. What do you think about doing this increase temporarily, and create an issue to break up the endpoint for both behaviours? Then we could have the `low` urgency only for the apparently slower html variant. It will also make investigating _what exactly_ is slow for both sides.