Skip to content

Commit c0192ec

Browse files
committed
Merge remote-tracking branch 'origin/master' into onlycoldstarts
# Conflicts: # lambda/utils.js # template.yml # test/unit/test-utils.js
2 parents dd14172 + c384dec commit c0192ec

26 files changed

+833
-469
lines changed

.github/workflows/tests.yml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -22,6 +22,6 @@ jobs:
2222
- run: npm run coverage
2323

2424
- name: Coveralls
25-
uses: coverallsapp/github-action@v1
25+
uses: coverallsapp/github-action@v2
2626
with:
2727
github-token: ${{ secrets.GITHUB_TOKEN }}

CHANGELOG.md

Lines changed: 50 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,50 @@
1+
## CHANGELOG (SAR versioning)
2+
3+
From most recent to oldest, with major releases in bold:
4+
5+
* *4.3.4* (2024-02-26): upgrade to Nodejs20, custom state machine prefix, SDKv3 migration, new includeOutputResults input parameter, JSON loggin support
6+
* *4.3.3* (2023-10-30): parametrized currency for visualization URL (USD|CNY)
7+
* *4.3.2* (2023-08-16): new disablePayloadLogs flag, updated documentation
8+
* *4.3.1* (2023-05-09): update dependencies, add VPC Configuration support, use Billed Duration instead Duration from logs, update state machine with ItemSelector
9+
* ***4.3.0*** (2023-03-06): SnapStart support (alias waiter)
10+
* *4.2.3* (2023-03-01): fix layer runtime (nodejs16.x)
11+
* *4.2.2* (2023-02-15): configurable sleep parameter, bump runtime to nodejs16.x, docs updates, GH Actions, and minor bug fixes
12+
* *4.2.1* (2022-08-02): customizable SDK layer name and logs retention value
13+
* ***4.2.0*** (2022-01-03): support S3 payloads
14+
* *4.1.4* (2022-01-03): sorting bugfix and updated dependencies
15+
* *4.1.3* (2021-12-16): support simple strings as event payload
16+
* *4.1.2* (2021-10-12): add x86_64 fallback when Graviton is not supported yet
17+
* *4.1.1* (2021-10-12): fixed connection timeout for long-running functions
18+
* ***4.1.0*** (2021-10-11): support Lambda functions powered by Graviton2
19+
* ***4.0.0*** (2021-08-16): support AWS Lambda states expansion to all functions
20+
* *3.4.2* (2020-12-03): permissions boundary bugfix (Step Functions role)
21+
* *3.4.1* (2020-12-02): permissions boundary support
22+
* ***3.4.0*** (2020-12-01): 1ms billing
23+
* *3.3.3* (2020-07-17): payload logging bugfix for pre-processors
24+
* *3.3.2* (2020-06-17): weighted payloads bugfix (for real)
25+
* *3.3.1* (2020-06-16): weighted payloads bugfix
26+
* ***3.3.0*** (2020-06-10): Pre/Post-processing functions, correct regional pricing, customizable execution timeouts, and other internal improvements
27+
* *3.2.5* (2020-05-19): improved logging for weighted payloads and in case of invocation errors
28+
* *3.2.4* (2020-03-11): dryRun bugfix
29+
* *3.2.3* (2020-02-25): new dryRun input parameter
30+
* *3.2.2* (2020-01-30): upgraded runtime to Node.js 12.x
31+
* *3.2.1* (2020-01-27): improved scripts and SAR template reference
32+
* ***3.2.0*** (2020-01-17): support for weighted payloads
33+
* *3.1.2* (2020-01-17): improved optimal selection when same speed/cost
34+
* *3.1.1* (2019-10-24): customizable least-privilege (lambdaResource CFN param)
35+
* ***3.1.0*** (2019-10-24): $LATEST power reset and optional auto-tuning (new Optimizer step)
36+
* ***3.0.0*** (2019-10-22): dynamic parallelism (powerValues as execution parameter)
37+
* *2.1.3* (2019-10-22): upgraded runtime to Node.js 10.x
38+
* *2.1.2* (2019-10-17): new balanced optimization strategy
39+
* *2.1.1* (2019-10-10): custom domain for visualization URL
40+
* ***2.1.0*** (2019-10-10): average statistics visualization (URL in state machine output)
41+
* ***2.0.0*** (2019-07-28): multiple optimization strategies (cost and speed), new output format with AWS Step Functions and AWS Lambda cost
42+
* *1.3.1* (2019-07-23): retry policies and failed invocations management
43+
* ***1.3.0*** (2019-07-22): implemented error handling
44+
* *1.2.1* (2019-07-22): Node.js refactor and updated IAM permissions (added lambda:UpdateAlias)
45+
* ***1.2.0*** (2019-05-24): updated IAM permissions (least privilege for actions)
46+
* *1.1.1* (2019-05-15): updated docs
47+
* ***1.1.0*** (2019-05-15): cross-region invocation support
48+
* *1.0.1* (2019-05-13): new README for SAR
49+
* ***1.0.0*** (2019-05-13): AWS SAM refactor (published on SAR)
50+
* *0.0.1* (2017-03-27): previous project (serverless framework)

README-ADVANCED.md

Lines changed: 76 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -59,3 +59,79 @@ The AWS Step Functions state machine is composed of five Lambda functions:
5959

6060
Initializer, cleaner, analyzer, and optimizer are executed only once, while the executor is used by N parallel branches of the state machine - one for each configured power value. By default, the executor will execute the given Lambda function `num` consecutive times, but you can enable parallel invocation by setting `parallelInvocation` to `true`.
6161

62+
## Weighted Payloads
63+
64+
> [!IMPORTANT]
65+
> Your payload will only be treated as a weighted payload if it adheres to the JSON structure that follows. Otherwise, it's assumed to be an array-shaped payload.
66+
67+
Weighted payloads can be used in scenarios where the payload structure and the corresponding performance/speed could vary a lot in production and you'd like to include multiple payloads in the tuning process.
68+
69+
You may want to use weighted payloads also in case of functions with side effects that would be hard or impossible to test with the very same payload (for example, a function that deletes records from a database).
70+
71+
You configure weighted payloads as follows:
72+
73+
```json
74+
{
75+
...
76+
"num": 50,
77+
"payload": [
78+
{ "payload": {...}, "weight": 5 },
79+
{ "payload": {...}, "weight": 15 },
80+
{ "payload": {...}, "weight": 30 }
81+
]
82+
}
83+
```
84+
85+
In the example above, the weights `5`, `15`, and `30` are used as relative weights. They will correspond to `10%` (5 out of 50), `30%` (15 out of 50), and `60%` (30 out of 50) respectively - meaning that the corresponding payload will be used 10%, 30% and 60% of the time.
86+
87+
For example, if `num=100` the first payload will be used 10 times, the second 30 times, and the third 60 times.
88+
89+
To simplify these calculations, you could use weights that sum up to 100.
90+
91+
Note: the number of weighted payloads must always be smaller or equal than `num` (or `num >= count(payloads)`). For example, if you have 50 weighted payloads, you'll need to set at least `num: 50` so that each payload will be used at least once.
92+
93+
94+
## Pre/Post-processing functions
95+
96+
Sometimes you need to power-tune Lambda functions that have side effects such as creating or deleting records in a database. In these cases, you may need to execute some pre-processing or post-processing logic before and/or after each function invocation.
97+
98+
For example, imagine that you are power-tuning a function that deletes one record from a downstream database. Since you want to execute this function `num` times you'd need to insert some records in advance and then find a way to delete all of them with a dynamic payload. Or you could simply configure a pre-processing function (using the `preProcessorARN` input parameter) that will create a brand new record before the actual function is executed.
99+
100+
Here's the flow in pseudo-code:
101+
102+
```
103+
function Executor:
104+
iterate from 0 to num:
105+
[payload = execute Pre-processor (payload)]
106+
results = execute Main Function (payload)
107+
[execute Post-processor (results)]
108+
```
109+
110+
Please also keep in mind the following:
111+
112+
* You can configure a pre-processor and/or a post-processor independently
113+
* The pre-processor will receive the original payload
114+
* If the pre-processor returns a non-empty output, it will overwrite the original payload
115+
* The post-processor will receive the main function's output as payload
116+
* If a pre-processor or post-processor fails, the whole power-tuning state machine will fail
117+
* Pre/post-processors don't have to be in the same region of the main function
118+
* Pre/post-processors don't alter the statistics related to cost and performance
119+
120+
## S3 payloads
121+
122+
In case of very large payloads above 256KB, you can provide an S3 object reference (`s3://bucket/key`) instead of an inline payload.
123+
124+
Your state machine input will look like this:
125+
126+
```json
127+
{
128+
"lambdaARN": "your-lambda-function-arn",
129+
"powerValues": [128, 256, 512, 1024],
130+
"num": 50,
131+
"payloadS3": "s3://your-bucket/your-object.json"
132+
}
133+
```
134+
135+
Please note that the state machine will require IAM access to your S3 bucket, so you might need to redeploy the Lambda Power Tuning application and configure the `payloadS3Bucket` parameter at deployment time. This will automatically generate a custom IAM managed policy to grant read-only access to that bucket. If you want to narrow down the read-only policy to a specific object or pattern, use the `payloadS3Key` parameter (which is `*` by default).
136+
137+
S3 payloads work fine with weighted payloads too.

README-DEPLOY.md

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -9,8 +9,7 @@ There are 5 deployment options for deploying the tool using Infrastructure as Co
99
1. [Using Terraform by Hashicorp and SAR](#option4)
1010
1. [Using native Terraform](#option5)
1111

12-
13-
Read more about the [deployment parameters here](README-INPUT-OUTPUT.md#state-machine-configuration-at-deployment-time).
12+
Read more about the [deployment parameters here](README.md#state-machine-configuration-at-deployment-time).
1413

1514
## Option 1: AWS Serverless Application Repository<a name="option1"></a>
1615

README-EXECUTE.md

Lines changed: 18 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -10,6 +10,23 @@ Feel free to customize the `scripts/sample-execution-input.json`, and then run `
1010

1111
The script will start a state machine execution, wait for the execution to complete (polling), and then show the execution results.
1212

13+
### Usage in CI/CD pipelines
14+
15+
If you want to run the state machine as part of your continuous integration pipeline and automatically fine-tune your functions at every deployment, you can execute it with the script `scripts/execute.sh` (or similar) by providing the following input parameters:
16+
17+
```json
18+
{
19+
"lambdaARN": "...",
20+
"num": 10,
21+
"payload": {},
22+
"powerValues": [128, 256, 512, ...],
23+
"autoOptimize": true,
24+
"autoOptimizeAlias": "prod"
25+
}
26+
```
27+
28+
You can use different alias names such as `dev`, `test`, `production`, etc. If you don't configure any alias name, the state machine will only update the `$LATEST` alias.
29+
1330
## Option 2: Execute the state machine manually (web console)
1431

1532
Once the state machine is deployed, you can execute it and provide an input object.
@@ -18,7 +35,7 @@ You will find the new state machine in the [Step Functions Console](https://cons
1835

1936
The state machine name will depend on the stack name (default: `aws-lambda-power-tuning`). Find it and click "**Start execution**".
2037

21-
You'll be able to provide the execution input (check the [full documentation here](README-INPUT-OUTPUT.md)]), which will look like this:
38+
You'll be able to provide the execution input (check the [full documentation here](README.md#state-machine-input-at-execution-time)), which will look like this:
2239

2340
```json
2441
{

0 commit comments

Comments
 (0)