Docket Cache On Shared Hosting
We built Docket Cache for shared hosting. Most shared plans do not offer Redis or Memcached, but almost all of them let PHP write files and turn on OPcache. That is all Docket Cache needs.
Shared hosting also has limits that are easy to miss. This post explains the limits that matter for a file cache, and which Docket Cache settings to change first.
The limits that matter#
A shared plan lists disk space and bandwidth on the price page. The limits that decide how your site behaves when it is busy are often in the small print.
- Disk activity. How much your account may read and write each second, and how many read and write operations it may do. Hosts call these IO and IOPS.
- Number of files. Every file and every folder counts as one inode. Your account can run out of inodes while most of its disk space is still free.
- Processes. How many PHP requests may run at the same time. Hosts call these entry processes, or EP.
The disk limits do not show an error. When your site reaches them, it simply slows down. Slow requests then take longer to finish, they pile up, and the process limit fills. That is when visitors see a "508 Resource Limit Reached" error. So a 508 error often starts with a disk problem.
If your host uses cPanel with CloudLinux, the Resource Usage page shows each limit, and a "fault" each time your site reached it. Look at the time of the faults first. They often line up with a backup, a malware scan or an import.
Where Docket Cache fits#
Docket Cache saves each cached item as a small PHP file, so it uses disk writes and inodes. We want to be clear about that. A Redis or Memcached server does not use them, but those are rarely offered on shared plans.
Reading is where Docket Cache saves work. OPcache keeps the cache files in memory, so most reads do not touch the disk at all. Our post How Docket Cache Uses OPcache explains how. Most disk activity comes from writing new cache files, and from the garbage collector cleaning up old ones.
To see how many files the cache uses, run these commands from your WordPress folder.
find wp-content/cache/docket-cache -type f | wc -l
du -sh wp-content/cache/docket-cache
On one of our test sites, the result was small.
71
600K wp-content/cache/docket-cache
A busy shop can have tens of thousands of files. The Overview screen shows the same numbers under Cache Files Limit and Cache Disk Limit.
Settings to change first#
By default, Docket Cache keeps up to 50,000 cache files and up to 500 MB on disk. That is fine on most hosts. If your plan has a low inode limit, lower both in wp-config.php.
define('DOCKET_CACHE_MAXFILE', 20000);
define('DOCKET_CACHE_MAXSIZE_DISK', 104857600);
The file limit can be anything from 200 to 1,000,000. The disk limit cannot be lower than 104857600 bytes, which is 100 MB. When the cache goes over a limit, the garbage collector removes files until it is back under it.
A lower file limit also helps OPcache. With PHP's default settings, OPcache has room for about 16,000 files in total, and your WordPress files need some of that room too.
If the cache still has too many files, these options help.
DOCKET_CACHE_FLUSH_DELETEdeletes an expired cache file at once. By default, the file is only emptied, and it keeps its inode until the garbage collector removes it.DOCKET_CACHE_IGNORED_GROUPSstops whole cache groups from being saved. This helps when one plugin creates a very large number of entries.
Keep the Cache Log option off unless you are looking for a problem, because the log is one more file that is written all the time.
The Constants page explains each option, and the Web Hosting I/O Usage page has more options for sites that are short of inodes.
Keep the garbage collector running#
The garbage collector is a WordPress scheduled task that runs every 5 minutes. It removes expired files and keeps the cache within its limits.
WordPress scheduled tasks, called WP-Cron, run when someone visits your site. Usually that is enough. The same visits that add cache files also start the garbage collector. On a quiet site, it runs less often, but few new files are written either.
The problem is a site where WP-Cron cannot run at all. The cache keeps growing with each visit, but nothing cleans it up. This happens in two cases.
- WP-Cron is turned off. Some hosts and speed guides add
define('DISABLE_WP_CRON', true);towp-config.php. That is fine only if a real cron job runs WP-Cron instead. - Your host blocks the loopback request. To start WP-Cron, WordPress sends a request to its own site. Some hosts and firewalls block it. Tools > Site Health then shows that your site could not complete a loopback request.
To check, look at Cache Files Limit on the Overview screen for a few days. If the number only goes up, the garbage collector is probably not running. You can fix this in two ways.
- Cronbot. Connect your site on the Docket Cache > Cronbot screen. Our free Cronbot service then pings your site every hour, and each ping runs the tasks that are due. Our post Cronbot Is Now Written In Go explains how it works.
- A cron job from your host. If your host lets you add cron jobs in cPanel, run
wp-cron.phpevery 5 minutes. This is more often than Cronbot, but some hosts count each run against your process limit.
Other things that help#
- Suspend Options Autoload. WordPress loads many settings on every page, in one big list. Docket Cache can keep plugin settings out of that list, so they only load on pages that need them. Our post Suspend WordPress Options Autoload explains it.
- Move heavy jobs to a quiet hour. Backups and scans use far more disk than Docket Cache. Run them at night, and save backups to remote storage, not to your hosting account.
- Turn off debug logs.
WP_DEBUG_LOGwrites to disk every time PHP shows a notice or a warning, which can be on every page load.
When it is time to move on#
If your site keeps reaching its limits after all this, it may have outgrown the plan. A VPS with Redis may then be the better choice. Our post Docket Cache, Redis Or Memcached? helps you decide.