How to Optimize a cPanel Server for Better Performance

Most cPanel optimization advice is a list of switches to flip. Enable OPcache, install LiteSpeed, raise the MySQL buffer, done. Some of those switches help on every server; most help on some servers and do nothing, or harm, on others, because a 4 GB VPS with 8 WordPress sites and a 64 GB reseller box with 300 accounts are not the same machine and do not have the same bottleneck. This guide is the way we approach performance on the servers we build for customers and on our own: measure first, find the bottleneck, change one thing, measure again.

Who this is for: root administrators of a WHM/cPanel VPS or dedicated server whose sites are slow or whose load average keeps climbing. If you are on shared hosting, the server-level tuning is your host's job; the application-level parts (caching plugins, image sizes, PHP version) still apply inside your account.

What's in this guide

• Measure before you change anything
• Which bottleneck do you actually have?
• PHP: versions, PHP-FPM and OPcache
• Web server: Apache tuning and when LiteSpeed is worth it
• Caching: page, object and browser layers
• MySQL and MariaDB tuning
• CloudLinux: limits as a performance tool
• CPU and RAM: sizing and swap
• Disk I/O: the bottleneck nobody checks
• Housekeeping: crons, logs, mail and backups
• Keep measuring: monitoring after optimization
• FAQ

Measure before you change anything

The most common optimization mistake is changing five things at once and not knowing which one helped. Twenty minutes of measurement before touching anything saves a weekend of guessing. These are the numbers we collect on every server, from SSH, before any tuning:

# Load and CPU
uptime
top -bn1 | head -20
mpstat 1 5            # sysstat; watch %steal on a VPS and %iowait everywhere

# Memory and swap
free -h
vmstat 1 5            # si/so columns: swapping in and out

# Disk wait and throughput
iostat -xz 1 5        # %util and await per disk
iotop -oa             # which processes are actually writing

# Who is using the CPU on a cPanel box
ps aux --sort=-%cpu | head -15
/scripts/find_outdated_services   # anything restarting itself in a loop?

# Web tier
tail -n 2000 /usr/local/apache/logs/access_log | awk '{print $1}' | sort | uniq -c | sort -rn | head   # top IPs
curl -o /dev/null -s -w "TTFB %{time_starttransfer}s total %{time_total}s\n" https://example.com/

Write the numbers down: load average at a busy hour, peak RAM used, swap used, %iowait, %steal, TTFB of two or three real sites. That is your baseline. Every change below is judged against it. The commands themselves, with a copy button on each, are in our Linux commands for cPanel servers.

Which bottleneck do you actually have?

A slow server is slow for one dominant reason at a time. Match your measurements to the row and jump to that section; do not start at the top and work down.

What you see	Likely bottleneck	Fix first
Load above the number of cores, %user high, php-fpm or lsphp at the top of top	CPU-bound PHP	OPcache, PHP-FPM pools, PHP version, then page caching
Load high, %iowait above 10%, await in the tens of ms	Disk I/O	Find the writer: backups, logs, MySQL, a runaway cron
Swap in use, si/so non-zero, OOM messages in dmesg	RAM	Trim PHP-FPM and MySQL memory, then buy RAM
%steal above 5% on a VPS	Noisy neighbour at the provider	Nothing on your side fixes this; move the VPS or go dedicated
mysqld at the top of top, slow query log filling up	Database	Buffer pool, slow queries, indexes
One account's processes everywhere; other sites fine until it spikes	No isolation	CloudLinux LVE limits
Thousands of requests per minute from a few IPs or bots, Apache MaxRequestWorkers reached	Request volume	LiteSpeed or MPM event, rate-limit bots, a page cache
Everything looks fine on the server, sites still slow	Application or network	Slow plugins, external API calls, DNS, no caching plugin; profile the site, not the server

PHP: versions, PHP-FPM and OPcache

On most cPanel servers PHP is where the CPU goes, and three changes account for most of the improvement available: a current PHP version, PHP-FPM instead of suPHP or CGI, and OPcache with enough memory.

PHP version. Each major PHP release has been measurably faster than the last for typical WordPress and Laravel workloads; PHP 8.x runs the same code in noticeably less CPU time than 7.4, which is also end-of-life and unpatched. In MultiPHP Manager, set the system default to the newest version your applications support and move accounts up one version at a time, checking the site after each move. Keep old versions installed only for the accounts that genuinely need them, and plan their retirement.

PHP-FPM. Enable it per account in MultiPHP Manager. FPM keeps a pool of PHP workers alive between requests instead of starting a new interpreter for each one, which is why it beats suPHP under any real load. The setting that matters is the pool size: pm.max_children per account, set in MultiPHP Manager's PHP-FPM options or in the account's pool YAML under /var/cpanel/userdata/. Every child can use up to memory_limit, so the arithmetic is simple: the sum of max_children across busy accounts multiplied by memory_limit must fit in RAM after MySQL and the OS take theirs. On a 4 GB VPS with 10 small sites, 3 to 5 children per account and a 256M memory_limit is realistic; on a large reseller box, use pm = ondemand with a short pm.process_idle_timeout so idle accounts hold no workers at all.

OPcache. Compiled PHP bytecode stays in shared memory, so each request skips parsing and compiling. It is installed per version as ea-php8X-php-opcache and enabled by default in recent EasyApache profiles; confirm with a phpinfo page. Tune it in the MultiPHP INI Editor or an opcache.ini:

opcache.enable=1
opcache.memory_consumption=256      ; MB; 128 for a few sites, 256-512 for many
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000 ; more than the total PHP files on the box
opcache.validate_timestamps=1
opcache.revalidate_freq=60          ; check files for changes once a minute, not every request

If opcache_get_status() shows the cache full or restarts climbing, raise memory_consumption. On a per-account PHP-FPM setup each pool has its own OPcache, so the memory is per account; that is the price of isolation and it is worth paying.

Web server: Apache tuning and when LiteSpeed is worth it

Apache with MPM event and PHP-FPM is a good web server for most cPanel workloads. LiteSpeed Enterprise is worth its licence when request volume, not PHP execution, is the constraint, or when your sites are WordPress and can use LSCache.

Apache. In EasyApache 4 choose MPM Event; Prefork spends a whole process per connection and runs out of RAM under a modest crawl. Then in Global Configuration set MaxRequestWorkers to what the RAM allows (each worker thread is cheap under event, so 400 to 1,000 is normal), KeepAlive On with a short KeepAliveTimeout of 2 to 5 seconds, and Timeout down from the default 300 to 60 so stalled clients release their slots. Enable HTTP/2 and Brotli or gzip compression. Remove modules you do not use: mod_userdir, mod_status if not needed, old PHP handlers.

LiteSpeed. LiteSpeed's event-driven architecture handles many thousands of concurrent connections in far less memory than Apache, reads your existing .htaccess files, and, crucially, ships LSCache: a server-level page cache that the LiteSpeed Cache plugin for WordPress, Joomla, Magento and others controls precisely, so cached pages are served without starting PHP at all. On a server whose sites are mostly WordPress, that single change often does more than every other item in this guide combined, because the majority of requests stop touching PHP and MySQL. It requires a LiteSpeed licence sized by CPU cores and worker count; on a 2-core VPS the smallest tier is enough. Install it before accounts exist if you can; switching later is safe but should be done in a maintenance window. Tune in the WebAdmin console: max connections, PHP lsapi children per account (same arithmetic as PHP-FPM), and enable the cache storage path on fast disk.

What LiteSpeed does not do: make slow PHP fast. If a site is slow because a plugin runs 300 database queries on every uncached page load, LiteSpeed makes the cached version instant and the uncached version exactly as slow as before. Logged-in users, carts and admin pages are uncached by design.

Caching: page, object and browser layers

Caching works because most requests ask for the same thing. There are three layers and each one answers a different question:

• Page cache: "Have we rendered this URL for an anonymous visitor recently?" LSCache on LiteSpeed, or a plugin-level cache (WP Super Cache, W3 Total Cache, or the LiteSpeed Cache plugin in file mode) on Apache. This is the biggest win for content sites. Set sensible TTLs and purge on publish.
• Object cache: "Have we run this database query recently?" Redis or Memcached, installed server-wide and enabled per site with a plugin. Helps logged-in and dynamic sites (WooCommerce, forums, membership) that the page cache cannot serve. cPanel does not install Redis; it is a dnf install redis plus the PHP extension per version, and it needs RAM (set maxmemory and an eviction policy).
• Browser and CDN cache: "Does the visitor already have this file?" Long Cache-Control headers for static assets in Apache or LiteSpeed configuration, and optionally a CDN in front. The security guide covers the trade-offs of putting a CDN in front of the server.

Measure caching with hit ratio, not feelings: LiteSpeed's x-litespeed-cache: hit response header, the plugin's own statistics, or redis-cli info stats for keyspace hits versus misses.

MySQL and MariaDB tuning

The default database configuration cPanel installs is sized for a machine with far less RAM than yours, and the single most important setting is innodb_buffer_pool_size. InnoDB keeps table and index data in that buffer; when it is too small, every query goes to disk, which shows up as I/O wait and slow pages even though "the database" looks idle.

Edit /etc/my.cnf under [mysqld], then restart with /scripts/restartsrv_mysql:

[mysqld]
innodb_buffer_pool_size = 1G        # ~25% of RAM on a mixed hosting server; up to 60% on a DB-heavy box
innodb_log_file_size    = 256M      # larger log = fewer flushes; needs a clean restart to change
innodb_flush_method     = O_DIRECT  # avoid double-caching with the OS on Linux
innodb_file_per_table   = 1
max_connections         = 150       # each connection costs RAM; 150 is plenty for most cPanel servers
table_open_cache        = 4000
tmp_table_size          = 64M
max_heap_table_size     = 64M
slow_query_log          = 1
slow_query_log_file     = /var/lib/mysql/slow.log
long_query_time         = 1

Then wait a day and read the slow log. On hosting servers the pattern is always the same: a handful of sites produce nearly all the slow queries, usually a WordPress plugin doing a full-table scan on wp_options or wp_postmeta, or a forum search. Fixing those is an index or a plugin change inside the account, not a server setting, and it does more than any my.cnf tweak. mysqltuner.pl (a Perl script you download and run as root) reads your running statistics and tells you which buffers are too small or too large; run it after 24 hours of uptime, not right after a restart, because it needs real traffic to judge.

Two cautions. Do not chase the MySQL query cache; MySQL 8 removed it and MariaDB disables it by default because it hurt concurrency. And leave innodb_buffer_pool_size below the point where PHP-FPM children and the OS start swapping; a swapping database is slower than a small buffer.

CloudLinux: limits as a performance tool

On a server hosting multiple customers, the biggest performance problem is rarely average load; it is the one account that spikes and takes everyone with it. CloudLinux LVE turns that into a problem only that account has.

CloudLinux wraps every account in a Lightweight Virtual Environment with hard limits: CPU (as a percentage of one or more cores), physical memory, IO throughput, IOPS, entry processes (concurrent requests) and total processes. When a site hits its limit it slows down or returns a 508 error; the server keeps serving everyone else at full speed. The limits are set per package in WHM's LVE Manager, so a reseller can sell tiers that mean something. Start with the defaults (100% CPU, 1 GB PMEM, 20 EP, 100 NPROC) and lower them for cheap packages.

Beyond limits, CloudLinux brings the PHP Selector (customers pick their own PHP version and extensions without a ticket), MySQL Governor (per-account database limits, so one site's bad queries cannot lock MySQL for everyone), and, on the Shared Pro licence, AccelerateWP (object caching and image optimisation offered to WordPress sites from cPanel). The LVE statistics in lveinfo and in cPanel's Resource Usage screen are also the best data you will get about which accounts are expensive, which is where a reseller's pricing conversations start.

CPU and RAM: sizing and swap

At some point a server is simply full, and the honest optimization is a bigger server. The signs: load consistently above the core count at ordinary hours (not just during a backup), swap in regular use, and OPcache and buffer pool already sized well. Tuning cannot conjure a fifth core.

Before you upgrade, reclaim what you can. Add up the memory: MySQL's buffer pool and per-connection buffers; PHP-FPM max_children across accounts times memory_limit; LiteSpeed or Apache workers; ClamAV (which holds about 1 GB of signatures in RAM and is a common surprise on small VPS plans); Imunify360 and any Redis. If the total exceeds RAM, something swaps under load. Trim children and buffers first, disable ClamAV if no one uses cPanel's virus scanner, and move Redis to a strict maxmemory. Keep a small swap partition or file (1 to 2 GB) as a safety net with vm.swappiness=10, so the kernel avoids it until it must; a server with no swap does not get slower under memory pressure, it kills MySQL.

On a VPS, watch %steal in mpstat or top. Steal is CPU time the hypervisor gave to another customer while yours waited; anything above a few percent means the host is oversold and no setting on your side will fix it. That is when a dedicated server stops being a luxury.

Disk I/O: the bottleneck nobody checks

High load with low CPU use almost always means the disk, and on cPanel servers the usual culprits are backups, logs, MySQL flushes and someone's cron job, not visitors. iostat -xz 1 shows %util and await per device; iotop -oa shows which process is doing the writing.

• Storage type: NVMe or at least SSD. Spinning disks are the wrong choice for a hosting server in 2026; database and mail workloads are random I/O, which is exactly what they are worst at. If your provider's plan says HDD, that is the bottleneck and the fix is a different plan.
• Backups: cPanel's nightly backup compresses every account; on a large server that is hours of I/O. Move it to the quietest hour, enable incremental backups (or use JetBackup with incremental mode), and back up to a remote destination so the local disk is not written twice.
• Logs: Apache and LiteSpeed write a line per request per domain; with thousands of requests per second that is real I/O. Rotate daily, keep them short, and consider disabling bytes logging or per-domain access logs on sites that do not need statistics. The statistics processors themselves (Awstats, Webalizer, Analog) run through every log nightly; in Statistics Software Configuration, disable the ones no customer looks at.
• MySQL: the innodb_log_file_size and innodb_flush_log_at_trx_commit settings decide how often it flushes to disk; the values above are a sane balance for hosting. Temporary tables on disk (visible in SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables') mean tmp_table_size is too small or a query needs an index.
• Runaway processes: a malware scan, a stuck rsync, a customer's WordPress backup plugin zipping 20 GB at noon. iotop names them; CloudLinux's IO and IOPS limits stop the customer-side ones from hurting anyone else.

Housekeeping: crons, logs, mail and backups

The unglamorous items that quietly cost a server a core:

• Cron jobs: customers' crons often run every minute because a plugin's instructions said so. grep -r "\* \* \* \* \*" /var/spool/cron/ finds them. WordPress's own wp-cron runs on every page load by default; a real cron every 5 minutes with DISABLE_WP_CRON in wp-config.php is lighter and more reliable.
• cPanel's own maintenance: upcp, backups, statistics and the nightly cpanellogd all run in the small hours. Stagger them (Tweak Settings and Backup Configuration) so they do not overlap at 3 AM.
• Mail queue: a queue of thousands of messages is both a security incident and an I/O and CPU drain as Exim retries them. exim -bpc daily.
• Disk space: a full disk turns every operation into a failure. Alerts at 80% and 90% in WHM's Contact Manager, and a cleanup routine for old backups, logs and /tmp. The cleanup commands are in the Linux commands list.
• Unused services: Mailman, cpdavd, ProFTPD, Spamd on a server without mail, ClamAV on a server whose customers never scan. Service Manager, off. Each one is RAM and a process that wakes up for no one.

Keep measuring: monitoring after optimization

Optimization is not a project with an end date; it is the same measurements repeated while the server fills up. After each change, take the baseline numbers again at the same hour and keep a simple record: date, change, load, TTFB. Keep the changes that moved a number; revert the ones that did not, because every setting you cannot explain is a future 3 AM mystery.

The ongoing version of this, what to watch every day, what to review every week and month, alerts, and when to call it "the server needs to grow", is the subject of the cPanel server management and monitoring guide. If you would rather the initial sizing was done for you, PHP-FPM pools, OPcache, MySQL buffers, LiteSpeed workers and CloudLinux limits matched to your hardware and documented in a handover note, that is part of our $50 cPanel server installation, and the setup guide shows where in the build each setting is made.

FAQ

Does LiteSpeed always make a cPanel server faster?

No. LiteSpeed reduces the cost of serving requests and adds a page cache; it does not speed up PHP execution or database queries. Sites that are mostly cacheable (blogs, brochure sites, WooCommerce catalogues for anonymous visitors) get dramatically faster. Applications whose every page is dynamic and per-user see modest gains in connection handling and memory, and none in PHP time. Measure TTFB for a logged-out and a logged-in page before and after; the difference between the two tells you what LiteSpeed can and cannot do for that site.

How much RAM does a cPanel server need?

cPanel's minimum is 2 GB and its recommendation is 4 GB. In practice: 4 GB for a handful of low-traffic sites, 8 GB for a small reseller server or a busy WooCommerce site, 16 GB and up for 100+ accounts. Add roughly 1 GB if you run ClamAV and 1 GB for Imunify360, and size the InnoDB buffer pool and PHP-FPM pools to what is left.

Should I enable the MySQL query cache?

No. MySQL 8 removed it and MariaDB ships it disabled because it serialised queries under concurrency and often made busy servers slower. Use InnoDB's buffer pool, proper indexes, and an object cache (Redis) at the application layer instead.

What is a good load average for a cPanel server?

Sustained load below the number of CPU cores. A 4-core server at load 3 is busy but healthy; at load 8 requests are queueing. Brief spikes during backups or cron runs are normal. What matters is the trend at your busiest hour, which is why the baseline measurement should be taken then, not at midnight.

Is it worth upgrading from PHP 7.4 to 8.x for performance alone?

Yes, and also because 7.4 stopped receiving security fixes in November 2022. PHP 8 executes typical WordPress code in noticeably less CPU time, which on a CPU-bound server translates directly into more requests per core. Test each site on the new version first; a plugin that still uses removed PHP 7 functions will break, and those plugins should be replaced anyway.

My server is fast but one website is slow. Is that a server problem?

Usually not. If load, RAM and disk are healthy and other sites on the same server respond quickly, the slow site is slow inside its own code: a heavy theme, too many plugins, uncached external API calls, unoptimised images, or a plugin doing expensive queries. The slow query log and a profiling plugin (Query Monitor for WordPress) find it in minutes. Server tuning cannot fix an application that does too much work per request.