Give dashboard GLQL panels their own request queue
What does this MR do and why?
Every GLQL request in the browser went through one static TaskQueue
with a concurrency of 1 in app/assets/javascripts/glql/core/executor.js.
That queue was shared by GLQL blocks embedded in issue and MR
descriptions and comments (rendered via facade.vue) and by GLQL
panels on analytics dashboards (rendered via
app/assets/javascripts/analytics/analytics_dashboards/components/visualizations/glql.vue).
Dashboard panels loaded strictly one request at a time. The DAP Impact
system dashboard has 42 GLQL panels, 15 of which also run a trend
comparison query, so it issued 57 requests serially. Every other
dashboard data source already fetches its panels in parallel; GLQL
panels were the only ones serialized.
The executor now keeps named queues instead of one static queue.
EXECUTION_QUEUE_DEFAULT (glql-queue-default) keeps a concurrency
of 1 and is what every caller gets unless it asks otherwise.
EXECUTION_QUEUE_DASHBOARD (glql-queue-dashboard) has a
concurrency of 4. GlqlResolver
(app/assets/javascripts/glql/components/common/resolver.vue) gains
a queue prop, defaulting to EXECUTION_QUEUE_DEFAULT, and passes
it on every request it makes: the main query, the comparison query,
and load-more pages. The dashboard visualization binds
:queue="$options.EXECUTION_QUEUE_DASHBOARD", so panels on one
dashboard share that one queue and at most 4 GLQL requests are in
flight per dashboard. Any name the executor does not recognize falls
back to the default queue rather than starting a queue of its own.
Pages within a single chart stay sequential because each page needs
the previous cursor; the parallelism is across panels, not within
one. The linked work item measured that four charts of 566 rows
each, at 6 sequential pages of 3 to 5 seconds, take 80 to 100
seconds serialized at concurrency 1 and about 25 seconds at
concurrency 4, and proposed 3 or 4; this MR uses 4.
The limit of 1 was never a technical limit. It was a production-readiness commitment made for the GLQL beta in GitLab 17.9, introduced in !180921 (merged) after the readiness review at https://gitlab.com/gitlab-org/gitlab/-/issues/517546 (readiness MR gitlab-com/gl-infra/readiness!224 (merged)). The scenario it guards against is a popular description with many GLQL blocks, viewed by many people, hitting Postgres. Embedded blocks keep the default queue and its concurrency of 1, so that behavior is unchanged. Because the limit was a readiness commitment, the linked work item asks that the reviewers on https://gitlab.com/gitlab-org/gitlab/-/issues/517546 get a heads-up before this merges.
This MR implements glql#222 (closed),
filed from a review comment on
!256013 (merged) (chart
auto-pagination). This MR is independent of that one and is based on
master. Both touch the same three execute(...) call sites in
resolver.vue, so whichever merges second will need a small rebase.
References
- glql#222 (closed): work item this MR implements, includes the concurrency measurements
- !256013 (merged): related MR (chart auto-pagination) whose review comment raised this
- !180921 (merged): MR that originally introduced the concurrency-1 limit
- https://gitlab.com/gitlab-org/gitlab/-/issues/517546: readiness review for the GLQL beta; reviewers need a heads-up before this merges
- gitlab-com/gl-infra/readiness!224 (merged): readiness MR for the GLQL beta
Screenshots or screen recordings
There is no visible UI change. Nothing renders differently; panels only finish loading sooner, so there is nothing to screenshot.
| Before | After |
|---|---|
How to set up and validate locally
- Run the Jest suites:
yarn jest spec/frontend/glql spec/frontend/analytics/analytics_dashboards/components/visualizations/glql_spec.js. - On a GDK with ClickHouse, open a dashboard with many GLQL panels, for example the DAP Impact dashboard under
/explore/analytics_dashboards. - Open the browser network tab and filter on
/api/glql. - Before this change, requests are strictly one at a time. After this change, up to four are in flight at once.
- Open an issue or MR description with an embedded GLQL block and confirm it still issues one request at a time.
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.