Introduction
This document provides a brief description of how JMETER can be used with a server-less architecture like AWS. This can be used to evaluate the read/write capacity of the underlying DB, to benchmark the load an application can survive with.
What are AWS Lambdas?
The code written is deployed to AWS lamba over the cloud with one or more lambda functions. A compute service runs the code on our behalf.
The advantages are:
- Takes care of the trouble of provisioning and maintaining the servers
- Is elastic enough to scale
- Is cost effective and secure
- Is easy to jump right at the business logic and not worry about the infrastructure and resource allocations
Terminologies to be familiar with
- API Gateway: 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: A NOSQL database service triggered as we create, update, and delete items from the associated lambda tables.
- Lambda functions: Custom code with its dependent libraries. Both the Lambda function and the DynamoDB stream must be in the same AWS region.
- Cloud watch: Helps to monitor, store, and access our log files.
How to use JMETER for Lambdas?
Apache JMETER is a 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 quick reference.
For a server-less architecture, the setup of JMETER is quite similar to the server-based architecture. We must 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 a set of threads during run-time. As JMETER doesn’t launch all the target threads upfront, extra memory won’t be used. The behavior of the application can be gauged on how it tackles the load as the number of threads increase.
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. We must 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 APIs of the related lambda functions are triggered through JMETER, we must 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 and 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.
Conclusion
JMETER for AWS provides a great support in the following scenarios:
- Determine the responsiveness and stability of an application under test (AUT) for server less architecture
- To make an application robust by setting a read/write measure
talentica.wordpress.com 