Performance Debugging

Learning Focus

By the end of this lesson you will know how to systematically investigate slow sites by working through each layer of the stack, from edge to database, without changing random settings.

The Golden Rule

Performance debugging works best when you move layer by layer instead of changing random settings. Measure first, then tune.

Diagnostic Flow

Layer-by-Layer Investigation

1. DNS and Edge Behavior

Before touching the server, rule out external factors:

# Check DNS resolution time
dig example.com +stats | grep "Query time"

# Check Cloudflare edge response (if using Cloudflare)
curl -sI https://example.com | grep -E "cf-cache-status|cf-ray|server"

# Test direct origin response (bypassing CDN)
curl -sI --resolve example.com:443:YOUR_SERVER_IP https://example.com

2. Cache Hit Rate

Caching is usually the biggest single performance lever:

# Check LiteSpeed Cache headers
curl -sI https://example.com | grep -i "x-litespeed-cache"

# Look for MISS vs HIT patterns
for i in {1..5}; do
  curl -sI https://example.com | grep "x-litespeed-cache"
done

Result	Meaning	Action
X-LiteSpeed-Cache: hit	Page served from cache	Cache is working
X-LiteSpeed-Cache: miss	Page generated dynamically	Check cache rules
No header present	Cache not active	Enable and configure cache

3. OpenLiteSpeed Concurrency

Check whether the web server itself is under pressure:

# View real-time server status in WebAdmin
# Dashboard → Server → Real-Time Statistics

# Check active connections from the command line
netstat -an | grep :80 | wc -l
netstat -an | grep :443 | wc -l

# Monitor server resource usage
top -p $(pgrep -d',' lshttpd)

4. PHP Worker Pressure

PHP workers are the most common bottleneck for dynamic sites:

# Check lsphp process count
ps aux | grep lsphp | grep -v grep | wc -l

# Check PHP error log for timeout or memory issues
tail -100 /usr/local/lsws/logs/stderr.log

# Monitor PHP worker memory usage
ps aux | grep lsphp | awk '{sum += $6} END {print "Total PHP memory: " sum/1024 " MB"}'

Symptom	Likely Cause	Fix
All PHP workers busy	Too few workers or slow queries	Increase Max Connections or optimize app
High memory per worker	Large PHP scripts or plugins	Tune memory_limit, review plugins
Workers constantly restarting	PHP fatal errors	Check stderr.log and PHP error log

5. Database and Application Latency

# MySQL slow query check
sudo mysql -e "SHOW GLOBAL STATUS LIKE 'Slow_queries';"

# Check database connection time
time mysql -e "SELECT 1;"

# Monitor disk I/O (database storage)
iostat -x 1 5

Quick Reference Table

Layer	Tool	What It Tells You
DNS	dig	Resolution latency
Edge / CDN	curl -I + headers	Cache status, edge location
Web server	WebAdmin dashboard	Connection count, requests/sec
PHP	ps aux, error logs	Worker count, memory, crashes
Database	SHOW STATUS, slow log	Query time, lock waits
Disk	iostat, iotop	Storage throughput and latency

Anti-Patterns

Don't Do This	Do This Instead
Change random settings hoping performance improves	Measure each layer, then tune the bottleneck
Increase PHP workers without checking memory	Calculate workers × memory_limit ≤ available RAM
Disable cache to "debug"	Check cache headers first, disable only the specific page
Blame the web server without checking the application	Profile the application after confirming OLS is healthy

warning

Tuning the wrong layer wastes time and can make things worse. Always measure before you change.

Key Takeaways

• Measure each layer before you tune it — DNS, cache, web server, PHP, database.
• Cache hit rate is usually the biggest single performance lever for dynamic sites.
• PHP worker pressure is the most common bottleneck on OpenLiteSpeed servers.
• Use the diagnostic flow as a runbook during slow-site investigations.

What's Next

• Continue to SSL Errors to diagnose Cloudflare 525, 526, and certificate mismatch issues.