Merge Request Discussions API is slow with high discussions items count

Summary

Performance testing has found the Merge Requests Discussions API has slow performance when there's a high amount of Discussion items (~165 in our test data). On a target 10k reference environment testing has found the endpoint to typically take between 2 to 3 seconds to return, which is considered too high.

Most endpoints return under 500ms so any that stand out like this are to be raised and investigated.

Environment:    10k (12.3.5-ee 9dbaa740018)
Scenario:       60s_200rps
Date:           2019-10-14
Run Time:       1691.07s (Start: 01:42:13 UTC, End: 02:10:24 UTC)

NAME                                                     | DURATION | P95        | RPS                  | SUCCESS RATE   | RESULT
---------------------------------------------------------|----------|------------|----------------------|----------------|-------
api_v4_projects_merge_requests_merge_request_discussions | 60.0s    | 3185.82ms  | 102.77/s (>112.00/s) | 100.00% (>95%) | Failed

Steps to reproduce

  1. Check out the Performance Toolkit
  2. Run the specific test with the run-k6 command. For example against the 10k environment you would run this following from the project root: ./run-k6 -e environments/10k.json -s scenarios/60s_200rps.json -t tests/api_v4_projects_merge_requests_merge_request_discussions.js. You will need an ACCESS_TOKEN for this endpoint as well - also covered in docs but give me a shout for the token to use against our 10k environment.
  3. If you're seeking to run the test against your own environment the Toolkit's documentation has details on how to achieve this.

What is the current bug behavior?

The API is slow with higher amounts of discussion items (>150). Testing has found it to be around 2 to 3 seconds on our certified 10k architecture.

What is the expected correct behavior?

That the API responds inline with other endpoints performance, typically under 500ms.