HTTP 调用需要 4 分钟以上才能在 Azure Functions 上看到它

Question

自上周以来，我们在向 Azure 函数发出 HTTP 请求时开始看到奇怪的行为。

一些背景：

• 这是一个 Linux 计划，在 P1v3 层、1 个实例上运行，自创建资源以来始终打开。使用 Azure 的 SSL。
• C# 中的 HTTP 触发功能，匿名授权，GET 请求，没有属性或任何其他无意中阻止调用的内容。
• 自定义域映射，DNS 由 Cloudflare 解析。
• 我们使用的是 IoT 设备，当设备注册用户操作时，该设备会发出此 HTTP 调用。
• 为了便于理解，example.company.com 是我们遇到困难的主机名，我们将在下面的观察中引用备用主机名 example2.company.com。

观察

• 如果我们映射 2 个子域 example.company.com 和 example2.company.com 指向同一个应用服务，无论我们在硬件中使用哪个主机名，该服务都需要超过 4 分钟才能触发。
• 如果我们仅设置 1 个子域 example2.company.com 映射并删除 example.company.com，该服务将按预期从硬件运行。
• 我们对设备固件使用了调试器实用程序，调用过程没有延迟。
• 我们使用 Wireshark 嗅探流出的流量，我们看到调用是由硬件发出的，没有延迟，但它们不会很快调用功能
• 我们尝试使用10多个硬件设备，在所有硬件设备上都是相同的效果。
• 当我们尝试从 Postman 或 C# 控制台应用程序发出相同的请求时，它的延迟时间为 <1s
• 我们还从同一个办公室进行邮递员呼叫，该办公室的硬件基本上与 ISP 相同，并且邮递员呼叫顺利进行，但从硬件发送的电话则不然。

行动

• 我们检查了硬件上的固件以及用于 HTTP 通信的芯片，看起来是最佳的，并且由于一年多前没有进行任何修改，因此没有在上面花费过多的时间。
• 我们尝试在 Azure 上查看遥测数据，联系 Azure 支持，并能够排除 Azure 服务或 Azure 中的任何内容作为可能的根本原因。如果我们可以研究更具体的东西，很高兴得到一些提示。
• 我们通过尝试识别任何改进来检查 Azure Functions，但我们正在最新的 Azure Functions 运行时上运行，无论如何，除了来自硬件的调用之外，其他调用都可以正常进行。
• 如果这只是一个 DNS 解析项目，请等待 Cloudflare 的支持票证响应。我们会受到 1 个子域的 DNS 解析的影响吗？看起来很奇怪！！

Answer 1

我想与社区分享，真正有效的是提高 Azure Function App 的规模。我们采用应用服务计划类型的托管，并且生产中的实例数为 1，我们注意到了该问题。如果我们扩大到 2 或更高的计数，问题就会得到控制。

我们尝试了一些方法，包括运行 dotnet profiler 来识别资源消耗代码，以及作为真实场景对超过 10 万用户进行负载测试。

到目前为止，最理想的方法是转向 Elastic Premium 计划 作为主机层的选择，并将在我们改进这一点并确定实际情况时分享进一步的更新。

尽管它不是专门针对 DNS 或基础设施的，但在我们的测试中发现该函数是一个非静态函数。通常当你创建一个新函数时，它会被修饰为静态。

我们会看到，即使我们使用 azurite [本地模拟器]，HTTP 函数也需要 3 秒以上才能触发。在 Azurite 上，我们看到了多个 409，经过调查我们发现情况就是这样，因为该函数必须获取主机锁租约。

我们创建了一个新的项目，从头开始创建功能来模拟效果等等。

最后，有效的是，如果将函数修饰为静态，则可以修复此租约锁定问题并按预期立即触发。

在[![在此处输入图像描述][1]][1]之前

[![在此处输入图像描述][2]][2]之后

这一更改解决了我们一直在 Azure 上的 DNS 和其他技术领域进行挖掘的问题。