Github Actions Runner核心数疑问及并行测试性能优化咨询

关于Runner核心数的问题 #

Github Actions的托管型Runner（比如ubuntu-latest、windows-latest）默认是2核CPU，不是1核。你遇到的并行测试更慢的问题，核心原因不是Runner只有1核，而是并行配置和资源调度的问题。

为什么并行测试反而更慢？ #

• 进程调度开销大于收益：如果你的测试用例本身比较短小，启动多个测试进程的开销（比如进程初始化、资源分配）会超过并行执行节省的时间。当你指定--processes=4时，进程数超过了Runner的2核上限，会导致CPU频繁在多个进程间切换，额外开销剧增，性能自然更差。
• Docker容器的资源限制：默认情况下，Docker容器会继承宿主（也就是Runner）的资源，但如果没有明确配置CPU配额，容器内的多进程可能无法充分利用Runner的全部核心，加上容器本身的隔离开销，进一步放大了并行的劣势。
• Laravel并行测试的额外瓶颈：Laravel的并行测试会给每个进程分配独立的数据库（默认是基于主库创建临时库），如果数据库操作本身是瓶颈（比如使用磁盘型数据库、迁移脚本耗时），多个进程同时操作数据库会带来锁竞争或IO等待，反而比串行测试更慢。

解决办法 #

• 匹配进程数到Runner核心数：针对托管型2核Runner，指定--processes=2，避免进程数超过核心数导致的上下文切换。命令示例：

  php artisan test --parallel --processes=2
  

• 配置Docker容器CPU资源：在启动Docker容器时，明确指定CPU配额，让容器能使用Runner的全部核心。比如：

  docker run --cpus=2 your-image php artisan test --parallel --processes=2
  

• 优化测试与数据库：
  • 合并小型测试用例，减少进程启动的次数和开销；
  • 改用内存型数据库（比如SQLite的:memory:模式），避免磁盘IO和数据库锁竞争；
  • 优化迁移脚本，减少每个测试进程的初始化时间。
• 使用更高配置的Runner：如果你的测试集确实需要更多核心，可以切换到Github的大型托管Runner（比如ubuntu-latest-large，8核CPU），或者搭建自托管Runner，使用多核物理/云服务器。

内容的提问来源于stack exchange，提问作者Bernard Wiesner