How to Optimize Your Server for Better Performance

To optimise a server for better performance, measure first to find the real bottleneck, then fix it in this order: application caching, PHP or application workers, the database, the web server, and finally the operating system and hardware. Most performance problems on web servers come from a small number of causes: no caching, too few or too many workers, an untuned database, or simply not enough memory.

This guide is written for VPS and dedicated servers where you control the configuration.

1. Measure before changing anything

Collect a baseline under realistic load:

• CPU, load average and memory (including swap) over time;
• disk I/O wait;
• response times of key pages, both cached and uncached;
• slow logs: PHP-FPM slow log and the database slow query log.

Standard tools such as top, htop, free -m, iostat and your control panel's resource graphs show these numbers. Change one thing at a time and measure again.

2. Add caching at the right layers

• Full-page cache for anonymous traffic (LSCache on LiteSpeed, FastCGI cache on Nginx, or an application-level cache).
• Object cache (Redis or Memcached) for logged-in and dynamic requests.
• OPcache for PHP, which stores compiled PHP code in memory. Make sure it is enabled and has enough memory for all your code.
• Browser caching and compression for static files.

Caching usually gives larger gains than any server tuning.

3. Tune PHP-FPM workers

PHP-FPM runs a pool of worker processes. The key setting is the maximum number of workers (pm.max_children):

max workers ≈ memory available for PHP ÷ average memory per worker

• Too few workers: requests queue up and pages wait even though CPU is idle.
• Too many workers: memory runs out, the server swaps, and everything slows down.

Measure the real memory per worker under load, leave room for the database and other services, and choose a process manager mode (dynamic or ondemand) that suits your traffic. Enable the slow log to find scripts that take too long.

4. Tune the database

For MySQL or MariaDB:

• size the InnoDB buffer pool to hold your working data set, within available memory;
• enable the slow query log and fix the slowest queries, usually with indexes;
• avoid huge, unindexed tables of logs or sessions;
• keep the number of connections reasonable.

MariaDB's slow query log overview explains how to find the queries worth fixing.

5. Configure the web server sensibly

• Serve static files directly from the web server, with long cache lifetimes for versioned files.
• Enable HTTP/2 (and HTTP/3 if supported) and compression (gzip or Brotli).
• Set reasonable timeouts and keep-alive settings.
• Choose a web server that fits your stack: Apache for .htaccess compatibility, Nginx for efficient static files and proxying, LiteSpeed for Apache compatibility with built-in caching.

6. Check storage and memory

• I/O wait consistently high means storage is a bottleneck: move to faster storage (NVMe) or reduce disk writes.
• Swap in constant use means the server needs more memory or fewer workers.
• Keep at least 20% of disk space free.

7. Reduce unnecessary work

• Remove services you do not use.
• Move heavy cron jobs and backups to quiet hours.
• Block abusive bots and rate-limit expensive endpoints.
• Offload email sending, search or media processing to dedicated services if they dominate resources.

8. Keep software current

Newer PHP, database and web server versions often bring performance improvements as well as security fixes. PHP lists which versions still get fixes on its supported versions page.

9. Know when to scale

If the server is well tuned and still runs out of CPU or memory at normal traffic levels, it is time to add resources or split roles (for example, a separate database server). Size the upgrade from your monitoring data, not from guesswork.

Worked example: tuning a WordPress VPS step by step

A 4 vCPU, 8 GB VPS hosts a busy WordPress site. Pages are slow at peak times. The tuning sequence:

1. Baseline: uncached TTFB around 1.2 s; load average spikes to 8 at peak; memory available drops near zero; swap grows.
2. Page cache: a server-level full-page cache is enabled for anonymous visitors. Peak load falls sharply because most visits no longer run PHP.
3. PHP-FPM: pm.max_children was set to 80, far more than memory allows (80 × ~90 MB ≈ 7 GB). Reduced to 30, which fits in the memory left after the database. Swapping stops.
4. OPcache: opcache.memory_consumption raised so all scripts fit; the OPcache status shows no more restarts due to full memory.
5. Database: the slow query log reveals one plugin's query scanning a large table; an index fixes it. The InnoDB buffer pool is set to 2.5 GB, fitting the working set.
6. Object cache: Redis added for logged-in users and the admin.
7. Result: uncached TTFB about 0.4 s, cached pages about 0.05 s, peak load around 2.

Each change was measured separately, which made it clear which ones mattered.

Common mistakes

• Copying "optimal" configuration values from the internet without measuring.
• Raising PHP-FPM workers until memory runs out.
• Making the database buffer pool larger than the available RAM.
• Adding caching layers that conflict with each other.
• Tuning the server when the real problem is a slow plugin or query.

Frequently Asked Questions

What is the single biggest performance improvement?

For most websites, effective page caching. For applications with many dynamic requests, database indexing and enough memory.

Should I use a control panel's default settings?

They are a safe starting point, but defaults are generic. Adjust them based on monitoring of your actual workload.

Related reading

If you are still deciding what kind of hosting you need, see shared hosting vs VPS. If you would rather have experts tune and look after the server, see ServerNeed managed VPS.

Sources

• PHP Manual: FPM configuration
• PHP Manual: OPcache
• MariaDB documentation: InnoDB buffer pool
• MariaDB documentation: Slow query log overview
• PHP: Supported versions

Featured image: “NDL Server Room taking shape” by jblyberg, licensed under CC BY 2.0.