Special sales reveal weaknesses not seen in normal traffic: the product page is fast from cache but lowers the Checkout worker, the inventory reservation becomes inconsistent with concurrent requests, the payment gatewayway rate-limit, or the email and webhook queue lags hours behind.
Quick answer:Test the actual path from product viewing to payment and callback by loading step by step on the same production environment. Measure the capacity of PHP, database, session, gateway and row. Before you start, freeze changes, dashboard, alert, runbook and be responsible for making specific decisions; the sudden increase in worker capacity on the day of the program's sale is not.
Turn demand into a technical scenario
Visitor numbers alone are not enough to measure capacity. Estimate product viewing rates, search, cart addition, checkout update, and order registration. A user makes several requests in a few minutes, and asset, Ajax, and external APIs behave differently.
| The way. | Cacheable? | The source of the crisis |
|---|---|---|
| Landing and public squad | Often, yes. | CDN, origin miss and asset |
| Search and filter. | Depends on the query. | Database and PHP |
| The cart and the account. | No, not public. | Session and Worker |
| Checkout | No, not public. | PHP, DB, forwarding and porting |
| Callback/Webhook | No, I'm not. | Security, idempotency and DB. |
Record the normal baseline
p50 and p95 record response time, error rate, PHP queue, CPU, available RAM, I/O, Query time, connection and row age on a normal day. Without a baseline, you don't know which indicator the campaign has changed.
Load Test is safe and realistic.
Do not run the test with real payment on production. Staging with copy, create unidentified data and close topology. Increase from low start and phase rates; separate read and write and then combine. Test data, email and webhook should not be sent to the real client or ERP system.
Don't just report requests per second. The correct order rate, duplicate, timeout, row, database pressure, and recovery time after load are important. If the result is captured with hot cache, record the warm-up and hit rate.
Cache public pages and purchase paths
Landing, categories and general products can benefit from CDN/page cache, but Cart, Checkout and My Account must have a correct bypass. The cache key must take into account language, currency, and personalization.
Cache Stampede when the campaign started.
If thousands of users go to the expired page at the same time, everyone may call the origin to restore. Design TTL, stale strategy, and warm-up according to the cache capability. Full purge just before the start, without warm-up, creates the most pressure at the worst time.
Checkout requires Dynamic capacity
Checkout goes through the full cache. Active worker, queue, request time, and memory of each process.Shop fast and checkoutIt's going to look at the difference in stages.
Database and Operations Competition
Order logs, inventory cuts, session and report read/write at the same time. Query, lock and I/O are seen in the test. Remove backup, product import and heavy report from the sales window, but do not remove the monitor and emergency backup.
Connection Pool and the roof of the database.
If the connection ceiling or Query capacity is lower, the increased PHP concurrency will only move the row from the web server to the database. See the number of active/idle, Query time and lock in the load test and do not increase the connection without the budget of RAM.
The simultaneous and the over-selling.
The presentation of the existent differs from the reserve or decrease security when ordering. Test two simultaneous requests for the last item in staging. The existing cache, ERP sync and the cancelled order release time should be clear. Do not override the existing validation to increase sales; the result is an unrealistic delivery commitment.
Gateway and external restrictions
Check the permitted rate, timeout, callback, webhook and inquiry with the provider. Timeout does not mean a complete failure and retry must be idempotent.
Action Scheduler and row
Email, webhook, sync, and cleanup may be in line. Baseline schedule and complete rates, oldest pending and failed rates.WooCommerce Action SchedulerShows why Delete or Run All is not a backlog solution.
Session, Redis and a few nodes.
In multiple nodes, session, cache namespace, clock and code version must be compatible. Redis can only be relied upon with hit rate, memory, eviction and failure tests. Restarting it at traffic peak can cause extensive cache miss and sudden database pressures.
Robot, Rate Limit and the buy-in line
WAF and rate limit should block abuse without blocking the callback gateway or actual client. Keep the rule before the campaign with traffic controlled testing and request ID. CAPTCHA or queue page affects conversion and accessibility and should be integrated beforehand.
Freeze and check the last 24 hours.
- No deployment and unnecessary plugin changes
- Backup verification and restore path
- Testing, cancellation and callback controlled.
- Check the certificate, DNS and system timing.
- Disk capacity, log rotation and quota services
- Alert verification and on-call access
- Config record and image copy active
The day of the sale dashboard.
See traffic, cache hits, p95 routes, error rates, PHP queue, DB latency, order per minute, payment success and backlog together. Link business and technical metrics. Do not display payment and customer data in the public dashboard.
Runbook happened.
- Identify the severity and direction of the impact.
- Record the last change and timeline.
- Stop the change at the same time.
- Take a risk-free, tried and tested approach.
- Re-read the metrics after each move.
- Reconcile the vague order and payment.
- Record the postmortem stability.
Rollback has to keep up with new orders.
Rollback image should not back up the database regardless of migration. Full restore removes recent-moment orders.
The Failure test, not just the success.
Simulate slow gate, Redis disconnect, webhook timeout and controlled row filling on staging. The system should send a clear message and not repeat retry. Also measure recovery and warm-up after service return; many incidents occur in the recovery wave.
Customer support capacity
Technical errors are not the only sales pressure. Prepare standard response for vague payment, SLA tracking and secure access to order ID. Do not re-apply to the customer until the previous status is inquired. The support team should not receive secret or card data.
The campaign's end schedule.
Do not turn off the monitor or temporary capacity immediately after the traffic drops. Webhook, email, sync and reporting may still have backlogs. Check Pending/Failed orders, successful unverified payments, negative items and backlog actions until the final status is reached.
Reduce temporary capacity after you see the discharge rate and return metrics. Clear test data and emergency rules with change record and add postmortem findings to the next campaign test plan.
Common Mistakes
- The test only caches the homepage.
- Full purge just before the start.
- Increase worker without RAM and DB
- Disable WAF or TLS.
- Load Test on the production
- Change the plugin on the day of sale
- Ignoring reconciliation
When do you need special assistance?
If the special sale focuses on short-term revenue, the capacity gauge and runbook should be ready in advance.Support for the WooCommerce storeIt can authenticate the purchase path, database, PHP, cache, gateway and array with a controlled test.
Common Questions
How many users can WooCommerce handle at the same time?
It has no fixed number; it determines the ratio of cache/dynamic path, request duration, database and external service capacity.
Is the CDN enough?
It lightens the public pages, but Checkout, session, order and gateway are processed at origin.
The day before, do we promote the server?
Changes to untested capacity are risky. New capacity must be validated with load test, monitor and rollback.
What do we do after the sale?
Reconcile and postmortem vague payments, duplicate, inventory, failed job, webhook and resource trends.