Security and Performance Correlation
Security incidents are performance incidents. Brute-force traffic, bad bots, and compromised servers consume the same resources you are trying to optimize: PHP workers, CPU, database capacity, cache hit rate, and bandwidth.
How Attacks Show Up in Performance Metrics
| What You See | Where You See It | Common Cause |
|---|---|---|
| Sudden TTFB increase on uncached routes | PSI/WebPageTest, origin logs, APM | Login brute force, cart/checkout abuse, bot traffic bypassing cache |
| Cache hit rate collapses | Cloudflare analytics, cache headers | Bots requesting unique URLs/query strings, missing bypass rules, cache poisoning attempts |
| CPU spikes with no deploy | Server monitoring (top, Netdata) | Malware/miner, security plugin real-time scanning, brute force that reaches PHP |
| Database load rises and stays high | DB monitoring, slow query log | Spam bloat, attack scripts triggering uncached queries, background jobs going wild |
| Bandwidth spikes | CDN analytics, provider graphs | Scrapers pulling media, hotlinking, L7 DDoS |
10-Minute Triage Checklist
- Confirm whether the regression is only on uncached routes (admin, checkout, logged-in).
- Check Cloudflare Security Events and Cache Analytics for spikes.
- Check the origin for CPU/RAM pressure and unusual processes.
- Check for brute force patterns in web and SSH logs.
- If you suspect compromise, treat it as an incident (contain first, then tune).
Quick Commands (Origin)
cpu-and-process-snapshot.sh
top -bn1 | head -40
ps aux --sort=-%cpu | head -20
ps aux --sort=-%mem | head -20
check-wordpress-core-integrity.sh
wp core verify-checksums
find-php-in-uploads.sh
find /var/www/html/wp-content/uploads -type f -name "*.php"
recent-ssh-failures.sh
sudo grep "Failed password" /var/log/auth.log | tail -50
Where to Mitigate (Order of Leverage)
- Edge (Cloudflare): WAF managed rules, bot controls, rate limiting on login, block XML-RPC (if unused).
- Origin (server/web server): firewall, Fail2Ban, restrict sensitive files/routes, optional ModSecurity where it makes sense.
- WordPress: reduce attack surface (plugins/themes), disable file editing, keep updates sane, avoid heavy real-time scanning in production.
note
If you can block a request at the edge, do it there. It is usually both more effective and cheaper than letting it reach PHP.
Common Diagnostic Trap
When a site gets slower, the default response is "add resources" or "tune caching". If the underlying cause is abusive traffic or compromise, scaling up just gives the attacker more capacity.
If you see a sudden change with no deploy:
- Verify you are not under brute force or bot abuse.
- Verify the server is clean.
- Then go back to performance tuning.