问题描述
今天，我们在单个c5.9xlarge EC2实例中作为C应用程序运行，并在EC2实例上的所有线程之间共享任务。
任务：
- 在100％cpu约束下，没有I / O或外部交互，它们进行了大量计算。
- 是100％独立的，执行任务之间没有关系/依赖性。
- 仅使用少量内存。
- 完成后，生成一些输出。所有任务的输出都被合并/合并为单个响应有效载荷，该响应有效载荷在json中小于3kb。
响应有效负载必须包含100％的任务，对于丢失的任务输出没有容忍度。
在当前体系结构忽略网络跳的情况下，处理时间不到1.5秒。
我正在考虑将此移植到AWS Lambda，因为：
- 请求稀疏/断断续续，并且长时间不活动
- Lambda可能更便宜-当我将开发，测试，质量保证和生产等考虑在内时，EC2实例的成本就成了问题 Lambda可能更具伸缩性-在当前架构下，需要单个EC2实例来处理单个请求。如果我想同时处理7个请求（在无效活动期间），则需要配置7个EC2实例。考虑到我的响应时间为1.5秒，在这种情况下，我认为动态ec2缩放没有帮助。
- 也许可以使用Lambda来提高性能（将响应时间从1.5秒降低），或者通过运行1000多个任务（但仍在1.5秒内）来提高计算精度。
我认识到AWS Lambda支持的语言(Java,Go,PowerShell,Node.js,C#,Python,and Ruby code)不太可能像C一样快，但是我认为通过集中精力进行优化，任务处理时间的差异将很小，并且可以弥补Lambda具有更大的潜在并发性。我很高兴使用任何语言。老实说，这个问题的重点不是语言的选择，而是体系结构。我确实意识到，不同的语言实现将具有不同的特征regarding startup time and execution time。
我最初的想法是散开每个任务以作为单独的Lambda运行，然后合并结果。
我注意到this article的作者描述了仅调用 await lambda.InvokeAsync（）大约50ms的阻塞延迟。这本身可能是满足我的性能要求的一个障碍。
我还想知道是否应该通过将1000个任务请求消息写入队列并允许触发1000个Lambda来同时处理它们来使用基于队列的体系结构。但是然后我需要合并结果，大概是通过将所有输出写入另一个SQS，结果处理器可以在其中合并它们。实际上，我将同时运行多个请求，因此架构需要扩展以支持该请求。
我知道默认情况下AWS Lambda是restricted to 1000 concurrent invocations per account，但是我知道可以通过请求AWS支持来增加这一点。
正如您所看到的，还有很多未知数，AWS Lambda能否最终满足我的性能要求（在1.5秒内完成1000个任务），如果可以，推荐的架构是什么，尤其是关于扇出-聚集的架构的响应。
解决方法
暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！
如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。
小编邮箱:dio#foxmail.com (将#修改为@）