Why is my site slow?

A slow site usually has one constrained layer - a cold cache, a heavy database query, unexpected traffic, or an undersized server. TurboStack gives you the tools to find which one it is and fix it, rather than guessing. Always measure before you change anything.

Symptoms

• Pages take seconds to load, or time out under load.
• The site is fast for logged-out visitors but slow in the admin or checkout.
• Slowness comes and goes, or only appears at certain times of day.
• The first request after a deploy is slow, then it recovers.

Diagnose it on TurboStack

Start by confirming where the time goes - do not change config without measuring.

1. Open the host's Health tab and read the Host Monitoring cards: CPU, RAM, Memory swap, and Disk. Use the 1H/8H/1D/7D range buttons to see whether the pressure is constant or spikes. Sustained high CPU, RAM near full, or any active swapping all point to a resource bottleneck.

2. Check Top Issues on the same tab - TurboStack ranks the most important PERFORMANCE and STABILITY problems it has detected and suggests a fix.

3. Look at the Services checks (database, cache, web server) and the database/cache hit-ratio metrics. A low cache hit ratio means requests are missing the cache and hitting PHP or the database directly.

4. Use the fleet Monitoring dashboard to see trends across hosts and any open alerts.

5. Check History (Revisions / Deploys) to see whether a recent publish or deploy coincides with the slowdown. If so, that change is the most likely cause and you can roll back.

Common causes and fixes

Cold or missing caches

After a deploy, a content change, or a cache flush, the caches are empty and every request does full work until they warm up. A persistently low hit ratio (rather than a brief dip) points to a caching layer that is being bypassed or invalidated too often.

TurboStack provides several caching layers - Redis object cache, Varnish full-page cache, and PHP OPcache. The fastest safe fix is usually to let the cache warm, and to clear only the layer that is serving stale or broken content. Connect over SSH and use tscli:

tscli varnish clear    # purge stale full-page cache
tscli opcache clear    # force PHP to recompile after a code change

• See Clear the Redis cache, Clear the Varnish cache, and Flush the PHP OPcache for what each command does and what to expect.

• See Performance tuning for how the layers fit together and how to size them.

After clearing, expect the first requests to be slower while the caches refill. Warm critical pages by visiting them (or let your sitemap/crawler do it) before judging the result.

Slow database queries

A single slow or unindexed query can drag down an otherwise healthy site, especially in the admin or at checkout. If the database service check shows high load or long query times while CPU and RAM look fine elsewhere, the database is the bottleneck.

See Database connection and performance problems for how to spot slow queries, read the database logs, and size the buffer pool.

Slow PHP application code

When caches are warm and the database is healthy but pages are still slow, the time is being spent in PHP itself. Use the Blackfire profiler to find the exact functions and calls that are slow. Enable it temporarily over SSH, profile the slow request, then disable it again:

tscli blackfire enable
# ... reproduce and profile the slow page ...
tscli blackfire disable

Bot and crawler traffic

A surge of automated traffic - aggressive crawlers, scrapers, or a small attack - can saturate PHP and the database even when nothing else changed. On the Health graphs this shows up as a traffic spike that tracks the slowdown.

TurboShield watches request rates and throttles abusive clients automatically. Clients that exceed the limit receive a soft 429 response - a brief slowdown, not a firewall ban. Raising the protection level (low / medium / high / attack) tightens the limits during an event. See What is TurboShield?.

For a single clearly abusive address you can also block it directly:

tscli firewall check 203.0.113.10
tscli firewall block 203.0.113.10

Undersized or saturated resources

If CPU is pinned, RAM is full, or the host is swapping under normal traffic - with warm caches and no runaway query - the server has insufficient capacity for the current load. See High CPU and load and Out of memory to confirm.

When to optimize vs. scale

Optimize first, scale second:

• Optimize when the bottleneck is one layer: a cold or bypassed cache, a slow query, or inefficient PHP. Fixing the root cause is cheaper and faster than adding hardware.

• Scale (or raise an auto-tuned sizing key with evidence) only when the host is consistently resource-bound under legitimate traffic after caches are warm and code and queries are tuned. Adding capacity to mask an unindexed query or a misconfigured cache just postpones the problem.

The sizing keys (mysql_innodb_size, redis_memory, varnish_cache_size, and others) are auto-tuned to the server. Override them only with measured evidence - see Performance tuning.

Prevent it

• Keep caching enabled and warm; clear caches surgically, not reflexively.

• Set a monitoring_url on every production application so you are alerted to slowdowns early (see Monitoring).

• Profile heavy pages with Blackfire before they become a problem.

• Let TurboShield manage traffic rather than chasing individual bots.

• Make permanent config changes in the TurboStack Platform and a publish - tscli acts on the running server now but does not change saved config.

When to contact support

If the host stays slow after you have warmed the caches, ruled out the database, and confirmed it is not traffic - or if a managed layer looks misconfigured - open a ticket at Support. Include the host and domain, what changed (and when), the Health graphs or Top Issues you are seeing, and any relevant log output.

Related

• Performance tuning
• Database connection and performance problems
• High CPU and load
• Out of memory
• TurboStack CLI
• What is TurboShield?
• Health