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
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:
- 3624454-reduce-cpu-request
changes, plain diff MR !17189
Comments
Comment #2
catchBroadening 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.
Comment #4
smustgrave commentedLets try it!
Comment #7
mstrelan commentedCommitted and pushed 873db2618a8 to main and a6c226b to 12.0.x Thanks!
Doesn't apply cleanly to 11.x, not sure we need to?
Comment #9
catchYeah this is mainly for MR run turnaround times I think it's fine to leave it on main/12.0.x.