在传统的性能自动化测试中: 有一个应用程序服务器,其中接收所有请求命中。所以在这种情况下;我们拥有服务器配置(CPU,RAM等),可以使用Jmeter或任何负载测试工具执行负载测试(假设5k并发用户),并检查服务器性能。
对于AWS Serverless,没有服务器-可以这么说-所有服务器都由AWS管理。因此,代码仅驻留在lambda中,并且由AWS决定在运行时执行负载平衡,以防服务器上有大量存储。
所以现在;我们有一个使用无服务器框架托管在AWS上的Web应用程序,并且我们希望针对5K并发用户评估其性能。没有服务器后端信息;这里唯一的选择是依靠前端或基于浏览器的响应时间-这足够吗? 有没有更好的方法来检查无服务器应用程序的性能?
答案 0 :(得分:2)
我没有使用AWS,但是在我看来,无服务器应用程序的性能测试应与使用自己的物理服务器的传统方法完全相同。
尽管名称为无服务器,但仍使用物理服务器(尽管由aws管理)。
因此,我将通过以下步骤来完成此任务:
将后端指标(响应时间,计数请求等)发送到某些指标系统(石墨,普罗米修斯等)
在此度量标准系统中构建仪表板(理想情况下,您应该看到每个实例的请求计数和响应时间以及实例计数)
使用负载测试工具(jmeter,gatling或其他工具)并开始您的负载测试场景
在测试过程中和测试之后,您将看到您的应用处理了多少请求,响应时间以及根据并发请求更改实例的次数。
因此,在这种情况下,您将无法使用aws管理工具(但是aws可能具有一些管理仪表板,之后比较它们的结果将是不错的选择。)
答案 1 :(得分:1)
“无负载测试”无服务器应用程序与传统应用程序不同。这样做的原因是,当您编写将在具有固定CPU和RAM数量的计算机上运行的代码时,许多HTTP请求将在同一台计算机上同时处理。这意味着您可能会遭受“吵闹邻居”的影响,其中一个请求消耗了太多的CPU和RAM,从而对其他请求产生了负面影响。这可能是由于许多原因,包括消耗大量资源的次优代码。尝试解决此问题的方法是启用自动扩展(如果当前服务器上的负载达到某个阈值,则自动启动其他服务器)和负载平衡以将请求分散到多个服务器上。
这就是为什么您需要对传统应用程序进行负载测试的原因;您需要确保编写的代码性能足以应付X数量的访问者涌入,并且基础伸缩系统可以根据需要吸收负载。这也是为什么当您预期流量突然激增时,您会抢先启动其他服务器以帮助提前管理所有负载的原因。问题是您不能总是预测到这一点。一位知名人士在Facebook上提及您的服务后,突然您的系统需要在几秒钟内做出响应,而通常是无法响应。
在无服务器应用程序中,由于多种原因,消除了许多有关计算机中嘈杂邻居的问题:
所有这一切并不是说完成作业以确保您的无服务器应用程序可以处理负载并非没有不可能。您只是做不同的事情。与其尝试在应用程序上推送假用户以查看它是否可以处理它,不如参考文档以了解所使用的各种服务。例如,AWS发布了这些服务的限制,并保证将这些数字作为服务的一部分。例如,API网关每秒限制10 000个请求。您是否希望流量大于每秒10000?如果没有,那你的好!如果您这样做,请联系AWS,他们可能会为您增加该限制。类似的限制适用于AWS Lambda,DynamoDB,S3和所有其他服务。
答案 2 :(得分:0)
正如您所提到的,无服务器架构 (FAAS) 没有物理或虚拟服务器,我们无法监控传统指标。相反,我们可以捕获以下内容:
自动扩展性: 由于这个平台的主要优势是可扩展性,我们需要通过增加负载来检查自动扩展性。
更多请求,更少响应时间: 当遇到大量请求时,传统服务器会增加响应时间,而这种方法会缩短响应时间。我们需要监控响应时间。
Cloudwatch 中的 Lambda 见解: 有一个选项可以监控多个 Lambda 函数的性能 - 限制、调用和错误、内存使用情况、CPU 使用情况和网络使用情况。我们可以在“性能监控”列中配置我们需要和监控的 Lambda。
容器 CPU 和内存使用情况: 在 cloudwatch 中,我们可以创建一个带有小部件的仪表板,以捕获容器的 CPU 和内存使用情况、任务计数和 LB 响应时间(如果有)。