Stacking caching plugins
Two page caches don't cache twice as well — they invalidate each other, double storage, and produce the bugs where customers see each other's carts. One cache per layer, configured properly.
ranjan@ranjan.info:~$ man services/performance-optimization
Server & Website Performance Optimization
Stop paying for hardware your configuration is wasting
Most "we need a bigger server" moments are actually configuration debt: default MySQL buffers, PHP-FPM pools sized by guesswork, no opcode cache, slow queries nobody ever profiled. I tune from evidence — measure, change one layer, measure again — and the result is usually a faster stack on the hardware you already pay for.
What is server performance optimization?
Server performance optimization is the measured tuning of each layer of a web stack — web server, PHP runtime, database, and caching — so the hardware you already own delivers the speed it's capable of. It starts with a baseline benchmark, finds the actual bottleneck (it's usually the database or missing caches, not CPU), fixes one layer at a time, and re-measures. Most untuned stacks halve their page times without any hardware change.
Written by Ranjan Chatterjee, Infrastructure Consultant · Linux Server Specialist · 15+ years in production Linux · Last reviewed
ranjan@ranjan.info:~$ dmesg | tail
Signs you need this now
Slow doesn't always look like slow. These are the shapes it takes in production — and each one has a findable cause.
- Time-to-first-byte over a second while the network is fine
- Load spikes whenever traffic does — a promotion shouldn't be an outage
- MySQL pinned at high CPU with the slow-query log empty (because it's off)
- WooCommerce or any logged-in traffic crawls while cached pages fly
- 502/504 errors under load — PHP-FPM pools exhausted
- A hardware upgrade that changed the bill but not the speed
- The host's answer to every complaint is the next plan up
- wp-admin and checkout are slow even when the homepage is fast
ranjan@ranjan.info:~$ cat scope.txt
What this covers
- Apache tuning: MPM sizing, keepalive, module diet
- Nginx tuning: worker model, buffers, caching layers
- LiteSpeed optimization: LSAPI, LSCache configuration
- MySQL / MariaDB tuning: buffer pool, connections, InnoDB
- Slow query analysis and index strategy
- Redis object and session caching
- OPcache configuration and hit-rate verification
- PHP-FPM pool sizing from real traffic patterns
- CloudLinux LVE limits tuned to actual usage
- Kernel and I/O scheduler tuning for the workload
ranjan@ranjan.info:~$ man first-aid
How to diagnose a slow server before tuning
Five steps that find the real bottleneck — and stop you from optimizing the wrong layer.
-
1
Measure before touching anything
Record TTFB and full-page times for your real money pages — home, product, checkout — under normal load. Without a baseline, every later change is an opinion.
-
2
Find which layer is slow
One request travels network → web server → PHP → database. Time each hop (curl timings, PHP profiling headers, query logs) — the slow layer is rarely the one everyone suspects.
-
3
Turn on the slow query log
MySQL will tell you exactly which queries hurt if you ask: log queries over one second for a day. The top three entries usually explain most of the pain.
-
4
Check memory and swap, not just CPU
A server dipping into swap makes everything mysteriously slow while CPU looks idle. Free memory, buffer pool size, and PHP-FPM totals must add up to less than RAM.
-
5
Change one thing, then re-measure
Stacked simultaneous changes can't be attributed — the classic result is a faster site and nobody knows which change did it (or which one is silently hurting). One layer at a time.
ranjan@ranjan.info:~$ grep -i "oops" ~/incidents.log
Mistakes that keep servers slow
Every one of these comes from a real engagement — usually from before I was called.
Upgrading hardware first
Un-indexed queries and unconfigured buffers scale beautifully — they waste the bigger server too. Tune first; if you still need hardware, at least you'll buy the right amount.
Copying my.cnf from the internet
A config tuned for someone else's RAM and workload can make yours worse — oversized buffers cause swapping, which is slower than the defaults ever were. Tuning follows measurement, not paste.
Benchmarking only the homepage
The homepage is cached and fast for everyone. Business slowness lives in the uncached paths — search, checkout, logged-in dashboards — which is exactly where benchmarks rarely look.
Treating high CPU as the diagnosis
"CPU is at 90%" is a symptom with a dozen causes: a runaway cron, a missing index, a scraping bot, PHP without OPcache. Naming the process and query behind the number is the actual diagnosis.
ranjan@ranjan.info:~$ diff --options
DIY, provider support, or a specialist?
An honest comparison — each option is right in some situations, including the free ones.
| Option | The right choice when… | Limits & risks |
|---|---|---|
| Caching plugin / DIY | A single WordPress site on decent hosting where page caching alone gets you most of the win. Cheap, quick, reversible. | Plugins can't fix server-level problems: MySQL buffers, PHP-FPM sizing, missing indexes. When logged-in traffic is the slow part, page caching by definition can't help. |
| Host's bigger plan | You're genuinely at capacity — measured, not guessed — or on hardware old enough that new-generation CPUs are a real jump. | Upgrading an untuned stack moves the same bottleneck to a bigger invoice. Hosts sell tiers, not diagnosis; "upgrade" is their answer to every symptom. |
| Specialist tuning | Real business traffic, database-heavy applications, WooCommerce/logged-in slowness, or when you want the before/after numbers proven rather than promised. | Costs more than a plugin. Extremely inefficient application code can bound the gains — in which case you'll get that finding in writing rather than an endless tuning engagement. |
What you get
- Before/after benchmarks on your real pages — not synthetic scores
- Every configuration change documented with the reasoning behind it
- Headroom analysis: what your current hardware can actually take, and when to scale
Why work with me on this
- 15+ years inside production Linux — this exact work, done at fleet scale
- Founder-operator of two hosting platforms: I've owned the uptime, not just the ticket
- Every change documented and reversible — you keep a written trail, not a mystery
- Plain-language updates and honest timelines you can plan a business around
ranjan@ranjan.info:~$ ./engage --how
How it runs
The same disciplined path on every engagement — scoped, planned, executed with checkpoints, handed off clean.
-
01
Scope
A short brief or call to understand your stack, the real problem, and what a good outcome looks like.
-
02
Plan
A clear architecture plan — steps, risks, rollback and timeline — agreed before anything touches production.
-
03
Execute
Hands-on work with checkpoints. You see progress; nothing changes on your servers silently.
-
04
Handoff
Documentation, access cleanup and a clear path for what comes next. No lock-in, no mystery.
ranjan@ranjan.info:~$ faq --service performance-optimization
Common questions
How much faster will my site actually get?
Untuned stacks routinely see page times halve, and database-bound apps often gain more — but I won't promise a number before measuring. The first deliverable is a baseline; the last is the same benchmark, re-run.
How long does performance tuning take?
Diagnosis and tuning typically complete within 3–5 days: baseline first, then layer-by-layer changes with measurements between them, then the final before/after report. Urgent "the site is crawling right now" cases can start same-day with triage first and the full pass after.
What does it cost?
Fixed price per server or per stack, quoted after a short description of your setup — no open-ended hourly tuning. If diagnosis shows the honest answer is application code or a hardware ceiling rather than configuration, you get that finding in writing instead of an endless engagement.
Should I just upgrade the server instead?
Upgrade after tuning, not instead of it — otherwise you carry the same bottlenecks onto more expensive hardware. Often the upgrade proves unnecessary; when it isn't, tuning first means you buy the right size.
Can you fix slow WordPress/WooCommerce sites?
Yes — that's a large share of this work. The fix is usually layered: object caching, OPcache, PHP-FPM sizing, slow-query cleanup, and page caching that actually survives cart sessions.
Will the changes break my site?
Each change is applied one layer at a time, measured, and reversible — configs are versioned before editing and nothing is "optimized" blind. The riskiest class of change (database indexes on big tables) is scheduled into your low-traffic window with tested rollback.
Do I need a CDN?
For static assets and global audiences, a CDN helps and is cheap — often free at Cloudflare's tier. But a CDN can't fix a slow backend: TTFB on dynamic pages comes from your server. Tune the origin first; then a CDN makes a fast site fast everywhere.
What do you actually deliver at the end?
Three things: the tuned stack itself, a before/after benchmark on your real pages (not synthetic scores), and a written change log with the reasoning for every modification — plus a headroom estimate for when scaling genuinely becomes necessary.
When is more hardware actually the right answer?
When measurements say so: a properly indexed database whose working set genuinely exceeds RAM, CPU saturated by legitimate application work after OPcache and caching are in place, or real traffic growth against a tuned stack. At that point the same measurements tell you exactly which resource to buy — which is the difference between scaling and guessing.
Is this one-time, or does performance need maintenance?
The tuning pass is one-time and holds as long as the workload resembles what was measured. Traffic growth, new plugins, and data growth shift bottlenecks over time — most clients either re-benchmark yearly or fold monitoring into a managed administration retainer so regressions get caught as trends, not complaints.
ranjan@ranjan.info:~$ man glossary
Terms you'll hear during tuning
Plain-language definitions — so the report reads like information, not incantation.
- TTFB
- Time to first byte — how long the server thinks before it starts answering. The purest measure of backend speed.
- OPcache
- PHP's bytecode cache: compiled scripts stay in memory instead of being recompiled every request. The cheapest big win on most PHP servers.
- Object cache
- Redis or Memcached storing computed results and sessions so the database isn't asked the same question a thousand times a minute.
- Buffer pool
- InnoDB's working memory. Sized right, your hot data lives in RAM; left at defaults, MySQL reads from disk while your RAM sits idle.
- PHP-FPM pool
- The set of PHP worker processes. Too few queues requests into 502s; too many swaps the server into molasses. Sizing comes from real traffic.
- Slow query log
- MySQL's confession file — every query slower than a threshold, with timing. The first document opened in any database diagnosis.
- Page cache vs. dynamic
- Cached pages serve from memory in microseconds; logged-in and cart traffic must execute code. Both paths need to be fast — they're tuned differently.
- LVE limits
- CloudLinux's per-account resource caps on hosting servers — protection against noisy neighbors that, mis-sized, becomes the bottleneck itself.
ranjan@ranjan.info:~$ ls ../related
Related services
Engagements that commonly pair with this one.
Infrastructure Audit
Security, performance, cost, and disaster recovery — one honest report.
View serviceManaged Server Administration
24×7 monitoring, patching, backups, and incident response on a flat monthly retainer.
View serviceZero Downtime Website Migration
Sites, mail, databases, DNS — migrated in a planned cutover, not a leap of faith.
View serviceranjan@ranjan.info:~$ ssh [email protected]
Ready when you are
One paragraph is enough: your stack, the symptom, and when you need it solved. Emergencies are answered first.