我对 azure 函数的可扩展性期望过高吗？

Question

我在由服务总线主题触发的消费计划上有一个 azure 函数运行，然后简单地将另一条消息添加到队列中（因此基本上不进行任何处理，仅进行 IO）。触发主题以约 1000/秒的速度填充。天真地以为功能可以轻松跟上，但实际上已经无可救药了，主题订阅很快就满了。我已经运行几个小时了，所以我怀疑它已经完全横向扩展了。

我应该从函数中获得多少性能？每秒几千的吞吐量是不可能的吗？

编辑： 我经常在日志中看到这个错误：

The connection attempt lasted for a time span of 00:00:00. TCP error code 10013: An attempt was made to access a socket in a way forbidden by its access permissions.

看起来功能在大规模服务总线上表现不佳？

为解决方案编辑 2 替换此绑定：

public static async Task Run(BrokeredMessage msgin, Binder binder, TraceWriter log)
{
 var collector = await binder.BindAsync<IAsyncCollector<BrokeredMessage>>(
                new ServiceBusAttribute("my-queue"));

...
}

有了这个：

public static IAsyncCollector<BrokeredMessage> collector;
public static async Task Run(BrokeredMessage msgin, Binder binder, TraceWriter log)
{
     collector = collector ?? await binder.BindAsync<IAsyncCollector<BrokeredMessage>>(
                new ServiceBusAttribute("my-queue"));


    ...
}

防止套接字耗尽，功能跟上生产者没问题。

Answer 1

一些问题：

您的服务总线连接字符串是否有管理权限？目前有效扩展需要管理权限。
您使用的是 input/output 绑定，还是您自己管理服务总线客户端？
您是否修改了 host.json 中的服务总线并发设置？

您看到的错误与连接耗尽有关，因此您的函数实例运行可用连接不足。

如果您想获得有关函数缩放和吞吐量的遥测数据，您可以试一试：https://github.com/Azure/Azure-Functions/wiki/App-Insights-Early-Preview

Answer 2

我的 Azure 函数遇到了同样的问题。根本原因是我用尽了所有端口，因为我在运行方法中创建了一个 TCP 连接。

所以当同一台机器上有很多并行执行时，它们都会创建连接，最终耗尽所有端口。

在那种情况下，连接是作为创建 ServiceBus 客户端的一部分创建的，并将其移至静态变量解决了该问题。

我对 azure 函数的可扩展性期望过高吗？

Am I expecting too much scalability from azure functions?

azure

azure-functions