Problem/Motivation

PHPStan detects the available CPUs when spawning child processes, so if a pod has more spare CPU than requested, it ought to use more than the requested CPUs (not confirmed).

Additionally, a lot of core MRs get a PHPStan cache hit and only scan 1-10 files. Since PHPStan uses one child process per 20 files at a time, this only needs one CPU anyway and there's no benefit to having more.

By reducing the CPU request to 1, we should be able to get a PHPStan pod quicker since it will be able to fit into any available spare capacity. If the PHPStan cache is not used, and the pod also ends up genuinely CPU constrained, then we will probably end up with slower phpstan jobs then, but that should be a tiny fraction of actual runs.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Issue fork drupal-3624454

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

catch created an issue. See original summary.

catch’s picture

Title: Reduce CPU request for PHPStan » Reduce CPU request for linting jobs
Status: Active » Needs review

Broadening the scope a bit - let's try 1 for each. That will hopefully allow the actual linting to start faster, which should mean the whole job finishes faster when it's mostly using the cache, and then we can see how bad it is when more files are changed and always tweak things upwards again if necessary.

smustgrave’s picture

Status: Needs review » Reviewed & tested by the community

Lets try it!

  • mstrelan committed 873db261 on main
    task: #3624454 Reduce CPU request for linting jobs
    
    By: catch
    

  • mstrelan committed a6c226b3 on 12.0.x
    task: #3624454 Reduce CPU request for linting jobs
    
    By: catch
    (cherry...
mstrelan’s picture

Version: main » 12.0.x-dev
Status: Reviewed & tested by the community » Fixed

Committed and pushed 873db2618a8 to main and a6c226b to 12.0.x Thanks!

Doesn't apply cleanly to 11.x, not sure we need to?

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

catch’s picture

Yeah this is mainly for MR run turnaround times I think it's fine to leave it on main/12.0.x.