我的实现还是基于 web service，对 lambda 的 event 进行转发。本地启动服务的时候，也能感觉到不是马上就起来的，所以 web service 本身的初始化也是占用不少时间的。如果直接处理 lambda event，就能把这部分时间省下来，缺点是直接绑 aws 上了。这个目前来说我觉得不重要，我也就是大概试一下，有个概念而已。

这方面可能 node 还是有优势吧，另外一个用 rust 写的服务，冷启动也要 1s+ 才返回结果。不过做的事情不一样，不好直接比。基于 web service 的实现，本身服务的启动速度非常敏感。而对传统的 web 框架来说，服务启动的时间不敏感。我回头还得再试个 py，这样做对比的时候有数字说话。我们公司其他人都还处于在想象的阶段，真正用过 lambda 的没几个人

另外 java 也是这个月初刚获得了一个免费的技术升级，大幅提高冷启动的速度。个人认为理论上 .net 也大同小异，估计下一个就会得到优化了。

【 在 keygen 的大作中提到: 】
: 频繁 scale 波动，cold start的话，的确比较麻烦，比不上 aot 的和解析语言
: 据说 java 在 lambada 上更快点，不知道为什么，都是类似的处境
: 之前看文章有些人迁移到了 Container App，保留一个 instance 常驻来解决这个问题
: ...................
--
修改:eGust FROM 222.153.59.*
FROM 222.153.59.*