Update Plan API Urgencies
What does this MR do and why?
Updates urgency on a number of Plan endpoints based on a review of impact. Justification for each is given below.
Urgency Lowered
These endpoints have been identified as breaching their target duration but the said target being inappropriate. Endpoints that breach but are appropriate for improvement (predominantly GraphQL-related) are the subject of a Working Group effort.
| Caller ID | Previous Target | New Target | Why? |
|---|---|---|---|
| GET /api/:version/groups/:id/epics/:epic_iid | 1s | 5s | Legacy Work Item REST API endpoints are not a priority, intended to be eclipsed by the GraphQL Work Items API. A Working Group has been stood up to specifically address performance of the Work Items API is the priority. Main users are automations that run through the weekend and disproportionately spend error budget. |
| GET /api/:version/groups/:id/epics | 1s | 5s | High cardinality. Legacy Work Item REST API endpoints are not a priority, intended to be eclipsed by the GraphQL Work Items API. Working Group stood up to specifically address performance of the Work Items API is the priority. Main users are automations that run through the weekend and disproportionately spend error budget. |
| GET /api/:version/projects/:id/issues/:noteable_id/notes | 1s | 5s | Merge Request notes are already low urgency, I'm not sure why Issues are excluded when the performance will be similar for both and there's a good chance of a similar root cause. The impact for the user is low with a REST endpoint. We should give notes performance some attention but it's not the immediate priority. |
| PUT /api/:version/projects/:id/issues/:noteable_id/notes/:note_id | 1s | 5s | As above. This endpoint is excluded for Merge Requests but not Issues. |
Urgency Raised
A large number of endpoints have been identified as performing better than the target duration of the next urgency level, with 100% consistency. Where possible, we should lock in this improvement by raising the urgency. Effectively this makes this performance level a requirement into the future.
| Caller ID | Previous Target | New Target | Why? |
|---|---|---|---|
| Projects::IterationsController#index | 5s | 1s | Endpoint executes 100% of the time in less than 1s. Iterations are important for the future of our planning tools so we should lock in the improvement. |
| Projects::IterationsController#show | 5s | 1s | Endpoint executes 100% of the time in less than 1s. Iterations are important for the future of our planning tools so we should lock in the improvement. |
| Groups::IterationsController#index | 5s | 1s | Endpoint executes 100% of the time in less than 1s. Iterations are important for the future of our planning tools so we should lock in the improvement. |
| Groups::IterationsController#show | 5s | 1s | Endpoint executes 100% of the time in less than 1s. Iterations are important for the future of our planning tools so we should lock in the improvement. |
| Groups::UploadsController#show | 5s | 1s | Urgency was lowered years ago under different ownership. Endpoint executed 100% of the time in less than 1s. |
| Projects::IssuesController#create | 5s | 1s | Endpoint executes 100% of the time in less than 1s. |
| Projects::IssuesController#edit | 5s | 1s | Endpoint executes 100% of the time in less than 1s. |
| Projects::IssuesController#destroy | 5s | 1s | Endpoint executes 100% of the time in less than 1s. |
References
Screenshots or screen recordings
| Before | After |
|---|---|
How to set up and validate locally
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.