Here is a mistake every beginner makes. They create 100 virtual users, each sending requests as fast as possible with zero delay. The result: 100 users generating 5,000 requests per second. Real users do not behave like that. A real user clicks a link, reads the page for 10-30 seconds, fills out a form, pauses to think, then clicks submit. Without simulating these pauses, your test is 10-50x more aggressive than reality.
Think time is the pause between actions in a user scenario. It simulates the time a real user spends reading content, filling forms, or deciding what to do next. In JMeter, you add Timer elements between requests. In k6, you add sleep() calls. Without think time, each virtual user acts like a robot spamming requests at machine speed.
| User Action | Typical Think Time | Range |
|---|---|---|
| Reading a product description | 10-30 seconds | 5-60 seconds |
| Filling a short form (login) | 5-15 seconds | 3-30 seconds |
| Filling a long form (checkout) | 30-90 seconds | 15-180 seconds |
| Browsing a list/catalog | 5-15 seconds | 2-30 seconds |
| Deciding on a purchase | 15-60 seconds | 5-120 seconds |
| Between search results and clicking one | 3-10 seconds | 1-15 seconds |
Real users do not all pause for exactly 10 seconds. Some read fast (5 seconds), some read slow (30 seconds). Use randomized think time with a range. JMeter has Gaussian Random Timer and Uniform Random Timer. k6 has sleep(Math.random() * 10 + 5) for 5-15 seconds.
import http from 'k6/http';
import { sleep } from 'k6';
export default function () {
// Step 1: Browse products
http.get('https://myapp.com/products');
sleep(Math.random() * 10 + 5); // 5-15 seconds think time
// Step 2: View product details
http.get('https://myapp.com/products/123');
sleep(Math.random() * 20 + 10); // 10-30 seconds (reading description)
// Step 3: Add to cart
http.post('https://myapp.com/cart', { productId: 123 });
sleep(Math.random() * 5 + 2); // 2-7 seconds
}Pacing is the total time for one complete iteration of the scenario, including processing and think time. If your pacing is 60 seconds and the scenario takes 10 seconds to execute with 40 seconds of think time, the system adds 10 seconds of additional wait to make the total exactly 60 seconds. Pacing ensures consistent throughput regardless of server response times.
When in doubt about think time values, analyze your production access logs. The time between requests from the same user session IS the think time. Most analytics tools can calculate session-level request intervals. Real data beats guesswork.
Q: What is think time in performance testing and why is it important?
A: Think time simulates the pauses between user actions -- reading content, filling forms, deciding what to click. Without it, each virtual user sends requests at machine speed, creating unrealistically high load. 100 users without think time can generate 5,000+ RPS, while 100 real users typically generate 50-100 RPS. I use randomized think time (e.g., 5-15 seconds between page views, 30-90 seconds for form filling) to simulate realistic browsing patterns. The values come from production access logs when available, or industry benchmarks. Pacing is related but different -- it controls the total iteration time to maintain consistent throughput.
Key Point: Think time simulates real user pauses between actions. Without it, tests are 10-50x more aggressive than reality. Use randomized ranges based on production data or industry benchmarks. Always include think time in load tests.
Key Point: Always add think time. Without it, 100 virtual users generate the load of 1000+ real users. Use randomized ranges for realism.