---
description: How to load test your app to find the sweet spot between performance and cost.
---

# Load Testing to Optimize Performance & Cloud Costs

## Overview

Most load testing tools focus on performance metrics like response times and throughput. They don't show you how much your scaling decisions cost in real-time.

This guide shows you how to use Stakpak to see both performance & cost during load tests. You'll learn exactly how much each scaling decision costs, so you can find the cheapest way to keep your app running smoothly.

## Problem

Companies face a lot of challenges while trying to optimize cloud costs through load testing:

### T**he limitations of traditional load testing**

* Standard load testing tools focus on performance metrics such as response times, throughput, and error rates.&#x20;
* Then they use these results to make architectural design decisions like scaling services, adding replicas, or reconfiguring infrastructure without thinking about the financial impact.
* They only realize the true cost of their architectural decisions once the cloud bill arrives.

This disconnect makes it difficult to align technical performance goals with cost optimization. Performance and cost live in two different universes

### Business Impact

* Unpredictable monthly cloud bills
* Inefficient resource utilization (often 20-30% waste)
* Difficulty in capacity planning and budgeting
* Competitive disadvantage due to higher operational costs

## How Stakpak Helps?

With the [infrastructure-cost-estimation](../rule-books/infrastructure-cost-estimation "mention") [rule-books](../rule-books "mention"), you can ask Stakpak not to just measure performance but also the cost of your architecture decisions.\
\
Instead of waiting for the bill, you can forecast costs during testing and make architecture decisions that are both performance-driven and cost-aware.

You also dont need to remember any CLI/tool commands.

## Step-by-Step Guide

### Prerequisites

1. [installing-stakpak-cli](../../get-started/installing-stakpak-cli "mention")
2. Cloud provider credentials configured
3. Application deployed and accessible
4. Basic understanding of your application's architecture.
5. Choose the endpoint you want to test (Staging or Ephemeral Environment)
6. Make sure you have explicit permission to run load tests.

In this guide, we will be load testing [**hackathon-judge-app**](https://github.com/kajogo777/hackathon-judge-app)**.** Let's take a look at the Cloud Architecture and what this app does.

### Architecture

<figure><img src="https://2684022488-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOFDKnFMEMmJjoclGx9Hr%2Fuploads%2FdWJK3U4C0pOBtkbJU2gu%2Fimage.png?alt=media&#x26;token=670fb621-75ca-494d-98dd-fd477c1e37af" alt=""><figcaption></figcaption></figure>

This setup deploys the `hackathon-judge-app` on Amazon ECS Fargate in the eu-north-1 region.\
Traffic flows through an Application Load Balancer (80/443 → Target Group 8501) into ECS tasks running across two availability zones for high availability.

* Networking: VPC (10.0.0.0/16) with public subnets (NAT Gateways) and private app subnets.
* Compute: ECS Fargate cluster with auto scaling (1–2 tasks, CPU 70%, memory 80%).
* Registry: Amazon ECR stores the container images.
* Observability: CloudWatch Logs (7 days) and Container Insights enabled.

Now, let's take a look at the app

### Application

<figure><img src="https://2684022488-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOFDKnFMEMmJjoclGx9Hr%2Fuploads%2FeO5jrfqDYB5m18fjSx6n%2Fimage.png?alt=media&#x26;token=041c445e-52d2-4ca7-9f34-31618c5e04f7" alt=""><figcaption></figcaption></figure>

#### Hackathon Judge App

A Streamlit web application for judging hackathon pitches. Designed to be accessible through mobile web browsers with persistent data storage.

#### Features

* Judge selection: Each judge can select their name before scoring teams
* Team scoring: Judges can score teams based on configurable criteria
* Score persistence: All scores are saved to a local JSON file
* Mobile-friendly design: Optimized for use on mobile devices
* Configurable through YAML: Easy to adjust teams, judges, and judging criteria
* Custom branding: Add your event logo and title for a personalized experience
* Authentication: Password protection for judges to secure the scoring process\


Now we can start that we understand the app and the architecture, we can start load testing our app

1. Open your terminal
2. Open Stakpak by typing `stakpak`

In this guide, we will use [Apache Bench](https://httpd.apache.org/docs/2.4/programs/ab.html) to load test our app

3. Now let's ask Stakpak to `load test our app [insert app link] with Apache Bench and monitor its resource  utilization`

That's it stakpak will automaically figure out what to do and how to use [Apache Bench](https://httpd.apache.org/docs/2.4/programs/ab.html)

<figure><img src="https://2684022488-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOFDKnFMEMmJjoclGx9Hr%2Fuploads%2FLixqwTjgjPIrvxyBdvnF%2Fimage.png?alt=media&#x26;token=af013268-4dc8-4176-b6f7-5494c0c82cce" alt=""><figcaption></figcaption></figure>

Here we see that the CPU utilization spiked to 17.88% and memory remained stable at 15% and auto scalling wasnt triggred

Now let's run the high load test `200 concarrunt users in 120 seconds`

<figure><img src="https://2684022488-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOFDKnFMEMmJjoclGx9Hr%2Fuploads%2FvpizHgT2yVHWlzwZ0Qqd%2Fimage.png?alt=media&#x26;token=e8e53fe8-488f-4bdb-b406-de7b62e308bc" alt=""><figcaption></figcaption></figure>

Even under stress testing, the highest CPU spike was 42.53%, far below the 70% auto-scaling threshold. This shows that the current infrastructure is over-provisioned for the tested workload and has plenty of headroom before scaling becomes necessary.

If you want to see this in action you can see our Stakpak Ship It session where we did that live

{% embed url="http://youtube.com/watch?v=HBvcfA6uUng&t" %}

Now that we’ve confirmed our infrastructure is over-provisioned, the next step is to evaluate cost efficiency. With Stakpak, you can go beyond performance testing and ask it to:

* **Estimate cloud costs** for the current setup (it will use the [infrastructure-cost-estimation](../rule-books/infrastructure-cost-estimation "mention") [rule-books](../rule-books "mention"))
* Generate a detailed report breaking down where resources (CPU, memory, storage, networking) are underutilized
* Provide actionable recommendations for cost optimization for example, rightsizing instances, adjusting auto-scaling policies, or switching to more efficient pricing models

## Extra Resources:

### Related Use Cases

* Performance Testing
* Infrastructure Cost Estimation

and more...

### References

* [installing-stakpak-cli](../../get-started/installing-stakpak-cli "mention")
* [rule-books](../rule-books "mention")
  * [infrastructure-cost-estimation](../rule-books/infrastructure-cost-estimation "mention")
* [ecs.docs](https://docs.aws.amazon.com/ecs/)
* cloud watch.docs
* [Apache Bench](https://httpd.apache.org/docs/2.4/programs/ab.html)
* [K6](https://k6.io/)
* [Artillary](https://www.artillery.io/)



