当你写下你的前几个lambdas时，性能是你最不想要的，你最关心的是权限，安全性，身份和访问管理（IAM）角色和触发器，这些都是为了进行“hello world”试用之后，让您的第一个无服务器能够部署正常运行。但是，一旦您的用户开始依赖您的lambdas提供的服务，就应该专注于高性能无服务器。
当您尝试生产高性能无服务器应用程序时，需要记住以下一些关键事项。
1.可观察性
无服务器处理扩展非常好。但随着规模与复杂性的相互作用，减速和错误是不可避免的。
可观察性不仅仅是日志记录或指标 - 这两者都是无服务器的。您可以深入了解云监视，以便在每次调用lambda时获取日志记录信息，并且AWS控制台提供了充分的方法来查看执行时间，内存使用和其他关键指标的平均值。
但是可观察性是我们如何从外部分析系统而不破解其内部结构。日志记录和指标都不能真正做到这一点，因为日志记录提供的信息太精细，无法告诉您如何处理请求，而度量标准只能指出问题的症状而不是其原因。该解决方案是真实的仪器，可以对跟踪信息进行采样，并为您提供一般和异常数据。
2.想想函数的请求路径
一旦触发一个函数lambda，就寻找各种信息，发出各种Web请求，检查配置文件，获取各种上下文，不要在一个函数中做太多事，注销这个被调用的lambda，寻找可实现你目标的函数。
3.不要重写您的代码
以下列出了常见的谎言：
- “在迭代之前一定要制作一个数组的副本，改变副本会更有效”
- “不要连接字符串，即使它只是两个字符串仍然加入一个数组，这将节省内存”
- “全局变量的性能比良好的变量要糟糕得多”
所有这些都是由善意的人提供的，他们希望帮助人们编写更具性能的JavaScripts。所有这些都忽略了一个基本事实： JavaScript是一种更高阶的语言。
可以通过减少必须执行的操作来改进程序：
- 将多个请求组合到其他服务;
- 当你有足够的匹配时就立即停止循环;
- 返回有用的错误信息;
- 失败优雅。
但除了这些最基本的最佳实践之外，重写代码并不是解决性能问题的方法
4.从本地开始
我认识的每个人在无服务器开发的早期都有类似的经历：当你的lambda开始做一些有点复杂的事情时，你会发现自己对你的配置和功能代码做了几十个小的调整。每次更改时，您都必须等待代码部署，然后堆栈的其余部分才能生效。而不是“保存，构建，刷新”，您的开发周期看起来更像是“保存，打开控制台，部署，等待，刷新，等待，刷新，等待，等待，刷新”
可以复制lambdas和API端点以及许多其他资源到本地docker容器中。
5.本地永远不会复制你的整个堆栈
要真正模拟无服务器流，您需要有一个堆栈来部署代码。
具体情况可能因团队规模而异，但基本上您需要某种阶段或测试版本的堆栈，您可以在其中测试我们的代码。
6.管理代码，而不是配置
创建YAML，管理你的堆栈。