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