Skip to content

Speed up several project lists

What does this MR do?

It speeds up loading of the dashboard/projects page:

Cache pipeline status for the dashboard

Before we were were getting the HEAD-commit for displaying the CI-status, this caused us to access the repository to get the head commit, and query for the status of the pipeline for that commit. Now we only do that the first time, and store the required results in redis.

The cache is updated when calling Pipeline#update_status and when a pipeline in an after_create callback for the pipeline.

before: Screen_Shot_2017-03-13_at_10.41.05 after: Screen_Shot_2017-03-14_at_13.41.19

So that already saves ~44 queries on my machine.

Eager load routes

before: Screen_Shot_2017-03-14_at_15.31.58

after: Screen_Shot_2017-03-14_at_15.33.20

A lot queries for routes were repeated, so eager loading them shaved another ~20 queries off on my machine.

The result of doing this on in the Explore::ProjectsController isn't so dramatic, but this is after all the other inprovements:

before: Screen_Shot_2017-03-15_at_12.41.55

after: Screen_Shot_2017-03-15_at_12.50.42

Improve cache keys for the _project.html.haml partial

From the entire objects being used as a cache_key like here to somthing smaller:

---
- groups/4-20170305124542531931000
- projects/7-20170313133958915964000
- projects
- index
- application_settings/3-20170305124259672320000
- v2.3
- pipeline-status/588440f66559714280628a4f9799f0c4eb880a4a-success

The results for this aren't really measurable on my local setup.

Are there points in the code the reviewer needs to double check?

Are there other places we need to invalidate the cache for the pipeline status?

Why was this MR needed?

To improve the performance of Dashboard::ProjectsController

Screenshots (if relevant)

Does this MR meet the acceptance criteria?

What are the relevant issue numbers?

#27376 (closed) #27390 (closed)

Merge request reports