https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/26248 added
support for deduplicating FindCommit requests using Gitaly ref name
caching. However, not all endpoints were covered, and in one case the
Gitaly wrapper wasn't actually surrounding the serialization step. We
can safely cache ref names between FindCommit calls for #index and #show
endpoints for merge requests and pipelines. This can significantly
reduce the number of FindCommit requests.
For each pipeline, the controller will call `Pipeline#latest?` to
determine if the pipeline's ref is the latest for that branch.
Since it's likely that the same branches are being used in each
pipeline, we can reduce Gitaly overhead by caching the results
of the FindCommit call.
Updates specs to use new rails5 format.
The old format:
`get :show, { some: params }, { some: headers }`
The new format:
`get :show, params: { some: params }, headers: { some: headers }`
This adds a database migration that creates routes for any projects and
namespaces that don't already have one. We also remove the runtime code
for dynamically creating routes, as this is no longer necessary.
This adds Keyset pagination to GraphQL lists. PoC for that is
pipelines on merge requests and projects.
When paginating a list, the base-64 encoded id of the ordering
field (in most cases the primary key) can be passed in the `before` or
`after` GraphQL argument.
When displaying a project's pipelines
(Projects::PipelinesController#index) we now exclude the coverage data.
This data was not used by the frontend, yet getting it would require one
SQL query per pipeline. These queries in turn could be quite expensive
on GitLab.com.
When displaying the project pipelines dashboard we display a few tabs
for different pipeline states. For every such tab we count the number of
pipelines that belong to it. For large projects such as GitLab CE this
means having to count over 80 000 rows, which can easily take between 70
and 100 milliseconds per query.
To improve this we apply a technique we already use for search results:
we limit the number of rows to count. The current limit is 1000, which
means that if more than 1000 rows are present for a state we will show
"1000+" instead of the exact number. The SQL queries used for this
perform much better than a regular COUNT, even when a project has a lot
of pipelines.
Prior to these changes we would end up running a query like this:
SELECT COUNT(*)
FROM ci_pipelines
WHERE project_id = 13083
AND status IN ('success', 'failed', 'canceled')
This would produce a plan along the lines of the following:
Aggregate (cost=3147.55..3147.56 rows=1 width=8) (actual time=501.413..501.413 rows=1 loops=1)
Buffers: shared hit=17116 read=861 dirtied=2
-> Index Only Scan using index_ci_pipelines_on_project_id_and_ref_and_status_and_id on ci_pipelines (cost=0.56..2984.14 rows=65364 width=0) (actual time=0.095..490.263 rows=80388 loops=1)
Index Cond: (project_id = 13083)
Filter: ((status)::text = ANY ('{success,failed,canceled}'::text[]))
Rows Removed by Filter: 2894
Heap Fetches: 353
Buffers: shared hit=17116 read=861 dirtied=2
Planning time: 1.409 ms
Execution time: 501.519 ms
Using the LIMIT count technique we instead run the following query:
SELECT COUNT(*)
FROM (
SELECT 1
FROM ci_pipelines
WHERE project_id = 13083
AND status IN ('success', 'failed', 'canceled')
LIMIT 1001
) for_count
This query produces the following plan:
Aggregate (cost=58.77..58.78 rows=1 width=8) (actual time=1.726..1.727 rows=1 loops=1)
Buffers: shared hit=169 read=15
-> Limit (cost=0.56..46.25 rows=1001 width=4) (actual time=0.164..1.570 rows=1001 loops=1)
Buffers: shared hit=169 read=15
-> Index Only Scan using index_ci_pipelines_on_project_id_and_ref_and_status_and_id on ci_pipelines (cost=0.56..2984.14 rows=65364 width=4) (actual time=0.162..1.426 rows=1001 loops=1)
Index Cond: (project_id = 13083)
Filter: ((status)::text = ANY ('{success,failed,canceled}'::text[]))
Rows Removed by Filter: 9
Heap Fetches: 10
Buffers: shared hit=169 read=15
Planning time: 1.832 ms
Execution time: 1.821 ms
While this query still uses a Filter for the "status" field the number
of rows that it may end up filtering (at most 1001) is small enough that
an additional index does not appear to be necessary at this time.
See https://gitlab.com/gitlab-org/gitlab-ce/issues/43132#note_68659234
for more information.
Uses `list_commits_by_oid` on the CommitService, to request the needed
commits for pipelines. These commits are needed to display the user that
created the commit and the commit title.
This includes fixes for tests failing that depended on the commit
being `nil`. However, now these are batch loaded, this doesn't happen
anymore and the commits are an instance of BatchLoader.
Now, when requesting a commit from the Repository model, the results are
not cached. This means we're fetching the same commit by oid multiple times
during the same request. To prevent us from doing this, we now cache
results. Caching is done only based on object id (aka SHA).
Given we cache on the Repository model, results are scoped to the
associated project, eventhough the change of two repositories having the
same oids for different commits is small.
The pipeline was quite meagre in both stages and the number of groups.
This has been improved. Performance is not yet optimal, but to limit
this from sliding further this slippery slope, a hard limit has been
set.
GitLab Bot
Alex Ives
Matija Čupić
gfyoung
Stan Hu
Kamil Trzciński
Rémy Coutable
blackst0ne
Michael Kozono
Steve Azzopardi
Yorick Peterse
Bob Van Landuyt
Douwe Maan
Alexis Reigel
Grzegorz Bizon
Kamil Trzciński
Zeger-Jan van de Weg
Jacopo
Mike Greiling
Robert Speicher
Lin Jen-Shin
Oswaldo Ferreira
Zeger-Jan van de Weg
Luke "Jared" Bennett
Shinya Maeda
Douwe Maan
Filipa Lacerda