Improve performance of commits.json action for Projects::MergeRequestsController to s4 tier

Related #30507 (closed)

Performance testing is showing that the Projects::MergeRequestsController#commits.json controller and action is over our target of 500ms under load:

█ Results summary

* Environment:                10k
* Environment Version:        13.13.0-pre `48b385ebb2c`
* Option:                     60s_200rps
* Date:                       2021-05-26
* Run Time:                   3m 20.02s (Start: 10:28:38 UTC, End: 10:31:58 UTC)
* GPT Version:                v2.8.0

NAME                              | RPS  | RPS RESULT        | TTFB AVG  | TTFB P90            | REQ STATUS     | RESULT
----------------------------------|------|-------------------|-----------|---------------------|----------------|----------------
web_project_merge_request_commits | 20/s | 17.21/s (>9.60/s) | 971.10ms  | 1310.14ms (<1750ms) | 100.00% (>99%) | Passed

     http_req_waiting..................................................: avg=971.10ms  min=572.98ms med=874.97ms max=2501.70ms p(90)=1310.14ms p(95)=1755.35ms
     ✓ { controller:Projects::MergeRequestsController#commits.json }...: avg=971.48ms  min=743.35ms med=875.12ms max=2501.70ms p(90)=1313.89ms p(95)=1755.48ms

The results above show that the commits.json action for the Projects::MergeRequestsController controller has a P90 of around 1300ms. This was tested on our 10k Reference Architecture with a RPS target of 20/s. It targeted an MR on our own gitlabhq project that has a high number of commits - 248.

It's worth noting that our test target was recently changed as of 2021-05 to a more realistic one that represents the 99th percentile of MR sizes. The issue has been updated as a result to reflect this.

As per our performance targets this endpoint is above our main target of 500ms and falls under the ~S3 tier. Task is to reduce the endpoint's performance to the severity4 tier (<1000ms).

Edited by 🤖 GitLab Bot 🤖