12

我试图了解如何使用 azure 函数进行缩放。我们一直在测试一个在存储队列中生成 88 条消息的应用程序，这会触发我们的函数。该函数是用c#编写的。该函数下载一个文件，对其执行一些处理（它最终会将其发回，但出于测试目的我们还没有这样做）。该函数完成每个请求大约需要 30 秒（总共约 2500 秒的处理时间）。出于测试目的，我们将其循环 10 次。

我们的理想情况是，经过一些升温后，Azure 会自动扩展功能，以最方便的方式处理消息。使用某种考虑到启动时间等的算法。或者只是扩大到积压中的消息数量，并设置某种上限。

这是它应该如何工作的吗？我们从来没有超过 7 个“消费单位”。并且通常需要大约 45 分钟来处理消息队列。

其他几个关于可扩展性的问题……我们的函数是一个内存密集型操作，内存如何在函数的缩放实例之间“共享”？我问是因为我们看到了一些我们通常看不到的内存不足错误。我们已经为函数配置了最大内存（1536MB）。看到大约 2.5% 的操作因内存不足错误而失败

在此先感谢您，我们真的希望完成这项工作，因为它可以让我们将大量工作从 EC2 上的专用 Windows VM 转移到 Azure 函数上。

4

1 回答 1

22

目的是该平台会自动为您进行扩展，最终目标是您不必考虑或关心分配给您的函数应用程序的“消耗单元”（有时称为实例）的数量。也就是说，总会有改进的余地，以确保我们为大多数用户提供正确的服务。:)

但是为了回答您关于内部细节的问题（就队列处理而言），我们现在拥有的是一个系统，它检查队列长度和每条消息在被您的应用程序处理之前位于队列中的时间量. 如果我们觉得您的函数应用在处理这些消息方面“落后”了，那么将添加更多的消耗单元，直到我们认为您的应用能够跟上传入的负载。

值得一提的是，除了消费单位的数量之外，规模还有另一个方面。每个消费单元都有能力并行处理许多消息。我们经常看到人们遇到的问题不是分配的消费单元的数量，而是他们工作负载的默认并发配置。查看可以在 host.json 文件中调整的batchSize和newBatchThreshold设置。根据您的工作量，您可能会发现更改这些值后吞吐量会显着提高（在某些情况下，减少并发已被证明可以显着提高吞吐量）。例如，如果每个函数执行需要大量内存，或者如果您的函数依赖于只能处理有限并发访问的外部资源（如数据库），您可能会观察到这一点。可以在此处找到有关这些并发控制的更多文档：https ://github.com/Azure/azure-webjobs-sdk-script/wiki/host.json 。

正如我在上面所暗示的，使用按消耗单位并发可能有助于解决您遇到的内存压力问题。每个消耗单元都有自己的内存池（例如自己的 1.5 GB）。但是，如果您在单个消耗单元中处理太多消息，那么这可能是您看到的内存不足错误的根源。

综上所述，我们一直在努力识别和优化我们认为最常见的某些负载场景，无论是从队列中排出一堆消息，消耗存储容器中的“流” blob，处理一个大量的 HTTP 请求等。随着我们的学习、成熟和从像你这样的人那里获得更多反馈，期待事情会发生变化。向产品组提供此类反馈的最佳位置是在我们的 GitHub 存储库的问题列表中，该列表会定期进行审查。

谢谢你的问题。我希望这些信息对您有所帮助，并且您能够获得您正在寻找的号码。

于 2016-06-08T20:18:04.607 回答