Click to expand/collapse
\n\n\n![](\"docs/Architecture.gif\")
\n\n- Serverless-artillery generates the requests to run the specified tests using load generator Lambda function, which is deployed and invoked on AWS along with other assets.\n - Naming format is `
![](\"docs/HowItWorks.jpg\")
\n\n* Serverless-artillery would be installed and run on your local machine. From command line run `slsart --help` to see various serverless-artillery commands.\n* It takes your JSON or YAML load script (`script.yml`) that specifies \n * test target/URL/endpoint/service\n * load progression\n * and the scenarios that are important for your service to test.\n* When you run `slsart deploy` command, serverless-artillery deploys a **load generator Lambda function**, on your AWS account along with other assets.\n* Running the tests\n * **Performance test:** When you run `slsart invoke` command, serverless-artillery would invoke the load generator Lambda function.\n * It would generate the number of requests as specified in `script.yml` to specified test target in order to run the specified scenarios.\n * **Acceptance test:** When you run `slsart invoke -a` command, serverless-artillery would invoke the load generator Lambda function in acceptance test mode where it runs each scenario in your script exactly once and reports the results.\n * **Monitoring:** When you customize the deployment assets to turn on monitoring and deploy those assets using `slsart deploy` command, the load generator Lambda function is invoked in monitoring mode once a minute 24x7 where it runs each scenario in your script 5 times and sends an alert if it detects a problem. \n* When you run `slsart remove` command, serverless-artillery would remove these assets from your AWS account.\n* When you run `slsart kill` command, serverless-artillery would kill the in-progress test and remove these assets from your AWS account.\n\n## Technologies powering serverless-artillery\n\n\n### Serverless Framework\n- The [Serverless Framework](https://serverless.com) makes managing (deploying/updating/removing) cloud assets easy.\n- It translates a `yaml` file to deployable assets of the target cloud provider (like AWS).\n- Serverless-artillery uses it to manage required assets to your cloud account.\n\n### Artillery.io\n- [Artillery.io](https://artillery.io/) (built by Hassy Veldstra of shoreditch-ops) is an existing open-source node package, built for easy load testing and functional testing of a target/service/endpoint/URL. It provides a simple but powerful means of specifying how much load to create and what requests that load should comprise.\n- It takes in a developer-friendly JSON or YAML load script that specifies \n - target/URL/endpoint\n - load progression\n - and the scenarios that are important for your service to test.\n- It generates specified load, and measures and reports the resulting latency and return codes.\n- It generates the load by running on your local machine or servers.\n- However, if you specify more load in your script than what can be produced on your machine, artillery will throttle down the load specified in your script. While it is simple to distribute artillery across a fleet of servers, you must then manage, coordinate, and retire them. It is not a serverless solution. This is the task that serverless-artillery steps in to remove from your plate.\n\n### Serverless-artillery\n- Serverless-artillery allows your script to specify an amount of load far exceeding the capacity of a single server to execute.\n- It breaks that script into smaller chunks (sized for a single instance of load generator Lambda function) and distribute the chunks for execution across multiple instances of load generator Lambda function.\n- Since this is done using a FaaS provider, the ephemeral infrastructure used to execute your load disappears as soon as your load tests are complete.\n\n
\n\n\n\n\n- Serverless-artillery generates the requests to run the specified tests using load generator Lambda function, which is deployed and invoked on AWS along with other assets.\n - Naming format is `
\n\n```\n# Thank you for trying serverless-artillery!\n# This default script is intended to get you started quickly.\n# There is a lot more that Artillery can do.\n# You can find great documentation of the possibilities at:\n# https://artillery.io/docs/\nconfig:\n # this hostname will be used as a prefix for each URI in the flow unless a complete URI is specified\n target: \"http://aws.amazon.com\"\n phases:\n -\n duration: 5\n arrivalRate: 2\nscenarios:\n -\n flow:\n -\n get:\n url: \"/\"\n\n```\n\n
\n\n\n```\n# We're excited that this project has provided you enough value that you are looking at its code!\n#\n# This is a standard [Serverless Framework](https://www.serverless.com) project and you should\n# feel welcome to customize it to your needs and delight.\n#\n# If you do something super cool and would like to share the capability, please open a PR against\n# https://www.github.com/Nordstrom/serverless-artillery\n#\n# Thanks!\n\n# If the following value is changed, your service may be duplicated (this value is used to build the CloudFormation\n# Template script's name)\nservice: serverless-artillery-XnBa473psJ\n\nprovider:\n name: aws\n runtime: nodejs10.x\n iamRoleStatements:\n # This policy allows the function to invoke itself which is important if the script is larger than a single\n # function can produce\n - Effect: 'Allow'\n Action:\n - 'lambda:InvokeFunction'\n Resource:\n 'Fn::Join':\n - ':'\n -\n - 'arn:aws:lambda'\n - Ref: 'AWS::Region'\n - Ref: 'AWS::AccountId'\n - 'function'\n - '${self:service}-${opt:stage, self:provider.stage}-loadGenerator*' # must match function name\n # This policy allows the function to publish notifications to the SNS topic defined below with logical ID monitoringAlerts\n - Effect: 'Allow'\n Action:\n - 'sns:Publish'\n Resource:\n Ref: monitoringAlerts # must match the SNS topic's logical ID\nfunctions:\n loadGenerator: # !!Do not edit this name!!\n handler: handler.handler # the serverlessArtilleryLoadTester handler() method can be found in the handler.js source file\n timeout: 300 # set timeout to be 5 minutes (max for Lambda)\n environment:\n TOPIC_ARN:\n Ref: monitoringAlerts\n TOPIC_NAME:\n 'Fn::GetAtt':\n - monitoringAlerts\n - TopicName\n events:\n - schedule:\n name: '${self:service}-${opt:stage, self:provider.stage}-monitoring' # !!Do not edit this name!!\n description: The scheduled event for running the function in monitoring mode\n rate: rate(1 minute)\n ########################################################################################################################\n ### !! BEFORE ENABLING... !!!\n ### 0. Change `'>>': script.yml` below to reference the script you want to use for monitoring if that is not its name.\n ### The script must be in this directory or a subdirectory.\n ### 1. Modify your `script.yml` to provide the details of invoking every important surface of your service, as per\n ### https://artillery.io/docs\n ### 2. Add a `match` clause to your requests, specifying your expectations of a successful request. This relatively\n ### undocumented feature is implemented at: https://github.com/shoreditch-ops/artillery/blob/82bdcdfc32ce4407bb197deff2cee13b4ecbab3b/core/lib/engine_util.js#L318\n ### We would welcome the contribution of a plugin replacing this as discussed in https://github.com/Nordstrom/serverless-artillery/issues/116\n ### 3. Modify the `monitoringAlerts` SNS Topic below, uncommenting `Subscription` and providing subscriptions for any\n ### alerts that might be raised by the monitoring function. (To help you out, we've provided commented-out examples)\n ### (After all, what good is monitoring if noone is listening?)\n ### 4. Deploy your new assets/updated service using `slsart deploy`\n ### 5. [As appropriate] approve the subscription verifications for the SNS topic that will be sent following its creation\n ########################################################################################################################\n enabled: false\n input:\n '>>': script.yml\n mode: monitoring\nresources:\n Resources:\n monitoringAlerts: # !!Do not edit this name!!\n Type: 'AWS::SNS::Topic'\n Properties:\n DisplayName: '${self:service} Monitoring Alerts'\n# Subscription: # docs at https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-sns-subscription.html\n# - Endpoint: http://