postman程序如何加载
When you mention load testing to a software engineer, nine times out of 10 you see a slight wince in their face. Why? Because historically, load tests have been painful.
当您向软件工程师提及负载测试时，十分之九的测试人员会感到有些畏缩。 为什么？ 因为从历史上看，负载测试一直很痛苦。
Building automated test scripts is tedious, developers didn’t think about performance at scale during the initial build, and nobody knows how to address the issues that crop up as a result.
构建自动化测试脚本非常乏味，开发人员在最初的构建过程中并未考虑大规模的性能，而且没人知道如何解决随之而来的问题。
Sounds like a recipe for disaster. Necessary disaster, but a mess nonetheless.
听起来像是灾难的秘诀。 必然的灾难，但还是一团糟。
Enter serverless. If you’ve built your app using FaaS (Functions as a Service), you’re in luck. You likely already know about the numerous benefits of AWS Lambda, but you can add easy to load test on there now too.
输入无服务器。 如果您使用FaaS(功能即服务)构建了应用程序，那么您会很幸运。 您可能已经知道AWS Lambda的众多好处，但是现在您也可以在其中添加易于加载的测试 。
A core tenet behind serverless apps is to be API first, which means you are able to fully exercise the system via endpoints. All you need in order to load test is just a way to chain these requests together to build your test scripts.
无服务器应用程序背后的核心原则是首先使用API，这意味着您可以通过端点完全行使系统的职能。 加载测试所需的一切只是将这些请求链接在一起以构建测试脚本的一种方法。
Once you have your test scripts, you need a tool that can run them at scale. Our good friends at AWS have provided us with a tool that does just that.
一旦有了测试脚本，就需要一个可以大规模运行它们的工具。 我们在AWS上的好朋友为我们提供了一个可以做到这一点的工具。
Lastly, you need to be able to monitor the system health while the load test is running. Guess what? AWS has us covered on that too.
最后，您需要能够在负载测试运行时监视系统运行状况。 你猜怎么了？ AWS也对此进行了介绍。
使用邮递员构建测试脚本 (Use Postman to Build Your Test Scripts)
Postman is going to act as your script builder. You should have a set of business processes that you want to see perform under load, and Postman is going to help orchestrate that.
邮递员将充当您的脚本生成器。 您应该具有一组希望在负载下执行的业务流程，而Postman将帮助您进行协调。
If you already use Postman and have collections built that run through business processes — great! You can use those without any additional setup. If you do not, I would highly recommend using the Postman Interceptor and walking through some of the business processes.
如果您已经使用Postman并构建了可在业务流程中运行的集合 ，那就太好了！ 您可以使用它们而无需任何其他设置。 如果您不这样做，我强烈建议您使用Postman Interceptor并逐步完成一些业务流程。
The interceptor will record all the requests made through your browser, leaving you with a collection that does exactly what your application does. All you have to do afterward is parameterize the requests (if necessary) so they can properly chain together for multiple runs.
拦截器将记录通过浏览器发出的所有请求，从而为您提供一个集合，该集合可以完全执行您的应用程序的工作。 之后，您要做的就是将请求参数化(如有必要)，以便它们可以正确地链接在一起以进行多次运行。
When you have your collection configured to your liking, export it to JSON as a collection v2.1.
将集合配置为自己喜欢的样式后，将其作为集合v2.1导出到JSON。
配置负载测试工具 (Configuring the Load Testing Tool)
We are going to be using the load testing mechanism created by AWS. Out of the box, it does not support Postman collections, but we can quickly modify it to run out collections via Postman’s CLI — Newman.
我们将使用AWS创建的负载测试机制 。 开箱即用，它不支持Postman馆藏，但是我们可以通过Postman的CLI Newman快速修改它以耗尽馆藏。
Follow the deployment instructions on the webpage to deploy the stack of load testing resources into your AWS account. While the stack is deploying, we can take on the code changes needed to support Postman.
按照网页上的部署说明，将负载测试资源堆栈部署到您的AWS账户中。 在部署堆栈时，我们可以进行支持Postman所需的代码更改。
Clone the GitHub repository for the AWS load testing tool and navigate to the .\source\container folder. Next, do the following steps:
克隆适用于AWS负载测试工具的GitHub存储库 ，然后导航到.\source\container文件夹。 接下来，执行以下步骤：
- Take the exported Postman collection JSON and add it to the folder. 以导出的Postman集合JSON并将其添加到文件夹中。
Add a new file called
test.jsonwith the following contents:添加一个名为
test.json的新文件，其内容如下：
You can change the value in iterations on line 5 to however many times you want your collection to run.
您可以将第5行的iterations的值更改为希望集合运行的次数。
The script value on line 11 is going to be the name of your exported collection from Postman.
第11行的script值将是您从Postman导出的集合的名称。
3. Update Dockerfile to include the new JSON files
3.更新Dockerfile以包括新的JSON文件
At this point, we are done editing the source. Now we need to push our changes into ECS.
至此，我们已经完成了源代码的编辑。 现在，我们需要将更改推送到ECS中。
在AWS中更新负载测试 (Updating the Load Tests in AWS)
By now, the stack we deployed into AWS should have finished. We can now go into the ECS service and navigate to the Amazon ECR Repositories link on the lefthand side of the page.
到目前为止，我们部署到AWS中的堆栈应该已经完成。 现在，我们可以进入ECS服务并导航至页面左侧的Amazon ECR存储库链接。
Select the load testing repository in your list to bring up the list of images.
在列表中选择负载测试存储库以显示图像列表。
From here, you want to click on the View push commands button in the upper right to get a set of commands specific to your repository. There are four commands given to update the repository with our changes.
在这里，您想单击右上角的“ View push commands按钮以获取特定于存储库的一组命令。 提供了四个命令来使用我们的更改来更新存储库。
On your local machine, open up a command prompt and navigate to the .\source\container folder. Copy and paste the four commands given to you by AWS in order to update the image.
在本地计算机上，打开命令提示符，然后导航到.\source\container文件夹。 复制并粘贴AWS提供给您的四个命令以更新映像。
After the commands finish running, we’re ready to run the tests!
命令运行完毕后，我们就可以运行测试了！
运行负载测试 (Running the Load Test)
After the stack finished deploying, you should have gotten an email with a username, password, and link to the load testing dashboard. Go find that email, click on the console link, and sign in with the given credentials.
堆栈完成部署后，您应该已经收到一封包含用户名，密码和负载测试仪表板链接的电子邮件。 找到该电子邮件，单击控制台链接，然后使用给定的凭据登录。
Hit the Create Test button at the top of the page to navigate to the load testing setup. Fill out the Name, Description, and Task Count fields with values you want for your test.
点击页面顶部的Create Test按钮以导航到负载测试设置。 用您想要测试的值填写“名称”，“描述”和“任务计数”字段。
The changes we made to the Dockerfile and test.json have made the Concurrency, Ramp Up, Hold For, and HTTP endpoint under test fields useless, but they are still required in order to submit the form. Simply fill out the fields with any values you want — they will be ignored when you hit submit.
我们对Dockerfile和test.json所做的更改使测试字段下的Concurrency ， Ramp Up ， Hold For和HTTP终结点无效，但是仍然需要它们才能提交表单。 只需使用所需的任何值填写字段-当您单击Submit时，它们将被忽略。
The Task Count field is going to spin up X amount of containers in your cluster to run your collection. Fargate has a limit of 100 containers running at a time, but this form has a limit of 50. If you wish to increase the throughput to 100, you can open up the browser dev tools and change the limit from 50 to 100.
Task Count ( 任务计数)字段将增加集群中X个容器的数量，以运行您的集合。 Fargate一次只能运行100个容器，但此表单的最大数量是50。如果要将吞吐量提高到100，可以打开浏览器开发工具并将极限从50更改为100。
When you hit the Submit button, it will spin up all the containers and start executing your Postman collection!
当您点击Submit按钮时，它将旋转所有容器并开始执行Postman收藏！
监控方式 (Monitoring)
While the load test is running, you’re going to want to monitor the performance of your application. There are two areas we want to watch for with serverless apps:
在负载测试运行时，您将要监视应用程序的性能。 我们希望在无服务器应用程序中注意两个方面：
- How the infrastructure scales 基础架构如何扩展
- How your code handles scaling 您的代码如何处理扩展
To do this, we can make two CloudWatch graphs to monitor in real-time.
为此，我们可以制作两个CloudWatch图进行实时监控。
基础架构扩展 (Infrastructure Scaling)
We want to take a look at API Gateway and Lambda functions across the board. If our app doesn’t handle load graciously, we will get throttling events and the app will become sluggish and non-responsive.
我们想全面了解API网关和Lambda函数。 如果我们的应用程序无法轻松处理负载，我们将收到节流事件，并且该应用程序将变得缓慢且无响应。
In Cloudwatch, navigate to the Metrics console. Click on Lambda metrics > Across All Functions. You want to enable ConcurrentExecutions, Durations, Errors, Invocations, and Throttles.
在Cloudwatch中 ，导航到Metrics控制台。 单击Lambda指标>所有功能。 您要启用ConcurrentExecutions ， Duration ， Errors ， Invocations和Throttles 。
Next, we want to view the ApiGateway > Across All APIs > Count metric.
接下来，我们要查看ApiGateway>所有API>计数指标。
Click on the Graphed metrics tab and change the statistic type and period to match the image below.
单击“图形化指标”选项卡，然后更改统计信息类型和期间以匹配下图。
As far as infrastructure scaling goes, this is going to cover the majority of a serverless app. If you use other AWS services, feel free to add other metrics. The graph will update in real-time to show you values across all these stats.
就基础架构扩展而言，这将涵盖大多数无服务器应用程序。 如果您使用其他AWS服务，请随时添加其他指标。 该图将实时更新，以向您显示所有这些统计信息中的值。
应用扩展 (Application Scaling)
You also want to see if your app is throwing any errors during the test. Since the system is being exercised through API Gateway, we want to monitor the responses of our API messages.
您还想查看您的应用在测试过程中是否抛出任何错误。 由于系统是通过API网关执行的，因此我们希望监视API消息的响应。
In a new CloudWatch graph, you want to view the 4XXError and 5XXError metrics for all of your APIs. Click on ApiGateway > By Api Name > filter for 4xx and select all results.
在新的CloudWatch图表中，您要查看所有API的4XXError和5XXError指标。 单击ApiGateway>按Api名称>过滤4xx然后选择所有结果。
Remove the filter and do the same thing for 5XX.
拆下过滤器，对5XX做同样的事情。
If you run into any throttling issues with the AWS services your lambda functions are using, they are bound to turn up as a 400 or 500 response through your API.
如果您的lambda函数使用的AWS服务遇到任何限制问题，则它们肯定会通过您的API变成400或500响应。
These two graphs will show you the health of your serverless app as it scales through the load testing. If you see errors start to crop up, you can modify the graphs to show specific lambda functions and start digging into logs.
这两个图形将向您展示无服务器应用程序在负载测试过程中的运行状况。 如果发现错误开始大量出现，则可以修改图形以显示特定的lambda函数，并开始挖掘日志。
结论 (Conclusion)
Load testing doesn’t have to be hard. You want to see if your application performs as seamlessly at scale as it does in a development environment.
负载测试不必很困难。 您想查看您的应用程序是否能像在开发环境中那样无缝地大规模执行。
Postman enables you to record and playback your business process through the browser. It is a one for one copy of what is going to be done in the field.
Postman使您可以通过浏览器记录和回放业务流程。 这是该领域要完成工作的一对一副本。
AWS enables you to scale that playback and hit your application with thousands of requests a minute. It also provides you a mechanism to view the health of your app as it scales to adjust to the workload.
AWS使您能够扩展该回放并每分钟以数千个请求命中您的应用程序。 它还提供了一种机制，可以根据应用程序的规模进行调整以适应工作负载，从而查看其运行状况。
To top it all off, when you’re done with the load testing, you have a pretty good understanding of how much your app is going to cost to run. As I’ve written about before, forecasting serverless costs can be difficult, but this can be regarded as a source of truth. Test the system with a production workload and view the cost breakdown via the AWS billing service.
最重要的是，在完成负载测试后，您对应用程序的运行成本有了很好的了解。 如我之前所写， 预测无服务器成本可能很困难 ，但这可以视为事实的来源。 使用生产工作负载测试系统，并通过AWS计费服务查看成本明细。
Don’t skip load tests. When your app hits prime time, you need to know it’s going to perform. You’ve already made the right choice by choosing serverless to build your app. Let’s tie a bow on it and prove how well it performs at scale.
不要跳过负载测试。 当您的应用达到黄金时段时，您需要知道它将会执行。 通过选择无服务器来构建应用程序，您已经做出了正确的选择。 让我们鞠躬，证明它在大规模上的表现。
Have fun!
玩得开心！
postman程序如何加载
扫一扫
1126
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
