Using PHP APCu on Plesk: Installation, Tuning, and Pitfalls

APCu is a lightweight in-memory cache for PHP that can dramatically cut database and API load on Plesk-based servers. In this guide we walk through what APCu is, how to install it against Plesk’s PHP builds, how to enable and tune it per domain, and what pitfalls to watch for so you don’t accidentally starve your VPS of memory or end up with a thrashing cache.If you’re hosting PHP apps on a Plesk server—WordPress, Drupal, Nextcloud, or custom apps—caching is one of the easiest ways to squeeze out more performance without touching application code.

Most people know about OPcache (the PHP bytecode cache), but fewer know about APCu, the user-data cache that lives right alongside it. On a typical single-server Plesk deployment, APCu can drastically reduce database and API calls with just a small amount of configuration.

In this article, we’ll cover:

• What APCu is (and how it differs from OPcache)
• How to install APCu on a Plesk Obsidian server
• How to enable and configure it per-domain in Plesk
• Key tunable parameters (with practical starting values)
• Disadvantages and common gotchas

What is APCu?

APCu (Alternative PHP Cache, user cache) is a PHP extension that exposes a simple in-memory key/value store to your PHP code. Instead of hitting MySQL or an external API on every request, your application can do things like:

Internally, APCu stores this data in shared memory, so all PHP worker processes using the same handler can reuse it.

A few key points:

• APCu is not OPcache.
  OPcache caches compiled PHP bytecode. APCu caches arbitrary PHP values (“user data”) that you choose to store (arrays, strings, scalars, serialized objects, etc.).
• APCu is local to a PHP handler / server.
  It does not share data across multiple servers or across different PHP versions/handlers.
• Most modern frameworks support APCu.
  Drupal, Nextcloud, and others have optional APCu backends and often recommend at least ~32 MB of APCu memory for decent performance.

For a typical Plesk VPS with PHP-FPM, APCu is a good “first upgrade” beyond OPcache when the database is the bottleneck.

Installing APCu on a Plesk Obsidian server (Linux)

Plesk ships its own PHP builds under /opt/plesk/php/<version>. To add APCu, you usually:

1. Install Plesk PHP dev packages and build tools
2. Compile APCu with pecl for each PHP version you care about
3. Drop an apcu.ini file into the right place
4. Reload PHP handlers

1. Install prerequisites

On Debian/Ubuntu systems, you’ll typically install:

On CentOS / AlmaLinux / Rocky:

(Replace 82 with your real PHP version(s), e.g. 74, 81, etc.) These packages provide headers and tools needed to compile APCu against Plesk’s PHP.

2. Build APCu via PECL for each PHP version

For each PHP version that needs APCu, run:

This compiles and installs apcu.so into that PHP version’s module directory.

If the build finishes successfully, you should see something like:

3. Create apcu.ini for each version

Tell Plesk’s PHP to load the extension. For each version:

Adjust the version in the path as required. This mirrors common Plesk APCu installation guides.

4. Reread handlers and restart PHP-FPM

Finally, let Plesk know about the updated PHP configuration and restart the PHP services:

After this, you should see apcu listed under Tools & Settings → PHP Settings for the relevant PHP versions, and apcu should appear in the output of:

Enabling and configuring APCu per-domain in Plesk

Once the extension is available, you turn it on and tune it at the domain level.

Step 1: Confirm APCu is available for that PHP version

1. In Plesk, go to Tools & Settings → PHP Settings.
2. Click the PHP version/handler your site uses (e.g. 8.2 FPM served by Nginx).
3. Check that apcu is listed in the extensions.

If it’s there, APCu is ready for domains using that handler.

Step 2: Set APCu directives for a domain

For each domain that should use APCu:

1. Go to Domains → your-domain → PHP Settings.
2. Make sure the PHP version matches one where APCu is installed.
3. Scroll down to Additional configuration directives.
4. Add something like:

Click OK / Apply.

These kinds of settings (with slightly different numbers) are commonly used for apps like Nextcloud running on Plesk and provide a good baseline for busy PHP applications.

Key APCu tunable parameters (and sensible defaults)

The APCu runtime configuration exposes a handful of important directives. Here are the ones that matter most in a Plesk hosting environment.

apc.shm_size – cache size (most important)

There is one big decision to make configuring APCu: how much memory is going to be allocated. The ini directive that controls this is apc.shm_size.

This is the amount of shared memory reserved for APCu for that PHP handler.

Typical starting points:

• Small site / dev: 64M
• Medium single-site VPS: 128M – 256M
• High-traffic / multiple apps: 256M – 512M (if RAM allows)

If your status script shows a rising “Cache full count” and frequent evictions, your cache is too small or your TTLs are too generous.

Plesk note: Remember each PHP handler (e.g., 8.2 FPM) gets its own APCu memory. On a multi-tenant server, you may want more modest values per handler.

apc.ttl, apc.user_ttl, apc.gc_ttl – how long data sticks around

• apc.ttl – default expiry for entries that don’t specify a TTL in code. Old, unused entries are candidates for removal after this many seconds.
• apc.user_ttl – similar, but applied to user cache entries in some setups.
• apc.gc_ttl – how long “dead” entries may hang around before being removed by garbage collection.

Practical starting point for most apps:

If you see constant evictions even with a reasonably large apc.shm_size, try lowering apc.ttl/apc.user_ttl so stale data is pruned more aggressively.

apc.entries_hint – expected number of keys

This is a “hint” to help APCu size its internal data structures:

If you store lots of small items (for example, each user / permission / setting as its own cache entry), increase this value. The default scales with apc.shm_size, but setting it explicitly can fine-tune performance in large caches.

apc.enable_cli – APCu in CLI scripts

By default, APCu is disabled for CLI (apc.enable_cli=0). That’s usually fine—CLI scripts don’t share memory between invocations.

If you genuinely need APCu in long-running CLI workers (e.g., a custom daemon), you can enable it:

But don’t turn this on just for cron jobs; they’ll start with an empty cache each run and won’t share cache with web requests anyway.

apc.mmap_file_mask – how APCu allocates memory

On most Plesk Linux installs, the default is fine. MMAP-backed APCu generally uses a single memory segment and avoids some shared memory limits.

You rarely need to touch this unless you’re working around OS-specific shared memory constraints.

apc.slam_defense – protect against “cache slams”

On very busy servers, multiple processes may try to insert the same key at once, causing lock contention (“cache slams”). Setting:

introduces a small probability-based defense to reduce the impact. This can be useful for large codebases or heavy deployment cycles, but many small Plesk installs can leave it at the default.

Monitoring APCu with apc.php

APCu ships with a helpful status script, usually called apc.php. A common pattern is to copy it into your webroot and load it in a browser to inspect cache usage, hit rates, and “Cache full count” over time.

On a Plesk domain:

1. Locate apc.php on the server (often under the PECL source dir or documentation).
2. Copy it into the domain’s httpdocs/ directory.
3. Protect it:
   • Restrict by IP in Plesk, or
   • Put it behind HTTP auth

Do not leave this script publicly accessible—it exposes internal performance data and some environment details.

Disadvantages and potential problems

APCu is powerful, but it’s not a magic bullet. Here are the main caveats we see on Plesk servers.

1. Per-server, per-handler cache only

APCu lives inside each PHP handler on a single server:

• Different PHP versions (8.1 vs 8.2) get separate caches.
• Different servers in a cluster get separate caches.
• Requests on one host cannot see APCu data on another.

If you need a shared cache across multiple servers, look at Redis or Memcached instead.

2. Easy to undersize (or oversize) apc.shm_size

If apc.shm_size is too small, you’ll see:

• “Cache full count” increasing steadily in your status script
• Frequent evictions, negating the benefit of caching

If you set it too large on a small VPS, you risk starving the rest of your system (especially with multiple PHP versions and many domains).

Rule of thumb: start conservatively, watch metrics, and adjust gradually.

3. Not a replacement for good application caching design

APCu is fast, but:

• Caching giant blobs (huge arrays, full rendered pages for many variants, etc.) can fragment memory and blow your cache size quickly.
• Poor cache key design (never expiring, unbounded per-user keys) can fill the cache and cause thrashing.
• Long TTLs on rarely-used data can hog space that could be better used for frequently accessed items.

You still need a sane caching strategy at the app/framework level.

4. No built-in persistence

APCu is in-memory only:

• Restarting PHP-FPM or the server clears the cache.
• Deployments that restart PHP will cause a cold cache afterward.

For workloads that need persistence across restarts, Redis/Memcached (or database-backed caching) are better fits.

5. Compatibility & build issues

On Plesk, you may run into:

• Missing plesk-php*-dev / plesk-php*-devel packages, which must be installed before pecl install apcu works.
• Version mismatches between OS PHP (php-apcu package) and Plesk’s own PHP builds under /opt/plesk/php. You generally want APCu built against Plesk’s PHP, not the system PHP.

Once APCu is installed correctly and visible in Tools & Settings → PHP Settings, most of these issues go away.

Wrap-up

On a Plesk server hosting PHP-heavy apps, APCu is:

• Simple to deploy (once compiled for Plesk PHP)
• Easy to tune with a handful of directives
• Very effective at reducing repetitive database and API calls

The key things to get right are:

1. Install APCu against Plesk’s PHP versions via pecl and apcu.ini.
2. Enable and configure it per domain in PHP Settings → Additional configuration directives.
3. Size apc.shm_size sensibly and tune TTLs to match your workload.
4. Use apc.php (behind access controls) to watch hit ratios and cache fullness.
5. Remember APCu is a local cache—use Redis/Memcached when you need cross-server or persistent caching.

If you’d like help sizing or tuning APCu for your specific Plesk environment, Reliable Penguin can review your current usage and recommend settings based on your actual traffic and memory profile.