Hidden Problem That Makes Most Load Tests Unrealistic

You execute a load test using 100 virtual users.

The test generates 1000 requests per second.

In production, the same system only receives around 80 requests per second.

So what happened?

The answer is simple — think time.

If you don't use it, your load test might act like robots instead of real users, and the results could be totally wrong.

Let’s break down why think time is important and how to use it correctly during performance testing.

What Is Think Time?

Think time is the amount of time a real user takes between performing actions in an application.

In real life, users don't immediately perform the next request after receiving a response.

They usually:

• read the page
• scroll through content
• think about what to click
• enter data
• compare options
• navigate through menus

All these actions take time.

Performance tests that ignore this behavior produce unrealistic load patterns.

The Problem Without Think Time

User opens a page
User clicks a button
User searches for a product

If your script runs without pauses, the virtual user will send requests as quickly as it can.

Example:

Without think time:

100 virtual users → ~1000 requests per second (RPS)

But real users behave differently.

With realistic pauses:

100 real users → ~80 requests per second

That’s more than a 12× difference.

You can think about it using a simple model:

RPS ≈ Users / (Response Time + Think Time)

When think time increases, the number of requests per second naturally drops — even with the same number of users.

The same number of users produces completely different load depending on think time:

Scenario	Users	RPS
No think time	100	~1000
With think time	100	~80

This is why tests that don't include time for thinking often show more system traffic than there really is.

Why This Matters

Ignoring think time can lead to incorrect conclusions.

You might think:

• system cannot handle the load
• infrastructure needs scaling
• performance is worse than expected

In reality, the test was simply unrealistic.

Virtual users perform actions continuously without any human behavior.

Real users don’t behave like that.

Where Does Think Time Come From?

Good performance tests aim to mimic how real people behave when using an application.

Think time values can be gathered from various sources.

1. User Analytics

User analytics tools offer important information about how people use your application.

Examples of such tools include:

• Google Analytics
• Mixpanel
• Amplitude
• Pendo

These tools allow you to look at several metrics, such as:

• Average time spent on a page
• Session duration
• Click intervals
• Page navigation patterns

These metrics can help estimate how long a user usually stays on a page before taking another action.

2. Real User Monitoring (RUM)

Real User Monitoring tools track how users interact with the application in production.

They can provide data such as:

• Time between user interactions
• Navigation timing
• User session behavior

This type of data is often one of the most reliable source for defining think times.

3. Business Knowledge

In some cases, the most effective source of think time information comes from understanding the product and its typical use scenarios.

For instance:

Login page → 2–5 seconds
Search page → 5–10 seconds
Checkout → 15–30 seconds

Users require time to read, compare, and make decisions.

Different user journeys naturally involve different think times.

How Think Time Is Implemented in Performance Tests

Performance testing tools often offer various methods to simulate think time, which represents the time users take between actions.

JMeter

Common timers available in JMeter include:

• Constant Timer
• Uniform Random Timer
• Gaussian Random Timer

Random timers are generally preferred because real users do not wait the exact same amount of time between actions.

An example of a random pause would be a delay between 3 and 8 seconds.

k6

In k6, think time is typically simulated using the sleep() function.

Example:

sleep(randomBetween(3,8))

Gatling

Gatling includes built-in pause functions to simulate think time.

Example:

pause(3,8)

This creates a random delay between actions.

Common Think Time Mistakes

Even experienced engineers can sometimes use think time incorrectly.

Here are some common problems.

No think time at all

The script runs without any pauses.

This creates traffic patterns that don't match real-world behavior.

Fixed pauses

Example:

sleep(5)

Real users don't wait the same amount of time each time.

Random delays are typically more accurate.

Unrealistic pause values

Pauses that are too short or too long can affect the test results in an unrealistic way.

Think time should be based on how real users actually behave.

The Key Idea

Virtual users execute scripts.

Real users think.

If your performance test does not simulate this thinking time, the results may not represent real-world traffic.

A realistic load test is not just about the number of users.

It is about how those users behave.

If you're interested in learning more about realistic load modeling, think time, and performance testing in practice — I cover these topics in detail in my course.

You can check it out here:
👉 Performance Testing Fundamentals: From Basics to Hands-On (Udemy)