Azure Functions 的缩放算法是什么（从未能够获得超过 7 个并行实例 运行）
What is the scaling algorithm for Azure Functions (never been able to get over 7 parallel instances running)
我正在尝试了解如何使用 azure 函数进行缩放。我们一直在测试一个在存储队列中生成 88 条消息的应用程序，这会触发我们的功能。该函数是用 C# 编写的。该函数下载一个文件，对其进行一些处理（它最终会 post 它返回，但出于测试目的我们还没有这样做）。每个请求完成该函数大约需要 30 秒（总共处理约 2500 秒）。出于测试目的，我们将其循环 10 次。
我们的理想情况是，经过一些预热后，Azure 会自动扩展功能，以最方便的方式处理消息。使用某种算法，考虑到启动时间等。或者只是扩大到积压中的消息数量，并设置某种上限。
这是它应该的工作方式吗？我们从未能够获得超过 7 个“消耗单位”。处理消息队列一般需要 45 分钟左右。
关于可伸缩性的其他几个问题……我们的函数是内存密集型操作，内存如何在函数的缩放实例之间“共享”？我问是因为我们看到了一些我们通常不会看到的内存不足错误。我们已经为该函数配置了最大内存 (1536MB)。看到大约 2.5% 的操作因内存不足错误而失败
提前致谢，我们真的很期待这项工作，因为它可以让我们将大量工作从 EC2 上的专用 windows 虚拟机转移到 Azure 功能上。
目的是让平台自动为您扩展，最终目标是您不必考虑或关心 "consumption units"（有时称为 实例 ) 分配给您的函数应用程序。也就是说，总会有改进的余地，以确保我们为大多数用户提供正确的服务。 :)
但是为了回答你关于内部细节的问题（就队列处理而言），我们现在拥有的是一个检查队列长度和每条消息在被您的应用程序处理之前在队列中的等待时间。如果我们认为您的函数应用正在 "falling behind" 处理这些消息，则会添加更多消耗单位，直到我们认为您的应用能够跟上传入的负载。
值得一提的是，除了消费单位的数量之外，还有另一个方面的规模。 每个消费单元都有能力并行处理多条消息。我们经常看到人们遇到的问题不是分配的消费单元的数量，而是他们工作负载的默认并发配置。查看 batchSize 和 newBatchThreshold 设置，可以在 host.json 文件中对其进行调整。根据您的工作负载，您可能会发现更改这些值后吞吐量明显提高（在某些情况下，减少 并发已被证明可以显着提高吞吐量）。例如，如果每个函数执行都需要大量内存，或者如果您的函数依赖于只能处理有限并发访问的外部资源（如数据库），您可能会观察到这种情况。可以在此处找到有关这些并发控制的更多文档：https://github.com/Azure/azure-webjobs-sdk-script/wiki/host.json.
正如我在上面暗示的那样，玩每消耗单位并发可能有助于解决您一直遇到的内存压力问题。每个消耗单元都有自己的内存池（例如它自己的 1.5 GB）。但是，如果您在单个消费单元中处理太多消息，那么这可能是您看到的内存不足错误的根源。
综上所述，我们一直在努力识别和优化我们认为最常见的某些负载场景，无论是从队列中排出一堆消息，还是消耗 "stream" 个 blob在存储容器中，处理大量 HTTP 请求等。随着我们学习、成熟并从像您这样的人那里获得更多反馈，期望事情会发生变化。向产品组提供此类反馈的最佳位置是 our GitHub repo's issue list，它会定期审核。
感谢提问。我希望这些信息对您有所帮助，并且您能够获得您正在寻找的号码。
我正在尝试了解如何使用 azure 函数进行缩放。我们一直在测试一个在存储队列中生成 88 条消息的应用程序，这会触发我们的功能。该函数是用 C# 编写的。该函数下载一个文件，对其进行一些处理（它最终会 post 它返回，但出于测试目的我们还没有这样做）。每个请求完成该函数大约需要 30 秒（总共处理约 2500 秒）。出于测试目的，我们将其循环 10 次。
我们的理想情况是，经过一些预热后，Azure 会自动扩展功能，以最方便的方式处理消息。使用某种算法，考虑到启动时间等。或者只是扩大到积压中的消息数量，并设置某种上限。
这是它应该的工作方式吗？我们从未能够获得超过 7 个“消耗单位”。处理消息队列一般需要 45 分钟左右。
关于可伸缩性的其他几个问题……我们的函数是内存密集型操作，内存如何在函数的缩放实例之间“共享”？我问是因为我们看到了一些我们通常不会看到的内存不足错误。我们已经为该函数配置了最大内存 (1536MB)。看到大约 2.5% 的操作因内存不足错误而失败
提前致谢，我们真的很期待这项工作，因为它可以让我们将大量工作从 EC2 上的专用 windows 虚拟机转移到 Azure 功能上。
目的是让平台自动为您扩展，最终目标是您不必考虑或关心 "consumption units"（有时称为 实例 ) 分配给您的函数应用程序。也就是说，总会有改进的余地，以确保我们为大多数用户提供正确的服务。 :)
但是为了回答你关于内部细节的问题（就队列处理而言），我们现在拥有的是一个检查队列长度和每条消息在被您的应用程序处理之前在队列中的等待时间。如果我们认为您的函数应用正在 "falling behind" 处理这些消息，则会添加更多消耗单位，直到我们认为您的应用能够跟上传入的负载。
值得一提的是，除了消费单位的数量之外，还有另一个方面的规模。 每个消费单元都有能力并行处理多条消息。我们经常看到人们遇到的问题不是分配的消费单元的数量，而是他们工作负载的默认并发配置。查看 batchSize 和 newBatchThreshold 设置，可以在 host.json 文件中对其进行调整。根据您的工作负载，您可能会发现更改这些值后吞吐量明显提高（在某些情况下，减少 并发已被证明可以显着提高吞吐量）。例如，如果每个函数执行都需要大量内存，或者如果您的函数依赖于只能处理有限并发访问的外部资源（如数据库），您可能会观察到这种情况。可以在此处找到有关这些并发控制的更多文档：https://github.com/Azure/azure-webjobs-sdk-script/wiki/host.json.
正如我在上面暗示的那样，玩每消耗单位并发可能有助于解决您一直遇到的内存压力问题。每个消耗单元都有自己的内存池（例如它自己的 1.5 GB）。但是，如果您在单个消费单元中处理太多消息，那么这可能是您看到的内存不足错误的根源。
综上所述，我们一直在努力识别和优化我们认为最常见的某些负载场景，无论是从队列中排出一堆消息，还是消耗 "stream" 个 blob在存储容器中，处理大量 HTTP 请求等。随着我们学习、成熟并从像您这样的人那里获得更多反馈，期望事情会发生变化。向产品组提供此类反馈的最佳位置是 our GitHub repo's issue list，它会定期审核。
感谢提问。我希望这些信息对您有所帮助，并且您能够获得您正在寻找的号码。