8

Azure 函数允许我编写在特定条件下执行的 C#/F#（以及更多）函数。这些函数可以是异步的（通过返回一个任务）。

azure 函数最酷的地方在于，它们会根据负载自动扩展。关于“经典”服务器上的异步/等待模式的一个很酷的事情是，您可以更好地利用内核，以便处理更多请求。

由于 azure 函数会自动扩展，因此编写异步函数对我有什么好处吗？

4

2 回答 2

8

您async在 Azure Functions 中使用的原因与在任何其他应用程序中使用的原因相同。对于阻塞可能长时间运行的外部 I/O 的操作，这将是更有效地利用资源。Azure Functions 完全支持运行时核心中的异步，因此如果使用得当，它将允许在单个 Function App 上实现更多并行性和更好的吞吐量，因为线程不会被阻塞等待 I/O，并且可用于处理更多请求/触发器.

如果您的 Function App 在Classic SKU上运行，那么您需要为 Always On 实例付费，因此很明显您希望尽可能高效地使用资源。

在Dynamic SKU中运行时，我认为您的问题是，如果我们只是根据需要扩展您的功能，那么谁在乎他们是否有效地使用资源？我仍然会说，最好对函数进行编码，以便它们尽可能高效地运行。这样，我们只会在真正需要的时候向外扩展，并在我们启动新实例时最大限度地减少新实例的冷启动时间。

于 2016-10-03T02:54:27.727 回答
8

在动态计划中将异步与 Azure Functions 结合使用时，您仍然会受益。这是因为您的应用程序消耗更少的资源（尤其是线程），使其更高效，因此更便宜。我想到了一些例子：

  • 上下文切换：在运行高度并发的工作负载时，最终会为函数应用实例分配大量线程。更多的线程将导致昂贵的上下文切换，这会增加函数执行的延迟，因此可能会增加您的费用。
  • 线程池增长：如果您有很多线程并且需要添加更多线程，则由于 CLR 如何限制线程池的增长，这可能会为您的函数执行增加额外的延迟。Jon Cole在这里有一个很好的描述：

一旦现有（繁忙）线程数达到“最小”线程数，ThreadPool 将限制每 500 毫秒向一个线程注入新线程的速率。这意味着，如果您的系统需要 IOCP 线程的工作量激增，它将非常快速地处理该工作。但是，如果工作量超过配置的“最小”设置，则在处理某些工作时会有一些延迟，因为 ThreadPool 会等待以下两种情况之一发生： 1. 现有线程可以自由处理工作2. 500ms 内没有现有线程空闲，因此创建了一个新线程。

  • 内存使用：更多线程意味着更高的内存使用。今天你为内存使用的上限支付了一个固定的金额，但是如果将来这改变为基于实际消耗的内存，那么你将为这种不必要的内存开销支付更多的钱。

如果工作量不大，我强烈建议您在函数中利用异步模式。除了上面提到的原因之外，最好不要对平台的容量或动态规模逻辑的效率做出太多假设，因为不准确的假设最终可能会花费你更多的钱。:)

于 2016-10-03T18:05:26.123 回答