This document provides a brief introduction/idea of how JMETER can be used with a serverless architecture also, like AWS, for evaluating the no. of read/writes capacity to benchmark the load an application can survive with.
What are AWS Lambdas?
The code written is deployed over the cloud with one or more lambda functions, to AWS lambda, a compute service that runs the code on our behalf.
It takes care of the trouble of provisioning and maintaining the servers, elastic enough to scale, cost effective and secure, making easy for us to jump right at the business logic and not worry about the infrastructure and resource allocations.
Terminologies to be familiar with:
- API Gateway: It handles all the tasks involved in accepting and processing up to hundreds of thousands of concurrent API calls, including traffic management, authorization and access control, monitoring, and API version management.
- DynamoDB: It is a NOSQL database service triggered as we create, update, and delete items from the associated lambda tables.
- Lambda functions: It is our custom code with its dependent libraries. Both the Lambda function and the DynamoDB stream must be in the same AWS region.
- Cloud watch: These Logs helps to monitor, store, and access our log files.
How to use JMETER for Lambdas?
Apache JMETER is widely known open source software, used as a load testing tool for analyzing and measuring the performance of a variety of services, with major focus on web applications.
It is easy to get started with and can be download from here for the quick reference.
Now, for a serverless architecture, the setup of JMETER would be quite similar to the server based architecture, as we need to keep in mind the required number of threads, target concurrency, etc.
We can use the concurrency thread group to maintain the level of concurrency, by adding set of threads during the runtime. As it won’t launch all the target threads upfront, so extra memory won’t be used and behavior of application can be gauged on how it tackles the load as no. of threads increase.
Also, we need to keep an eye on the tables or indexes of DynamoDB to witness the spike received once we trigger or hit the APIs of lambda functions.
Note: There can be multiple values accessed from multiple lambda functions, thus we need to be very cautious when we call a lambda which involves values from multiple tables.
How to check graphs/logs/results on AWS?
Once the intended API’s of related lambda functions are triggered through JMETER, we need to check on the AWS console inside the Cloud watch’s ‘Metrics’ tab about the consumed reads and writes of respective tables.
The immediate spike in the graphs within the same time frame as when the lambda was invoked will provide a relevant visibility of the read write capacity used for that particular table or index.
The cumulative consumed capacity of each table can then be used to set a maximum load with 20% buffer, for an index or table to handle.
Thus, In order to determine the responsiveness and stability of the application under test (AUT) for server less architecture and to make the application robust by setting a read/write measure, JMETER for AWS provide a great support to go ahead with.