Load testing your captive portal: don't lose guests at peak hours

Key takeaways: A captive portal that works for 50 concurrent users can fail catastrophically at 500. The failure mode: portal page doesn't load, DNS redirect times out, form submissions drop, and guests see "no internet connection" — then switch to cellular and you capture zero data. Load testing before deployment at high-traffic venues (stadiums, festivals, convention centers, busy restaurant chains during rush hour) is the difference between capturing 5,000 contacts at an event and capturing 50. The testing methodology isn't complex, but almost nobody does it.

Performance benchmarks in this article are illustrative. Actual results depend on portal complexity, hosting infrastructure, network configuration, and AP hardware. Test in your specific environment.

Small venues don't need load testing. A 60-seat restaurant with 30 concurrent WiFi users at peak will never stress a captive portal. The portal runs on cloud infrastructure that handles single-digit requests per second without breaking a sweat.

Large venues are a different story. A 20,000-seat stadium at a concert. A convention center during a 5,000-person conference. A festival with 10,000 attendees. A national restaurant chain's 500 locations simultaneously running a Friday night promotion.

At those scales, every component in the captive portal chain is a potential bottleneck: the AP's DHCP server, the DNS interceptor, the portal page load, the form submission endpoint, the OAuth callback (for social login), and the backend database write.

If any component fails under load, guests don't get WiFi. They don't fill out the form. You capture nothing. And the venue operator blames you.

---

What fails at scale

Failure 1: DHCP exhaustion

When 500 devices connect simultaneously, each one requests an IP address via DHCP. If the DHCP pool is too small (e.g., a /24 subnet with 254 addresses for 1,000 users), devices fail to get an IP. No IP = no network = no portal.

Fix: Size the DHCP pool to 2x expected concurrent connections. For 1,000 concurrent users, use a /22 subnet (1,022 addresses) or split across multiple /24 pools.

Failure 2: DNS resolution bottleneck

The captive portal redirect relies on DNS interception. The AP (or controller) intercepts DNS queries and responds with the portal IP. If 500 devices send DNS queries in a 30-second window, the DNS resolver must handle ~500 queries. Most AP DNS resolvers handle this fine, but underpowered hardware (consumer-grade routers, low-end APs) chokes.

Fix: Use enterprise APs with sufficient CPU for DNS processing. For very large venues, deploy a dedicated DNS server or use the controller's centralized DNS handling.

Failure 3: Portal page load time

The captive portal page is a web page hosted on a server (typically the platform's CDN — in MyWiFi's case, Amazon CloudFront). When 500 guests simultaneously request the portal page, the server must handle 500 HTTP requests in a short window.

Cloud-hosted portals on CDN infrastructure handle this well — CloudFront, for example, scales to millions of requests per second. But custom-hosted portals, self-hosted redirect pages, or portals with heavy assets (large images, unoptimized JavaScript, embedded videos) can become slow or unresponsive.

Benchmark: The portal page should load in under 2 seconds at peak concurrency. Above 3 seconds, 40% of users abandon before the page fully loads (Google/SOASTA 2024 study — still widely cited).

Failure 4: Form submission bottleneck

When 200 guests simultaneously submit the portal login form, the backend receives 200 POST requests. Each request must: validate the email, create/update the contact record, generate an authentication token, and return the redirect URL.

If the backend is a single-threaded process or the database is on underpowered infrastructure, form submissions queue up. The guest sees a spinning wheel for 10+ seconds. Some give up. Some retry, creating duplicate submissions.

Fix: Ensure the backend handles concurrent writes. Cloud platforms with auto-scaling handle this inherently. Self-hosted solutions may need load balancers, connection pooling, and write queue optimization.

Failure 5: OAuth callback failure

Social login (Facebook, Google) adds an external dependency. The guest taps "Login with Facebook." The browser redirects to Facebook's OAuth server. Facebook authenticates and redirects back to the portal with a token. The portal validates the token and grants access.

At scale, two things break:

1. •Facebook/Google's OAuth rate limits. Facebook's Graph API has rate limits per app. A sudden burst of 500 OAuth requests from the same app ID may hit throttling.
2. •The callback URL handler on your portal server. 200 simultaneous callback requests require the server to validate 200 tokens against Facebook's API.

Fix: Offer email login as the primary authentication method for large events. Social login works, but email login has no external dependency — it's entirely under your control.

---

Load testing methodology

Step 1: Define the scenario

Before testing, define the expected load:

Step 2: Test the portal page

Use a load testing tool to simulate concurrent requests to the portal URL:

Tools:

• •k6 (open source, scriptable, excellent for web page testing)
• •Apache JMeter (open source, Java-based, widely used)
• •Locust (Python-based, good for API testing)
• •Artillery (Node.js, good for quick tests)
• •Loader.io (cloud-based, no setup required)

Test script (conceptual):

1. •Simulate 500 concurrent users requesting the portal page
2. •Measure: response time (p50, p95, p99), error rate, throughput
3. •Ramp up: start at 10 users, increase by 50 every 10 seconds until 500

Pass criteria:

• •p95 response time under 2 seconds
• •Error rate under 1%
• •No connection timeouts

Step 3: Test form submission

Simulate concurrent form submissions with realistic data:

1. •200 concurrent POST requests with unique email addresses
2. •Measure: response time, success rate, duplicate handling
3. •Verify that all 200 contacts appear in the platform's contact database

Pass criteria:

• •p95 response time under 3 seconds
• •100% success rate (zero dropped submissions)
• •Zero unintended duplicates

Step 4: Test the full flow

Simulate the end-to-end experience:

1. •Device connects (simulated via network traffic generator)
2. •DNS redirect triggers (verify portal URL is returned)
3. •Portal page loads (measure time)
4. •Form submits (measure time, verify data storage)
5. •Post-authentication redirect (verify internet access granted)

This requires a more complex test setup — ideally using real devices (a batch of phones or tablets) connecting to the actual AP and going through the full portal flow.

Step 5: Test at 2x expected load

Always test at 200% of expected concurrent load. If you expect 500 concurrent portal users, test at 1,000. Actual event attendance often exceeds estimates. You want headroom.

---

Performance optimization for high-traffic portals

Optimize portal page weight

The portal page should be self-contained. No external CDN calls. No third-party tracking scripts. No Google Fonts (use system fonts). Every external dependency is a latency addition and a failure point under load.

Use CDN for portal hosting

Cloud-hosted portals on CDN infrastructure (CloudFront, Cloudflare, Fastly) handle traffic spikes inherently. The portal page is cached at edge locations worldwide. 500 simultaneous requests are served from cache without hitting the origin server.

MyWiFi hosts captive portals on Amazon CloudFront CDN, which handles high-traffic scenarios out of the box.

Preflight social login

If using social login at a large event, ensure the OAuth app is approved for high-volume use:

• •Facebook: Check the app's rate limits in the Facebook Developer dashboard. Request a rate limit increase if needed.
• •Google: Google Sign-In handles high volume well, but verify the OAuth consent screen is approved for production use.

Warm up the DHCP pool

Before a large event, verify that the DHCP server has sufficient available addresses. Flush expired leases. Shorten lease duration to 2–4 hours (default is often 24 hours) so addresses recycle faster as attendees leave and new ones arrive.

---

Real-world load testing checklist

For resellers deploying at high-traffic venues, run through this checklist before the event:

• • DHCP pool sized at 2x expected concurrent connections
• • Portal page weight under 200KB
• • Portal load tested at 2x expected concurrent portal users
• • Form submission tested at expected peak rate
• • Social login rate limits verified (if applicable)
• • DNS resolution tested under load
• • Bandwidth per-user limits configured (prevent individual users from saturating backhaul)
• • Backhaul bandwidth adequate (100 Mbps minimum for 500+ concurrent users)
• • AP firmware updated to latest stable version
• • Monitoring in place (AP dashboard, portal analytics) to detect issues in real time
• • Fallback plan: if portal fails, switch to click-through (zero-data) portal to maintain WiFi service

---

FAQ

Do I need to load test for a 100-seat restaurant? No. Cloud-hosted portals handle the traffic from a single restaurant without any risk of overload. Load testing is for venues with 500+ concurrent WiFi users: stadiums, convention centers, large hotels, festival grounds.

Can I load test without the physical AP infrastructure? Partially. You can load test the portal page and form submission endpoint directly (simulating HTTP requests to the portal URL). You can't test the full DHCP → DNS redirect → portal flow without actual AP hardware and test devices.

What if the portal fails during an event? Fail gracefully. Have a fallback plan: switch the portal to a click-through mode (no form fields, no data capture, just a "terms accepted" button) so guests still get WiFi. You lose the data capture, but you maintain the guest experience. A venue full of angry people with no WiFi is worse than a venue with no data capture.

How does MyWiFi handle high-traffic portals? MyWiFi hosts portals on Amazon CloudFront CDN, which is designed for high-traffic web delivery. The portal page is cached at AWS edge locations. Portal form submissions are processed by auto-scaling backend infrastructure. For extremely high-traffic events (10,000+ concurrent), contact MyWiFi's enterprise support for pre-event capacity planning.

What's the most common cause of portal failure at events? DHCP exhaustion. Not enough IP addresses for the number of devices. This has nothing to do with the portal itself — it's a network configuration issue. Always verify DHCP pool size before a large event.

---

Resellers deploying at high-traffic venues can contact the MyWiFi team for pre-event capacity planning and load testing guidance on Enterprise deployments.