AWS Lambda Test

Compare the value of this measure acros functions to know which function is used the maximum. The failure of such a function will naturally have a more adverse impact on performance and productivity than other functions.

Ideally, the value of this measure should be 0. A non-zero value is indicative of one/more errors in the function code.

To know what errors occurred during invocation, check the logs. Typically, each time the code is executed in response to an event, it writes a log entry into the log group associated with a Lambda function, which is /aws/lambda/<function name>.

Following are some examples of errors that might show up in the logs:

• If you see a stack trace in your log, there is probably an error in your code. Review your code and debug the error that the stack trace refers to.
• If you see a permissions denied error in the log, the IAM role you have provided as an execution role may not have the necessary permissions. Check the IAM role and verify that it has all of the necessary permissions to access any AWS resources that your code references.
• If you see a timeout exceeded error in the log, your timeout setting exceeds the run time of your function code. This may be because the timeout is too low, or the code is taking too long to execute.
• If you see a memory exceeded error in the log, your memory setting is too low. Set it to a higher value. Typically, when creating a function, you need to mention the amount of memory that should be given to that function. Lambda uses this memory size to infer the amount of CPU and memory allocated to your function. Your function use-case determines your CPU and memory requirements. For example, a database operation might need less memory compared to an image processing function. The default value is 128 MB. The value must be a multiple of 64 MB.

By default, a failed Lambda function invoked asynchronously is retried twice, and then the event is discarded. Using Dead Letter Queues (DLQ), you can indicate to Lambda that unprocessed events should be sent to an Amazon SQS queue or Amazon SNS topic instead, where you can take further action.

If the value of this measure keeps increasing, it implies that the event payload is consistently failing to reach the dead letter queue. Probable cause for this are as follows:

• Permissions errors
• Throttles from downstream services
• Misconfigured resources
• Timeouts tidings

Ideally, the value of this measure should be low. A high value indicates that a function/version/alias is taking too long to execute.

To determine why there is increased latency in the execution of a Lambda function, do the following:

• Test your code with different memory settings: If your code is taking too long to execute, it could be that it does not have enough compute resources to execute its logic. Try increasing the memory allocated to your function and testing the code again, using the Lambda console's test invoke functionality. You can see the memory used, code execution time, and memory allocated in the function log entries. Changing the memory setting can change how you are charged for duration.

• Investigate the source of the execution bottleneck using logs: You can test your code locally, as you would with any other Node.js function, or you can test it within Lambda using the test invoke capability on the Lambda console, or using the asyncInvoke command by using AWS CLI. Each time the code is executed in response to an event, it writes a log entry into the log group associated with a Lambda function, which is named aws/lambda/<function name>. Add logging statements around various parts of your code, such as callouts to other services, to see how much time it takes to execute different parts of your code.

The unit of scale for AWS Lambda is a concurrent execution (see Understanding Scaling Behavior for more details). However, scaling indefinitely is not desirable in all scenarios. For example, you may want to control your concurrency for cost reasons, or to regulate how long it takes you to process a batch of events, or to simply match it with a downstream resource. To assist with this, Lambda provides a concurrent execution limit control at both the account level and the function level.

On reaching the concurrency limit associated with a function, any further invocation requests to that function are throttled, i.e. the invocation doesn't execute your function. Each throttled invocation increases the value of this measure for the corresponding function.

AWS Lambda handles throttled invocation requests differently, depending on their source:

• Event sources that aren't stream-based: Some of these event sources invoke a Lambda function synchronously, and others invoke it asynchronously. Handling is different for each:

• Synchronous invocation: If the function is invoked synchronously and is throttled, Lambda returns a 429 error and the invoking service is responsible for retries. The ThrottledReason error code explains whether you ran into a function level throttle (if specified) or an account level throttle (see note below). Each service may have its own retry policy. For example, CloudWatch Logs retries the failed batch up to five times with delays between retries. For a list of event sources and their invocation type, see Supported Event Sources.
• Asynchronous invocation: If your Lambda function is invoked asynchronously and is throttled, AWS Lambda automatically retries the throttled event for up to six hours, with delays between retries. Remember, asynchronous events are queued before they are used to invoke the Lambda function.

• Stream-based event sources: For stream-based event sources (Kinesis and DynamoDB streams), AWS Lambda polls your stream and invokes your Lambda function. When your Lambda function is throttled, Lambda attempts to process the throttled batch of records until the time the data expires. This time period can be up to seven days for Kinesis. The throttled request is treated as blocking per shard, and Lambda doesn't read any new records from the shard until the throttled batch of records either expires or succeeds. If there is more than one shard in the stream, Lambda continues invoking on the non-throttled shards until one gets through.

This measure is available only for the Summary descriptor.

Use the detailed diagnosis of this measure, if enabled, to know which functions are available for each region, the runtime environment of each function, and when the function was last modified.

Note that detailed diagnostics will be reported for this measure only if the DD For Total flag is set to Yes.

This measure is available only for the Summary descriptor.

Use the detailed diagnosis of this measure to know which Lambda functions were recently created in this region.

This measure is available only for the Summary descriptor.

Use the detailed diagnosis of this measure to know which Lambda functions were recently deleted in this region.

Compare the value of this measure across functions to know which function was hogging the CPU. Likewise, compare the value of this measure across aliases / versions to know the functions mapped to which alias / version is hogging the CPU.

In the Init phase, Lambda creates or unfreezes an execution environment with the configured resources, downloads the code for the function and all layers, initializes any extensions, initializes the runtime, and then runs the function’s initialization code (the code outside the main handler). The Init phase happens either during the first invocation, or in advance of function invocations if you have enabled provisioned concurrency.

Compare the value of this measure across functions to know which function spent the maximum time in the init phase. Likewise, compare the value of this measure across aliases / versions to know the functions mapped to which alias / version were delayed in the init phase.

Compare the value of this measure across functions to know which function used the maximum amount of memory.

Likewise, compare the value of this measure across aliases/versions to understand if functions of a specific version are memory-hungry.

Compare the value of this measure across Lambda functions to know which function is I/O-intensive.

You can also compare the value of this measure across aliases/versions to determine if Lambda functions of any specific alias/version are consistently I/O-intensive.

Compare the value of this measure across Lambda functions to know which function's runtime is spending more time running code for extensions.

You can also compare the value of this measure across aliases/versions to determine if Lambda functions of any specific alias/version are spending more time running code for extensions.

Concurrency is the number of requests that your function is serving at any given time. When your function is invoked, Lambda allocates an instance of it to process the event. When the function code finishes running, it can handle another request. If the function is invoked again while a request is still being processed, another instance is allocated, which increases the function's concurrency. The total concurrency for all of the functions in your account is subject to a per-region quota.

For an initial burst of traffic, your functions' cumulative concurrency in a region can reach an initial level of between 500 and 3000, which varies per region. You can also allocate capacity on a per-function basis with Reserved concurrency. This guarantees the maximum number of concurrent instances for the function. When a function has reserved concurrency, no other function can use that concurrency. Alternatively, you can configure Provisioned concurrency for a function. This initializes a requested number of execution environments so that they are prepared to respond immediately to your function's invocations.

By observing the variations to this measure for each function over time, you can quickly isolate functions requiring more concurrency capacity. You can then allocate the additional capacity to that function by setting Reserved concurrency or Provisioned concurrency.

Ideally, the value of this measure should be 0 for any function/alias/version. A non-zero value is a cause for concern, as it implies that a Lambda function or functions mapped to an alias/version (as the case may be) failed to send an event to a destination. Delivery errors can occur due to permissions errors, misconfigured resources, or size limits..

Provisioned Concurrency is a feature that keeps functions initialized and hyper-ready to respond in double-digit milliseconds. This is ideal for implementing interactive services, such as web and mobile backends, latency-sensitive microservices, or synchronous APIs.

When you invoke a Lambda function, the invocation is routed to an execution environment to process the request. When a function has not been used for some time, when you need to process more concurrent invocations, or when you update a function, new execution environments are created. The creation of an execution environment takes care of installing the function code and starting the runtime. Depending on the size of your deployment package, and the initialization time of the runtime and of your code, this can introduce latency for the invocations that are routed to a new execution environment. This latency is usually referred to as a “cold start”. For most applications this additional latency is not a problem. For some applications, however, this latency may not be acceptable.

When you enable Provisioned Concurrency for a function, the Lambda service will initialize the requested number of execution environments so they can be ready to respond to invocations.

If the value of this measure is consistently high for any function, it could indicate that the function has outgrown its provisioned concurrency capacity. You may then want to allocate more concurrency capacity to that function by fine-tuning its Provisioned concurrency setting.

A value close to 100% for any function indicates that the concurrency capacity configured for that function is inadequate. In such cases, a spill over becomes inevitable. To avoid this, you may want to consider increasing the Provisioned Concurrency capacity for that function. Optionally, you may want to configure Reserved Concurrency for that function, as it guarantees the maximum number of concurrent instances.