Skip to content

Cache continued tasks during queue maintenance#565

Open
bennettzhu1 wants to merge 1 commit into
jenkinsci:masterfrom
bennettzhu1:upstream-cache-continued-tasks
Open

Cache continued tasks during queue maintenance#565
bennettzhu1 wants to merge 1 commit into
jenkinsci:masterfrom
bennettzhu1:upstream-cache-continued-tasks

Conversation

@bennettzhu1
Copy link
Copy Markdown

Fixes #560

We have seen jenkins queue maintenance spend a lot of time in ContinuedTask.Scheduer.canTake. Queue.maintain already iterates through each buildable and idle executor, and then for each buildable, scans the full buildable queue again to see if any are ContinuedTasks.

To avoid the full buildable loop again, this PR creates a cache of buildable ContinuedTask items. On first pass, populates the map of ContinuedTasks, else it watches the QueueListener to update the cache.

This brings the execution time from (buildable)^2 * idle executors to buildables * idle executors * unique continued tasks. I briefly thought of caching by node to continued task, but it makes updating the cache very messy.

Testing done

We tested it in our staging environment, and we are currently running this patch at my company.

Submitter checklist

  • [ x] Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
  • [ x] Ensure that the pull request title represents the desired changelog entry
  • [ x] Please describe what you did
  • [ NA] Link to relevant issues in GitHub or Jira
  • [ x] Link to relevant pull requests, esp. upstream and downstream changes
  • [ x] Ensure you have provided tests that demonstrate the feature works or the issue is fixed

Queue maintenance calls QueueTaskDispatcher.canTake for each buildable item and idle executor. ContinuedTask.Scheduler previously scanned every buildable item on each call to find continued tasks, making queue maintenance quadratic in the number of buildables.

Maintain a queue-id keyed cache of buildable continued tasks via QueueListener events. The first scheduler call initializes the cache from the current buildable queue, and later queue transitions add or remove entries. Cache entries keep only a weak task reference plus display name and assigned label so stale entries can be dropped during the next scheduler pass.

Add coverage for a cached task that stops being continued.

Fixes jenkinsci#560
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Improving CauseOfBlockage during queue maintenance with cache

1 participant