为何JMeter中显式调用嵌入资源比Retrieve All Embedded Resources更快？

• 并行下载能力差异：第一种脚本的并行下载数固定为6，而第二种的20个独立请求可以同时并发执行（只要JMeter线程组的并发配置允许），更高的并行度直接提升了资源下载的整体速度。
• 省去HTML解析延迟：自动抓取嵌入资源的模式下，JMeter需要先完整接收并解析主请求的HTML响应，才能识别出所有嵌入资源并发起请求，这个解析过程会产生额外的等待时间。而显式请求是预先定义好的，主请求完成后可立即批量发起，没有解析环节的开销。
• 连接复用效率更高：显式的独立HTTP请求更容易复用已建立的HTTP长连接（若开启了keep-alive），而自动抓取模式下JMeter对连接复用的处理可能更保守，部分资源请求可能会新建连接，增加TCP握手的耗时。同时显式请求可以统一配置连接池、超时等优化策略，进一步提升效率。
• 避免冗余请求：自动抓取模式可能会误抓页面中不需要的资源（比如隐藏DOM元素引用的、重复加载的资源），而显式请求是精准控制的，只请求你需要的20个资源，减少了无效请求的时间消耗。
• 内部调度逻辑差异：JMeter的自动抓取逻辑是在主请求的后置处理阶段触发的，这部分任务的调度优先级低于独立的HTTP采样器，导致资源请求发起的时机被延迟。而独立请求作为单独的采样器，调度更直接高效，没有内部逻辑的额外延迟。

内容的提问来源于stack exchange，提问作者Sébastien M