### Problem to solve Making lots of small IO calls to Gitaly is a bad access pattern. This is magnified for customers using NFS where each Gitaly call could cost 200ms regardless of the Git command. We need to address the worst IO access patterns so that NFS performance is tolerable while we wait for HA Gitaly https://gitlab.com/groups/gitlab-org/-/epics/842 ### Further details There are many customers using Gitaly with NFS for high availability, which makes the problem of N+1 issues more pronounced because disk access is slower on NFS. Resolving N+1 issues is important so that customers using NFS don't experience unacceptably poor performance over the next 6+ months while they wait for Gitaly HA and coordinate deployment of Gitaly HA. After bringing back a subset of Rugged, performance reached an acceptable level: https://gitlab.com/gitlab-org/gitlab-ce/issues/57317 - this should be the starting point for reducing Gitaly IO calls. ### Proposal - MergeRequestsController#ci_environment_status (JSON) ~Verify https://gitlab.com/gitlab-org/gitlab-ce/issues/38632 - PipelinesController#show (JSON) ~Verify https://gitlab.com/gitlab-org/gitlab-ce/issues/38632 - Projects::CommitsController#signatures ~Create https://gitlab.com/gitlab-org/gitlab-ce/issues/57658 - `/api/v4/projects/:id?per_page=100` ~Create https://gitlab.com/gitlab-org/gitlab-ce/issues/57113 https://gitlab.com/gitlab-org/gitlab-ce/issues/51363 - `/api/v4/groups/:id/projects?per_page=100` ~Create https://gitlab.com/gitlab-org/gitlab-ce/issues/57113 https://gitlab.com/gitlab-org/gitlab-ce/issues/51363 Refer to [priorities board](https://gitlab.com/groups/gitlab-org/-/boards/812893?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Gitaly%20n%2B1) for current prioritization.