I know. Load testing is particularly important for microservices because of the need to execute fast at scale. So we have a paradox: Test too much too early and we slow the development process down. Test too late and we run the risk of paying the increased expense of fixing code late in the development cycle.

The trick is to test high-risk microservices at the start of the development cycle and leave less risky services for later. High-risk microservices are the low hanging fruit worthy of taking the time to load test. If a problem is discovered, the money saved fixing the problem early on outweighs the cost of the time it takes to run the test.

Time intensive load testing on low-risk microservices can take place later on in the software development lifecycle. Dependencies can be the bane of software development. One team has the code ready to go but is held back from releasing it because another team has yet to deliver a dependency.

This is a mistake. The way to address this type of delay is to use service virtualization. You can think of service virtualization as mocking out a service.

You create a microservice that has the URLs you require. These URLs accept data according to the microservice specification and respond according to specification. However, the response is very limited in scope. Although the behavior is limited, it does serve the purpose required: to provide the consumable functionality of a dependency that is still under development.

There are some microservices load testing tools out there that make microservice virtualization an easy undertaking. Swagger Editor and Restito are two of many. You use these tools to specify the URLs that make up the microservice.

Then behind the scenes, the tool implements the limited REST functionality required, according to the specification. Testing to a service level agreement might seem like an obvious thing to do. But, many companies are organized in such a way that testing personnel and product management never know about each other, let alone interact in an informative way.

Testers waste valuable resources imagining the operational conditions to meet. Product manager ends up being frustrated when the expectation is not met.

The easier way to avoid this problem altogether is to put products and testing into a room — real or virtual — and come up with a Service Level Agreement SLA by which product management expectations are well known and upon which good load tests can be designed and implemented.

The SLA does not need to be written in stone and never change, but if new needs evolve and become time-consuming beyond the established SLA, manage and communicate the changes needed.

The important thing is that the document provides the concrete, common reference that sets the standards by which testing will be conducted, and products will be accepted. We dedicated our deployment to a Midwest US data center. During load testing, we discovered that the microservice took too long to execute.

The code ran great in-house. So we did a no-brainer. We deployed the code to another region in Asia. Everything was fine. Firstly, load test execution can take a long time to complete. We must avoid slowing down or delaying application development simply because we have multiple load tests pending and only a single environment to run them on.

For example, an application deployed into a US-based data center could experience vastly different transaction response times compared to the same application deployed in a data center in Asia. Ideally, we want to ensure that the geolocation of our runtime environment used for testing matches the runtime environment that will be used in production.

We also need to ensure that the actual traffic we send to our application originates from realistic destinations. For example, if we create a public-facing application hosted on the internet, we will likely receive traffic from all over the world.

We must use a distributed load testing environment, with load test injectors deployed in multiple different geographical locations, to simulate an accurate load test.

Without these SLAs, the team responsible for load-testing microservices has to rely on guesswork to determine whether or not the transaction response times of a service are acceptable. We can avoid this problem by taking the time to bring microservice developers and product management together to establish acceptable levels of performance.

We typically establish SLAs for measuring microservice performance by defining the expected transaction response times and error rates for the service.

Still, they give everyone involved in the development of the application and its corresponding microservices an indication of what the acceptable level of performance is. The development of microservices is fast-paced, typically with multiple different builds and versions of any one service created over a short period of time.

We also need a way to quickly compare the performance of different builds and versions of our microservice. Gatling Enterprise solves this problem for you by allowing you to compare executions of any load test easily.

Although microservices are designed to function independently, they typically rely on working together to implement end-to-end functionality of applications. When you have such microservices in your domain, it can, therefore, be valuable to load test those microservices simultaneously.

This can be accomplished by executing realistic load tests against multiple different microservices in parallel. Gatling supports concurrent execution of different load test scenarios as standard, all within the same single load testing script.

Whilst the load test is executing, we can analyze the performance of the different microservices by utilizing the monitoring tools described below. Successful load testing of microservices hinges on the use of the correct tools. We first need a load testing tool that is capable of simulating real-world scenarios effectively.

Assuming that we are load-testing an application that will receive traffic from multiple geographic locations, the tool must also support distributed load generation. These requirements make Gatling a perfect choice for your microservices load testing tool.

Gatling can generate huge levels of HTTP traffic from minimal load injector resources. A Gatling load test environment distributed worldwide can be spun up with a few clicks.

The load test environment resources are automatically torn down once the test completes — meaning you are only charged whilst the load test is executing. Beyond tools that generate load, we must also ensure we have a suitable APM tool configured to monitor the microservices running in our test environment.

A tool like Gatling will be able to provide detailed information on the request and response times of the transactions to our microservices. Still, an APM tool is required so that we can dig into the resource utilization metrics of the hardware the application is running on and pinpoint any problems or bottlenecks.

A few popular tools that you might consider for your APM requirements are:. All the APM tools listed above should meet your requirements for monitoring microservice performance. There can be no shortcuts when it comes to performance testing microservices. Simply focussing load testing on the high-risk services is insufficient because these components depend on other microservices to function.

Planning a microservice load testing strategy following the principles outlined in this article is the appropriate way to mitigate this. Gatling Enterprise enables the deployment of distributed load-testing infrastructure in the cloud or on-premises with just a few clicks.

In addition to monitoring test results with a detailed dashboard in real-time, Gatling Enterprise offers several other significant features that will bring success to your microservice load testing efforts. Why Gatling?

Solutions Gatling Gatling Enterprise Integrations Features Dynamic Load Generators Continuous Load Testing No-Code Generator More features Learn more Blog Gatling Academy Documentation Resources Gatling Community About Our company Partner Program Events Join us Contact us Pricing Book a demo Login Free Trial.

Understanding Microservices What Are The Key Characteristics and Benefits Of Microservices? What Are The Three Types of Tests For Microservices? We can follow the traditional test pyramid model to identify the three types of tests for microservices we are primarily concerned with: Unit — tests that fall under this category relate to testing the microservice in isolation from other microservices.

Integration — this area of testing covers the verification that a microservice can successfully interact with other related microservices. We might use service utilization to achieve this more on that further below in this article or even have actual versions of the dependent services deployed and running in the test environment that can be called.

E2E — these tests cover the entire user journey of the application, utilizing all relevant microservices. End-to-end tests are typically performed through a UI or by triggering the API calls corresponding to a user journey in the expected order. Strategies for Performance Testing Microservices When it comes to load testing microservices, there are a few considerations that we need to be aware of and plan for upfront.

Ensure Sufficient Monitoring Is In Place The first thing we need to address is that the test environment hosting our microservice has sufficient monitoring in place.