git submodule update的--jobs选项如何选择合理取值

官方文档基础定义：--jobs 选项仅对 git submodule update 命令生效，作用是指定并行克隆新子模块的任务并发数，默认读取 submodule.fetchJobs 配置项的取值。

针对官方文档未覆盖的常见使用疑问，逐一说明如下：

• 是否需要将--jobs参数值设置为当前仓库子模块的总数量，比如传--jobs $GIT_SUBMODULES_COUNT？
  不需要。该参数控制的是同时运行的克隆任务上限，不是要求一次性启动和子模块数量相等的任务。如果你的环境（网络、磁盘、CPU）最多支撑4个并发任务跑满资源，哪怕你有50个子模块，设成50也只会让大量任务同时争抢资源，拖慢整体速度。只有当子模块总数远低于环境可承载的并发上限时，设为子模块总数才不会有额外开销，常规使用完全不需要特意统计子模块总数来凑参数值。

• 设置极大的参数值（比如--jobs 1000）能不能获得性能提升？有什么限制和负面影响？
  不能，反而大概率拖慢速度甚至导致克隆失败。
  并发数的收益存在明确上限，主要受三类约束：

  1. 网络带宽约束：每个克隆任务占用独立网络连接，并发数超过带宽承载阈值后，单任务速率会被均匀分摊，整体传输速度不会上升，反而会因为大量TCP连接握手、重传的额外开销增加总耗时
  2. 本地资源约束：每个克隆进程独立占用内存、CPU、磁盘IO资源，并发过高会导致磁盘IO打满、CPU上下文切换开销暴增，甚至触发系统进程数、文件句柄数上限，直接导致部分子模块克隆报错
  3. 服务端约束：几乎所有Git托管服务都有单IP并发连接限制，短时间发起数百个克隆请求会触发限流，严重时会被临时拦截IP，导致拉取完全中断。
     实际使用中，机械盘环境建议设2_{4，SSD环境设4}8，公网拉取设4~16，内网高带宽场景最高也不建议超过32，超过这个区间没有任何性能收益。

• submodule.fetchJobs配置项的作用是什么？为什么在旧版官方文档里找不到相关描述？
  这个配置是Git用于设置子模块拉取、克隆操作默认并发数的选项，不止git submodule update会读取，执行带--recurse-submodules参数的git fetch/git pull操作时，也会用这个值作为默认并发数。旧版Git官方文档存在遗漏，没有收录这个配置项的说明，高版本Git文档已经补全了相关描述。
  如果需要长期固定并发数，不需要每次执行命令都传--jobs，可以直接全局配置，比如设置全局默认并发为8：

git config --global submodule.fetchJobs 8

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