所以我定义了一个相当简单的AWS Lambda。我使用AWS API Gateway为它创建了一个HTTP GET URL。我在浏览器中部署了它并测试了URL，但它确实有效。然后我创建了一个桌面应用程序来调用URL，它只需要一个查询字符串参数。我连续运行代码以使用不同的查询字符串输入调用URL 100次，并且看到lambda每次平均执行500毫秒。
然后我更改了桌面应用程序以并行发出请求。考虑到最长的执行时间平均为950毫秒，我预计整个时间可能需要1秒左右才能完成。但是，当我这样做时，完成所有请求需要30多秒。
我已经完成了其他测试，知道桌面应用确实是并行发出所有网址请求，因此不是问题。我只是不明白为什么它没有为每个URL请求提供100个lambda以便它们同时执行。似乎请求已缓冲。
每个URL之间的唯一区别是查询字符串参数。在这一点上，我考虑创建100个不同的lambda，每个lambda都使用先前在查询字符串中传递的不同值构建，但每个lambda都有不同的URL，因此我可以实现实际的并发执行。
我错过了什么吗？
答案 0 :(得分：0)
默认情况下，AWS lambda提供高达75的并发执行，i。 e每次可以创建75个lambdas。
编辑：默认情况下，AWS Lambda将给定区域内所有函数的并发执行总数限制为1000.
之前的限制为每Lambda 75。我没有检查最新的并发限制。
如果您需要更多并发性，则需要向AWS团队提出案例。
答案 1 :(得分：0)
并发执行计数将根据您的Lambda函数是否正在处理来自基于流的事件源的事件而有所不同。
非基于流的事件源 - 如果您创建Lambda函数来处理来自非基于流的事件源的事件（例如，Amazon S3或API Gateway），则每个已发布的事件都是工作。因此，这些事件源发布的事件（或请求）的数量会影响并发性。
您可以使用以下公式来估计并发的Lambda函数调用：
events (or requests) per second * function duration
例如，考虑一个处理Amazon S3事件的Lambda函数。假设Lambda函数平均需要3秒，而Amazon S3每秒发布10个事件。然后，您将有30个并发执行Lambda函数。
请求率
请求率是指调用Lambda函数的速率。对于除基于流的服务之外的所有服务，请求率是事件源生成事件的速率。对于基于流的服务，AWS Lambda计算请求率如下：
request rate = number of concurrent executions / function duration
例如，如果流上有五个活动分片（即，您有五个并行运行的Lambda函数），并且Lambda函数大约需要两秒钟，则请求速率为2.5个请求/秒。
来源： - http://docs.aws.amazon.com/lambda/latest/dg/concurrent-executions.html