对此我有两种看法。

1. 不要加载它们 - 我发现了一个 Web 应用程序存在许多问题，其中 DLL 和其他此类对象没有首先加载到内存中。在所有文件“启动”之前同时访问应用程序的两个并发用户会产生一些仅在该实例中发生的非常奇怪的并发问题。如果您的测试目的是在加载时检查这些初始化条件，那么绝对不要先加载它们 DLL。
2. 加载它们 - 对于许多应用程序，应用程序已经启动并运行了一段时间，下次有人点击它时，因此大多数通用性能测试在预加载 DLL 时是最“现实的”。

本质上，两种不同的测试需要两个不同的答案。

两种方式都进行测试，尤其是当用户可能遇到 DLL 没有加载的情况时。

@Tristaan​​ 的回答很好地说明了为什么你真的应该双向进行。

话虽如此，在大多数性能或负载测试中，我们会逐渐增加负载，因为这就是它在现实生活中通常发生的方式。因此，在大多数情况下，随着系统负载的增加，初始加载所有内容的延迟和问题通常不会影响系统在现实世界中的性能。

大约唯一一次系统突然从无到满负载的情况是在“农场”情况下，它以高容量运行并且额外的服务器启动并联机以帮助处理负载（可能发生的事情在动态配置的云环境）。如果这可能在您的情况下发生，那么将该场景也添加到您的测试中。

如果您查看 TPC、SPEC 等提供的任何标准基准测试，您会注意到所有这些测试都包括性能测试中的预热期、满载时间，然后是斜坡下降间隔。此加速期旨在允许在第一次执行时需要编译的代码或要加载的库在进入满载时间间隔之前发生，以测量最佳性能。

这个加速/预热期是商业基准测试领域的最佳实践，市场上有大量糟糕/未经培训的性能测试人员，他们只需几个步骤即可从 0% 负载到 100% 负载，以允许任何类型的热身间隔。对此有一个市场类比，称为“全茶”。它是这样的，“拿一个茶总杯和一瓶伏特加。快速混合。你会得到整个系统的冲击。另一方面，一次拿一个茶总杯、一瓶伏特加和一个装满伏特加的顶针，然后您可能会更顺利地进行测试，并且您也可能会找到随着负载增加而系统崩溃的确切位置......这通常比combine all at once模型更大。”