Load Testing Before a Campaign, Without a Performance Team

A campaign is booked, television or a large page is sending people to your site at a known hour, and nobody knows what happens at a thousand concurrent visitors. You do not need a performance engineering practice to answer that. You need one honest afternoon, a realistic script and the willingness to act on what it tells you.

Work out the number you need before you test anything

Testing without a target produces a graph nobody can act on, so start by converting the campaign into concurrent users. Take the expected arrivals in the busiest minute, multiply by how long a visitor stays active in seconds, and divide by sixty. Five thousand people arriving over ten minutes, each active for two minutes, is roughly a thousand concurrent sessions at the peak. Then double it, because campaign traffic is spiky and the peak minute is never the average minute.

• Ask the media buyer for expected reach and the exact broadcast or send time.
• Assume the arrival curve is a spike, not a plateau. Most of the traffic lands in the first few minutes.
• Add the traffic you already have; the campaign does not replace it.
• Write the target down as a sentence, so the test has a pass or fail rather than a vibe.

Test the journey, not the homepage

Hitting the homepage with a load tool measures your cache and nothing else. Write the script as the journey the campaign actually drives: landing page, one product or service page, add to cart or open the enquiry form, then submit. That last step is where sites fall over, because it is the one request that cannot be cached and it usually touches the database, a mail provider and a payment gateway at the same time.

• Model the real path, including the form submission or checkout.
• Include the third-party calls, or note explicitly that you excluded them and why.
• Ramp up in steps rather than jumping to the target; a step pattern shows where the curve bends.
• Run against staging with production-sized data. An empty database gives you fast queries that do not exist in reality.
• Vary the inputs. Every virtual user requesting the same product ID tests your cache, not your application.

Which tool

Any of the modern scriptable load tools will do this job, and the choice matters far less than the script. Pick one that lets you write the journey in a language your team reads, run it from a machine with more bandwidth than your laptop, and check that your own network or laptop CPU is not the thing you are actually measuring. Run the test from outside your hosting provider's network so the result includes the path a real visitor takes.

The numbers that matter

Average response time hides the failure, so watch the 95th percentile, the error rate and throughput together. Find the point where response time climbs while throughput stops rising. That knee is your capacity: below it the system is fine, above it queues build and everything degrades at once. Watch the server side at the same time, because the useful diagnosis is in CPU, memory, database connections and queue depth, not in the client-side graph.

The useful output is one sentence: we serve N concurrent users at under two seconds, and above that the enquiry form starts failing.

Do not point a load test at production without warning people

Testing against live systems has consequences beyond your own servers, and the ones that cause real damage are usually external. A test that runs a real checkout can hit a payment gateway's rate limits and get your merchant account flagged. A test that submits real forms sends real emails and real SMS, burns credits, and lands your domain in spam filters. Tell your hosting provider you are running a test, use gateway sandbox credentials, and stub outbound mail and SMS at a level you control.

What usually fixes it

The bottleneck is rarely the language or the framework. It is a page running a query per item, a missing index on a column you filter on, images served at full size, or a synchronous call to an external service sitting on the request path. Cache what can be cached, put a CDN in front, move mail and webhooks onto a queue so a slow provider cannot hold a request open, and add the index. These are afternoon fixes with disproportionate effect, and they are the same ones that improve your Core Web Vitals on an ordinary day.

• Find the N+1 query. It is almost always there, and an ORM makes it invisible in the code.
• Index the columns you actually filter and sort on, then confirm the query plan uses them.
• Serve images at display size, in a modern format, lazily below the fold.
• Move email, webhooks and third-party calls off the request path and onto a queue.
• Set a timeout on every outbound call. A gateway that hangs for sixty seconds will exhaust your workers long before it returns an error.

Some limits are not yours to fix

A load test measures your infrastructure, and campaign day often fails somewhere you do not control. Payment gateways, SMS and OTP providers, mail relays and mapping APIs all have rate limits and quotas, and hitting one produces failed checkouts that look exactly like a bug in your code. Find out the published limits in advance, ask for a temporary increase where that is possible, and make sure the failure is handled visibly rather than silently. If your checkout depends on eSewa or Khalti callbacks, test the failure path where the callback is slow or never arrives, because that is the one that leaves an order in limbo and a customer on the phone.

The network is part of the test

Most of the traffic a Nepali campaign generates arrives on a mid-range Android phone over mobile data, so a page that responds in 200 milliseconds from a server in Singapore can still take eight seconds to become usable. Test the real thing: throttle the connection, use an older device, and measure when the page becomes interactive rather than when the first byte arrives. A payload that a laptop shrugs off is a genuine barrier on a phone with four-year-old hardware and a weak signal.

Plan for the day itself

Decide in advance what you will do if the numbers go wrong. Know who is watching, where the dashboard is, and which lever you pull first, whether that is scaling up, turning on aggressive caching, or disabling a heavy feature behind a flag. Have a static fallback page carrying the phone number and the offer, so that in the worst case a visitor gets something useful instead of a timeout. If nobody currently owns any of this, the monitoring and alerting groundwork in DevOps on a budget for startups is the prerequisite, and it is also what we set up under cloud and DevOps.

Do it a week early

Run the test far enough ahead that fixes can be deployed and re-tested calmly, then run it again after the fixes. A load test the night before produces a bad night and a rushed change on the least forgiving day of the quarter. A week of margin turns the same information into an ordinary piece of work, and it leaves room for the second test that tells you whether the fix worked.