Loading
Raise the GLQL dashboard request concurrency to 6
What does this MR do and why?
This raises the concurrency limit for the GLQL dashboard request queue (glql-queue-dashboard) from 4 to 6 in app/assets/javascripts/glql/core/executor.js. A matching spec assertion in spec/frontend/glql/core/executor_spec.js is updated to match. Nothing else changes, and there is no visible UI change.
This queue controls how many GLQL API requests a viewer's browser keeps in flight at once for the GLQL panels on a single analytics dashboard; requests beyond that limit wait in a client-side queue. On the DAP Impact system dashboard, which has 42 GLQL panels (15 of them also running a trend comparison query), the Overview tab alone sends 12 GLQL requests on load. At a concurrency of 4 that is three rounds of requests; at 6 it is two, if request durations are similar. Pages within a single chart stay sequential, since each page depends on the previous cursor, so this only changes parallelism across panels, not within one panel. Every other analytics dashboard data source (GraphQL and ClickHouse-backed) has no client-side concurrency cap; GLQL panels are the only ones queued this way.
The GLQL API rate limiter (Analytics::Glql::QueryService) keys on the SHA of the GLQL query source and only counts against a query after it hits a statement timeout, so it does not react to concurrency. This change does not touch it. The cost of raising the limit is up to two more concurrent GLQL queries per dashboard viewer against ClickHouse or Postgres.
References
- Related to https://gitlab.com/gitlab-org/gitlab/-/work_items/630507 (DAP Impact V1 performance improvements)
- !256168 (merged) introduced named concurrency queues and gave dashboard GLQL panels their own queue, separate from the default queue, at a concurrency of 4
- !257812 (merged) (open draft) reshapes the same constant table into a
QUEUESstructure withconcurrencyandcacheper queue; whichever of the two merges second will need a trivial rebase on those lines - https://gitlab.com/gitlab-org/gitlab/-/issues/517546 is the GLQL beta readiness commitment that keeps the default queue, used by embedded GLQL blocks in issues, MRs, and comments, at a concurrency of 1; this MR does not touch it
Screenshots or screen recordings
Not applicable, no visible UI change. This only changes how many GLQL requests are in flight at once.
How to set up and validate locally
- Enable the
dap_impact_v1feature flag. - Open
/explore/analytics_dashboards. - Open the DAP Impact dashboard.
- Pick a group in the scope picker.
- Open the browser network tab and filter to
api/glql. - Watch the number of pending requests: up to 6 at once instead of 4.
- Switch tabs on the dashboard to see it again.
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.