What is think time (wait time) in load testing?

In traditional load testing parlance, “think time” is the pause between a simulated user’s actions. It represents the time a real person might spend reading, typing, or deciding what to do between clicks.

Loadster calls this “wait time” and implements it with wait steps in your scripts. In practice, “think time” and “wait time” mean the same thing.

Why Realistic Wait Times Matter

A bot with no wait steps sends its next request as soon as the previous one finishes. Even 100 bots with zero wait time might generate as many requests as thousands of real users, because real users typically spend much of their session reading and thinking instead of loading pages continuously.

If your wait times are too short, you’ll overstate the load generated by each virtual user and might conclude that your site can handle fewer concurrent users than it actually can. Try to make your scripts run at approximately the same pace as real users. Otherwise, your conclusions about concurrent user capacity might be misleading.

Wait Times, Session Duration, and Concurrency

Wait times often make up most of a script iteration’s duration, and the iteration duration is what relates concurrency to throughput. The longer each user’s session lasts, the more concurrent users you need to produce a given transaction rate. For example, 5,000 visits per hour with visits lasting around 3 minutes works out to roughly 250 concurrent users.

Changing your script’s wait times changes how much traffic a given number of bots will generate. The FAQ on calculating how many bots you need includes a formula for working backwards from your target transaction volume, and realistic wait time is an important input to that calculation.

Setting Wait Times in Loadster

In both protocol scripts and browser scripts, you can add wait steps between actions and set the duration in seconds. Before running a large test, review the wait steps in each script and make sure they approximate how an average user would move through the flow.

In code blocks, bot.sleep(milliseconds) does the same thing, and you can randomize the duration if you want more natural variation. In Playwright scripts, you can use Playwright’s waiting methods such as page.waitForTimeout(). Fixed wait times are generally fine for load testing, but some variation can help prevent large numbers of bots from sending requests at exactly the same time.

When to Use Zero Think Time

There are situations where zero think time makes sense. For example, you might want to generate the maximum possible load during a stress test, or you might be testing an API whose real clients are machines that send requests continuously.

Make this rare and deliberate choice only when it makes sense for what you want the test to measure. A test with zero think time can help answer “how much raw traffic can this system handle?”, but it doesn’t necessarily tell you how many human users the system can serve.