On this page
What server performance optimization involves
When a site slows down, the instinct is to upgrade the server. Sometimes that is right. Often it is not: the slowdown comes from a single slow query, a missing index, a misconfigured PHP or database setting, a cache that is not being used, or disk I/O from logs. A bigger server can hide the problem for a while at a higher monthly bill.
Performance optimization means finding the actual bottleneck with measurements, fixing it, and confirming the result with numbers rather than impressions.
Warning signs
- Pages slow down at particular times of day, or during an e-commerce sale or course launch.
- CPU or memory sits high even when traffic seems normal.
- The database server is the busiest process on the machine.
- Your hosting bill has increased through upgrades but the site is not noticeably faster.
- A SaaS dashboard or report takes much longer as customer data grows.
What we look at
- Resources: CPU, memory, swap, disk I/O and network, over time rather than in a single snapshot.
- Database: slow query logs, missing indexes, connection limits and buffer sizes.
- Application runtime: PHP-FPM workers, Node.js process counts, Python application server workers.
- Web server: compression, caching headers, keep-alive and static file handling.
- Caching: object caching with Redis, page caching and CDN caching where appropriate.
- Background work: cron jobs and queues competing with visitor traffic.
- A report with before-and-after measurements and recommendations for anything not fixed.
Our method
- Measure: establish a baseline of response times and resource use under normal and busy conditions.
- Identify: trace the slowest requests to the component responsible.
- Fix: address the biggest constraint first, one change at a time.
- Verify: measure again under the same conditions to confirm the improvement.
- Repeat or stop: continue while changes are worthwhile, and tell you honestly when an upgrade is the right answer.
Tools we use
We use standard Linux tools such as htop, iostat and vmstat, database slow query logs and EXPLAIN plans for MySQL, MariaDB and PostgreSQL, and load testing tools to reproduce busy periods safely. For ongoing visibility, Prometheus and Grafana show trends over time. Caching and delivery improvements may involve Redis, Nginx and Cloudflare.
If the bottleneck is in application code or the deployment pipeline, our DevOps Performance Optimization service goes deeper into queries and code paths.
What affects timeline and cost
A single server with an obvious bottleneck can be improved quickly. Time grows when problems only appear under specific load, when there is no staging environment to test in, when several components interact, or when fixes require application code changes that your developers need to make.
Where the fix is an application code change, such as rewriting a query or adding pagination, we document exactly what needs to change and why. Your developers can make it, or we can if we have access to the codebase.
Access to realistic data also matters. Problems that only appear with a production-sized database are hard to reproduce on an empty staging copy, so we agree a safe way to test against representative data early on.
Typical findings
Every server is different, but certain patterns come up again and again. These are the kinds of issues we commonly find, and what fixing them usually involves:
| Symptom | Common cause | Typical fix |
|---|---|---|
| Slow pages that get worse as data grows | Missing database indexes or inefficient queries | Add indexes, rewrite the worst queries |
| High memory use and swapping | Too many PHP or application workers for the RAM | Right-size worker counts and limits |
| Spikes at fixed times | Heavy cron jobs or backups during busy hours | Reschedule or throttle background work |
| Slow for repeat visitors | No caching headers or object cache | Browser caching, Redis, CDN rules |
| High disk I/O | Verbose logging or database settings | Adjust logging and database buffers |
The order matters. Fixing the largest constraint first often reveals the next one, so we work in steps and measure after each, rather than applying a long list of tweaks at once and hoping the combination helps.
Common mistakes
- Upgrading hardware before measuring anything.
- Changing several settings at once, so nobody knows which one helped or hurt.
- Copying database tuning values from a guide written for a much larger server.
- Caching aggressively and serving stale or personal data to the wrong visitors.
Related: Server Monitoring and High Availability Setup. See Cloud & Server Management, the cloud and server guide, or contact us.
Frequently asked questions
Will this definitely avoid a server upgrade?
Not always. Sometimes the server really is too small. We measure first and tell you honestly which situation you are in.
Can you optimise without touching our code?
Often, through server, database and caching changes. If the main issue is in the code, we explain what needs to change and can work with your developers.
How do you prove the improvement?
We record response times and resource use before and after, under comparable conditions, and include the figures in the report.
Is load testing risky on a live server?
It can be, so we test in staging where possible, or run controlled tests at quiet times with your agreement.
Should we use a CDN for performance?
For sites with visitors in several regions, or with lots of images and scripts, a CDN such as Cloudflare often helps noticeably. It does not fix slow server-side processing, which is why we look at both.
Talk to us about performance optimization
Profiling and tuning so your server handles the load without paying for a bigger one.