Our company is preparing for a large marketing campaign, and we expect traffic to increase significantly when it launches. I want to verify that the website can handle the demand without slow responses, errors, failed signups, or checkout problems. What would a realistic pre-launch load test involve? Should we start with our previous peak traffic, test the projected campaign volume, and then add extra headroom? Which tools and metrics should we use, and what precautions should we take so the test itself doesn't cause problems?
4 Answers
Run the test in a production-like environment and get explicit approval from the service owners. If you test against production, schedule it carefully, set clear stop conditions, have someone actively watching the dashboards, and use test accounts so you don’t send real emails, charge cards, or affect customer data. Don’t overwhelm external providers or partner services without permission. Caching, rate limits, a CDN, load balancing, and a waiting room can provide useful protection, but they should complement—not replace—a realistic end-to-end test.
Define pass/fail criteria before running anything: acceptable p95 or p99 latency, maximum error rate, successful signup or order percentage, and tolerable queue delay. After the test, reduce the load and confirm that queues drain and response times return to normal without manual restarts. Also have a scaling plan ready. If monitoring shows the system is failing, you should already know how to add instances, increase capacity, enable caching, or prioritize critical paths such as checkout.
Use a proper load-testing tool such as k6, JMeter, Gatling, or Locust. The important part is modeling realistic user journeys rather than repeatedly requesting one cached page. Simulate actions such as arriving on the landing page, searching, signing up, and checking out, using varied sessions and test data. Watch latency percentiles, error rates, throughput, database connections, slow queries, CPU and memory, queue depth, and saturation of downstream services. Also make sure the load generator itself can produce the requested traffic.
Test several levels instead of choosing one arbitrary number. Start with a small run to validate the scripts, then reproduce your previous peak, then test the expected campaign load based on the marketing team’s estimated arrivals per minute and launch timing. Add an agreed amount of headroom, but stay within a safe limit. Test the ramp-up as well as the peak, since systems can fail while scaling or while queues are building. Hold the load long enough to observe autoscaling, background jobs, and recovery after traffic drops.
An arrival-rate workload is useful for this. With a fixed number of virtual users, slower responses can cause them to send fewer new requests, which may hide overload. In k6, for example, an arrival-rate scenario can represent a target number of user journeys per second.