Load Testing with Dotcom-Monitor: Stress Testing Your Web App

LoadView is Dotcom-Monitor's load testing product. The distinguishing feature: it uses real browsers — actual Chrome instances — rather than simulated HTTP traffic. That distinction matters more than it might seem, and it's worth understanding before you design your first load test.

Why Real Browsers for Load Testing

Most load testing tools (JMeter, k6, Gatling, Artillery) simulate HTTP traffic. They record and replay network requests without executing JavaScript. This works well for APIs and server-rendered pages with simple request patterns.

Modern web applications are different. A single "page load" often involves:

• The initial HTML document request
• 20-100 subsequent asset requests (JS, CSS, images, fonts)
• Multiple XHR/fetch calls for data
• Third-party scripts that themselves trigger additional requests
• Client-side rendering that generates more requests after initial load

HTTP-level simulation generates load only for the requests you explicitly record. Browser-based load generation fires all of these requests automatically, because a real browser is loading the page.

The practical difference: HTTP simulation tends to underestimate server load for JavaScript-heavy applications. If your app uses React, Vue, Angular, or any significant client-side logic, your HTTP load test numbers may look fine while your production servers struggle under real user load.

LoadView's real-browser approach eliminates this gap. The load profile it generates matches what real users produce.

The tradeoff: real-browser load testing costs more in infrastructure per virtual user. You can run 10,000 simulated HTTP users on commodity hardware; 10,000 real Chrome instances require significantly more resources. LoadView's pricing reflects this.

Setting Up Your First Load Test

Step 1: Create a Load Test Script

LoadView uses scripts recorded with EveryStep Recorder, the same tool used for UserView transaction monitoring. Install EveryStep on Windows, record your target workflow, and export the script.

For load testing, your script should represent a realistic user session:

• Navigate to the homepage
• Browse to a product or content page
• Perform the primary action (search, add to cart, fill a form)
• Complete or abandon the flow

Avoid recording the entire application. Pick the critical path — the workflow that your real users follow most frequently. Load testing everything at once produces data that's hard to interpret.

If you're testing an API-heavy application or a simple page rather than a transaction flow, you can create a basic URL-based check without a full EveryStep script. Navigate to LoadView → Devices → Add Device → select HTTP/S or WebView depending on your test target.

Step 2: Configure Virtual Users and Ramp-Up

After importing your script, you configure the load profile. The key parameters:

Peak virtual users: The maximum number of concurrent users to simulate. Start conservatively — run at 10% of your expected peak before testing at full load.

Ramp-up duration: How long it takes to go from 0 to peak virtual users. A good default is 10-15 minutes for most tests. Instant ramp-up (all users starting simultaneously) creates artificial load spikes that don't match how real traffic arrives.

Test duration: Time to hold at peak load before ramping down. For a meaningful stress test, hold at peak for at least 10 minutes. Response times and error rates often take several minutes to stabilize at a given load level.

Ramp-down: How long to decrease from peak back to zero. Usually shorter than ramp-up — 5 minutes is typically sufficient.

LoadView provides three ramp-up patterns:

• Linear: Steady increase from 0 to peak. Good default for most tests.
• Step: Increase in increments (e.g., add 50 users every 5 minutes). Useful for finding the exact threshold where performance degrades.
• Goal-based: Automatically adjusts virtual user count based on a target response time. LoadView ramps up users until the target latency is hit, then holds. This directly answers "how many concurrent users can we handle at under 2 seconds response time?"

Step 3: Configure Geographic Distribution

LoadView's agent network covers 30+ locations globally. For load testing, geographic distribution matters for two reasons:

1. Realistic traffic patterns: Real users come from multiple locations. All-from-one-location load tests can saturate a single CDN edge node or routing path in ways that don't match production traffic.
2. Geographic performance validation: You can verify that users in different regions experience similar performance, or identify where regional differences are significant.

Under Load Distribution, assign percentages to different geographic regions. A typical distribution:

• 40% North America (East)
• 25% North America (West)
• 20% Europe (West)
• 15% Asia Pacific

Match this to your actual user distribution. If 70% of your users are in Europe, weight the load distribution accordingly.

Step 4: Configure Think Time

Think time is the delay between steps in a user flow. Real users don't instantly click the next button after a page loads — they read, scroll, decide.

Under Think Time, set the delay between script steps. A realistic baseline:

• Between page navigations: 3-8 seconds
• Between form field entries: 1-3 seconds
• Before checkout or submit actions: 5-15 seconds (users review before committing)

Zero think time produces unrealistically aggressive load. Think time at realistic values means your "100 concurrent users" in LoadView translates to a more realistic concurrent session count.

Running the Test

With the script and configuration ready, click Run Test. LoadView starts spinning up browser instances across your selected agent locations.

During the test, the real-time dashboard shows:

• Active virtual users (current count vs. peak target)
• Response time (average and percentiles)
• Error rate
• Throughput (requests per second)
• Geographic breakdown

Watch the first 5 minutes after reaching peak load carefully. This is where most failures first appear — the application reaches a new equilibrium under load, and problems surface as resource pools saturate.

Reading Results

Response Time Metrics

LoadView reports response time as:

• Average: Misleading on its own. A fast p50 with a slow p99 produces an average that hides the fact that 1% of users have terrible experiences.
• Percentiles (p50, p75, p95, p99): More useful. Focus on p95 and p99 — these represent real user experiences, not theoretical averages.
• Max: The worst single response during the test. Often caused by garbage collection pauses, connection pool exhaustion, or a single slow database query under high concurrency.

For most web applications, targets are:

• p50 under 1 second
• p95 under 3 seconds
• p99 under 5 seconds

Adjust based on your actual SLA and application type.

Error Rate

Error rate is the percentage of requests that returned errors (HTTP 4xx/5xx, timeout, connection refused). Under normal load, error rate should be near zero. As load increases:

• Error rate increase at moderate load: Application or infrastructure bottleneck — investigate before production traffic grows
• Error rate increase only at peak: Capacity issue — add resources or optimize hot paths before you hit that traffic level
• Sustained high error rate throughout: Check your script — you may be hitting an authentication barrier or misconfigured endpoint

Error rate of 1% at peak load sounds small but means 1 in 100 user actions failing. For checkout flows, that's directly measurable revenue impact.

Throughput

Throughput (requests per second or transactions per second) measures how much work your application is doing during the test. Compare throughput to virtual user count:

• Linear relationship: Each additional user adds proportional throughput — system is scaling correctly
• Throughput plateau while users increase: System has hit a bottleneck — you're queuing work, not doing more of it
• Throughput decrease under higher load: Queue overflow, timeout cascades, or resource exhaustion — the system is degrading

The throughput plateau is where you find your system's actual capacity ceiling.

Geographic Performance Comparison

The breakdown by agent location shows whether performance is consistent globally. Red flags:

• One region significantly slower than others: CDN miss, regional infrastructure problem, or missing edge presence
• One region with high error rates: Routing issue, regional API endpoint problem, or compliance-related blocking
• All regions degrading proportionally: Application bottleneck, not geographic

Interpreting Results Against Targets

After your test, you need to answer specific questions:

Can the system handle expected peak load? Compare peak virtual users to your traffic projections. If your Black Friday peak is 500 concurrent users and your test shows degradation at 200, you have a problem to solve before the event.

Where does the system break? If you ran a step-ramp pattern, identify the virtual user count where response time exceeded your target. That's your current capacity ceiling.

What breaks first? Correlate LoadView results with your APM data (Datadog, New Relic, or whatever you use). During the test, watch:

• Database connection pool utilization
• Server CPU and memory
• Cache hit rate
• Background job queue depth

The bottleneck LoadView finds is where to focus optimization work.

Common Load Testing Mistakes

Testing too aggressively too early: Run a baseline test at low load (10-20 users) first. Establish that the script works correctly at minimal concurrency before ramping up. A script bug at 500 users produces garbage data.

Not testing the critical path: Testing your marketing homepage under load tells you very little about whether checkout holds up. Test the transactions that matter.

Ignoring think time: Zero think time makes 50 users look like 500. Your results will be wildly pessimistic if you don't configure realistic think time.

Testing once and moving on: Load characteristics change as your application evolves. Run load tests before major releases, after significant infrastructure changes, and before high-traffic events.

No baseline comparison: A single load test result tells you your current state. A comparison against last month's test tells you whether you're getting better or worse. Keep test results and compare over time.

LoadView with real browsers gives you accurate load test data, but the value comes from running tests repeatedly, tracking trends, and acting on what you find.