问题标签 [warm-up]

我正在使用 Java 开发一个需要低延迟处理（不到 1 秒）的消息传递系统。但是，JVM 需要预热时间来处理导致延迟增加的第一个输入数据（大约 2~3 秒）。延迟增加的主要原因是类加载。我知道最简单的解决方案是使用虚拟消息提前调用方法。但是，由于系统要求，我不能使用虚拟消息来预热 JVM 。所以我想知道在JVM启动时预加载所有使用的类的方法。

我尝试了强制加载方法的属性

但是，它似乎运行得并不好。JVM 在调用类时仍会加载它们。

我还阅读了其他线程，但没有人指定在 JVM 启动时预加载类的方法。

在 jar 启动时预加载 java 类/库？

最小化Java“热身”时间的技术或实用程序？

我一直在努力使用 Numba，因为每当我为它编写一个函数时，我第一次使用它时都会有很长的预热时间。我想问有没有办法预热 JIT 功能？

例如，如果我将此函数编写y=1/(log(x+0.1))^2为 Numba 函数：

我用这个数组来测试函数的速度：

为了测量函数的执行时间，我使用了这个：

第一次运行需要 0.8 秒，所有后续运行需要 0.001 秒。如果我能以某种方式预热 JIT 函数以避免这种延迟，那就太好了。我尝试将第一次运行与一个小尺寸的虚拟阵列一起使用x_warm=np.random.rand(10)，然后运行f_numba(x_warm)，但预热时间根本没有改变。有什么建议么？

对于完成主义，以下是称为的库：

我正在使用带有 Python 3.7 的 Jupyter Notebook。

我目前正在使用多个 azure function app 实例，带有 "apiVersion": "2015-08-01" 。目前我没有使用任何预热触发器，只有少数功能始终处于“预热”状态，即使重新启动应用程序很快就会进入预热状态，任何有相同经验并找到解决方案的人？

ARM 模板

起动机

问题：在 Sharpoint + BPM 方案中，运行 Windows 2012 和 IIS 8，在应用程序池回收后，任何类型的进程的第一次调用失败，所有后续调用都成功。

从嵌入在 Sharpoint 解决方案中的 ascx 开始，每个进程类型一个 ascx，我们单击一个源自服务器的按钮。转移到创建假装进程类型的新实例的新页面，如果成功，我们从这里响应。使用查询字符串重写重定向到刚刚创建的新流程实例。如果出现错误（回收后的第一个过程），最后一步不会发生。

由于实例化进程的页面是动态的，根据选择的进程类型，它不能在启动解决方案之前预加载，如果我们在启动时强制这些页面的预实例化，我们最终可能会得到在每个新的应用程序池回收（每天一次）时，每个类型的一个虚拟进程。

问题：我怎样才能找到 [MyApp].XMLSerializers.dll 并卸载它，以验证我的理论，即它的缺失是导致第一个进程调用失败的原因？

尝试的解决方案：

• 优化应用程序池和站点配置 无结果
• 搜索 DLL 绑定错误 使用 FUSLOGVW，在回收应用程序池后，似乎在第一次尝试中，[myApp].XMLSerializers.DLL 等丢失了。由于这是一个耗时的步骤，并且在启用跟踪（即使仅针对事件查看器）时不会发生错误，我认为动态生成具有所有可序列化类型的 DLL 可能与此问题有关。

发现：

• 影响不使用 Web 服务的进程
• 当跟踪打开时没有错误
• 影响所有环境

非常感谢任何建议非常感谢，LTS

通过指示自定义初始化，我已经在 IIS 上的应用服务上配置了预热：

当发生自动横向扩展时，所有外部调用都会发送到现有实例，等待新实例完成预热。没关系。

但是我在同一个订阅中有另一个应用服务，但在另一个位置调用我的服务，而无需等待此预热。从逻辑上讲，这些调用太慢了，因为尚未进行热身。

为什么我会有这种行为？

为什么来自外部应用程序的请求会发送到预热的实例，而从另一个 Azure 应用服务运行的请求可以发送到冷实例？

两个应用都在不同的应用服务计划中。