Set up LSMCD as a WordPress object cache on cPanel

If you already run LiteSpeed Enterprise on cPanel, you have a faster object cache option than either standalone memcached or Redis: LSMCD, LiteSpeed's own caching daemon. It speaks both the memcached and Redis protocols on the same port, persists to disk between restarts, supports SASL auth out of the box, and shares process accounting with LSWS so a runaway PHP-FPM worker can't starve it.

This guide installs LSMCD on a cPanel server, locks it down with SASL, enables the memcached PHP extension for every selectable PHP version, and wires the LiteSpeed Cache for WordPress plugin to use LSMCD as both an object cache and an ESI block cache backend. Plan on 30-40 minutes end-to-end on an idle box.

When LSMCD beats Redis on a LiteSpeed server

The honest answer: on a pure WordPress object cache workload, Redis and LSMCD perform within 5% of each other. LSMCD's edge shows up in three places specific to the LiteSpeed stack:

• ESI block cache integration. LSCache stores per-user ESI fragments (cart widgets, "Hi, $username" greetings) directly in LSMCD without going through PHP. With Redis you need the LSCache plugin to round-trip through phpredis, which costs roughly 80-150µs per fragment.
• Single daemon for two protocols. LSMCD answers memcached and Redis traffic on the same listener. That matters when one plugin on the account hard-codes a memcached client and another expects Redis — both work without running two services.
• SASL is on by default. Redis needs requirepass plus ACLs to approximate the same isolation, and historically many hosts ship Redis unauthenticated on 127.0.0.1 and trust the firewall. LSMCD ships with SASL ready.

If you're not running LiteSpeed Enterprise, stop reading and use Redis as the WordPress object cache instead — there's no benefit to LSMCD over Redis without LSCache.

Prerequisites

• cPanel/WHM with LiteSpeed Enterprise installed and licensed. If LSWS isn't on the box yet, run through installing LiteSpeed on cPanel first.
• CloudLinux 8 or 9, AlmaLinux 8 or 9, or Rocky 9. The packaging is the same; only the EPEL dependency name shifts.
• LiteSpeed Cache for WordPress plugin (v6.0 or later) on the WordPress sites that will use it.
• Root SSH. CageFS-protected accounts need an extra mount line — covered in step 3.

Step 1 — Install LSMCD

LiteSpeed publishes LSMCD as a standalone package via their repo. The repo is already configured if LSWS is installed; if not, add it:

rpm -ivh https://repl.litespeedtech.com/centos/litespeed-repo-1.2-1.el8.noarch.rpm

Install LSMCD:

yum install lsmcd

The package installs to /usr/local/lsmcd/, drops a systemd unit at /etc/systemd/system/lsmcd.service, and stages a default config at /usr/local/lsmcd/conf/node.conf. Don't start it yet — the default config binds to 0.0.0.0:11211 with no auth, which is the same footgun Redis gives you.

Step 2 — Configure the daemon

Edit /usr/local/lsmcd/conf/node.conf. The defaults to change:

CAS                       yes
USER                      nobody
GROUP                     nobody

[General]
LogFile         /usr/local/lsmcd/logs/lsmcd.log
LogLevel        INFO
PidFile         /tmp/lsmcd.pid
SliceId         0

[!AnonymousAccess]
[CACHE]
CacheFile        /usr/local/lsmcd/cachedata/cache.data
MemMaxSz         512M
MemAllSz         3072M
KeyMaxLen        255
ValMaxSz         1M

[SOCKET 127.0.0.1:11211]

Key changes from the shipped defaults:

• MemMaxSz is the in-RAM cache size; size it to 5-10% of total RAM on a hosting box.
• MemAllSz is the disk-backed mapped size — what survives restart. 3-6× MemMaxSz is a good ratio.
• [!AnonymousAccess] (the leading ! enables the section's flag) blocks unauthenticated clients. SASL credentials come in step 3.
• The SOCKET line binds to localhost only. Don't expose LSMCD to a public interface — there's no TLS support yet.

Create the cache data directory and fix ownership:

mkdir -p /usr/local/lsmcd/cachedata
chown nobody:nobody /usr/local/lsmcd/cachedata /usr/local/lsmcd/logs

Step 3 — Enable SASL authentication

LSMCD reads SASL credentials from the system saslpasswd2 database. Install the SASL tooling if it isn't already present:

yum install cyrus-sasl cyrus-sasl-plain

Create the SASL config file LSMCD looks for. The path is hard-coded to /etc/sasl2/lsmcd.conf:

cat > /etc/sasl2/lsmcd.conf <<'EOF'
mech_list: plain
sasldb_path: /etc/sasl2/lsmcd-sasldb2
log_level: 5
EOF

Add a user — one per server is enough; per-account isolation happens via key prefixes in the WordPress plugin, not separate SASL accounts:

saslpasswd2 -c -f /etc/sasl2/lsmcd-sasldb2 -a lsmcd wp_objcache

You'll be prompted for a password twice. Pick something random and 32+ chars; you'll paste it into wp-config.php later.

Lock down the SASL DB so only LSMCD can read it:

chown nobody:nobody /etc/sasl2/lsmcd-sasldb2
chmod 600 /etc/sasl2/lsmcd-sasldb2

Start and enable LSMCD:

systemctl enable --now lsmcd
systemctl status lsmcd

A clean start logs LSMCD started ok to /usr/local/lsmcd/logs/lsmcd.log. If the process keeps respawning, 90% of the time it's a permissions problem on cachedata or the SASL DB — both must be readable by nobody.

Step 4 — Enable the memcached PHP extension

The LiteSpeed Cache plugin talks to LSMCD over the memcached protocol via the memcached PHP extension (note the trailing d — memcache without the d is the older, unmaintained extension and won't do SASL).

If you run CloudLinux PHP Selector, enable memcached for every selectable version. The fastest path is the WHM batch enable:

cloudlinux-selector enable --json --interpreter=php --extension=memcached --version=8.1
cloudlinux-selector enable --json --interpreter=php --extension=memcached --version=8.2
cloudlinux-selector enable --json --interpreter=php --extension=memcached --version=8.3
cloudlinux-selector enable --json --interpreter=php --extension=memcached --version=8.4

If you're on stock EasyApache 4 PHP without CloudLinux, install it per version:

yum install ea-php83-php-pecl-memcached ea-php84-php-pecl-memcached

Restart LSWS to pick up the new modules:

/usr/local/lsws/bin/lswsctrl restart

Verify the extension is loaded for a real account by running, as that user:

php -m | grep memcached

You want memcached (with the d) in the output. If cloudlinux-selector lists it as enabled but php -m doesn't show it, the account is pinned to a PHP version where you didn't enable it — fix from cPanel → Select PHP Version.

Step 5 — Wire WordPress to LSMCD via LSCache

Open WordPress admin on a site, then LiteSpeed Cache → Cache → Object. Set:

• Object Cache: ON
• Method: Memcached
• Host: 127.0.0.1
• Port: 11211
• Default Object Lifetime: 360 (seconds)
• Username: wp_objcache
• Password: the password you set with saslpasswd2
• Global Groups: leave defaults — users, userlogins, useremail, site-transient, etc.
• Do Not Cache Groups: leave defaults — comment, counts

Click Test Connection. A green "Connection Test Passed" confirms the PHP extension, the daemon, and SASL all line up. If it fails, the plugin error message is usually the truth — Connection refused means the daemon isn't running, AUTHENTICATION_ERROR means SASL credentials are wrong or CageFS is hiding /etc/sasl2.

Hit Save Changes and LSCache starts populating the object cache on the next request.

Optional: enable ESI block caching

If the site uses logged-in user widgets (WooCommerce carts, BuddyPress "Hi $username", logged-in nav menus), turn on LSCache → Cache → ESI and set the same LSMCD endpoint under ESI Settings → ESI Cache. ESI blocks land in LSMCD via LSWS itself rather than the PHP plugin — that's where the 80-150µs per-fragment saving comes from versus Redis.

Step 6 — Verify it's actually caching

The fastest sanity check is from wp inside a site's account:

wp eval 'wp_cache_set("lsmcd_test", "yes"); var_dump(wp_cache_get("lsmcd_test"));' --path=/home/user/public_html

You should see string(3) "yes". Then check LSMCD has it:

echo -e "stats\nquit" | nc 127.0.0.1 11211 | grep -E "curr_items|cmd_set|cmd_get"

curr_items should be > 0 and cmd_get / cmd_set should climb as the site takes traffic. If curr_items is always 0, WordPress is thinking it's writing to the cache but actually falling back to its in-memory PHP array — usually because the LSCache object cache toggle isn't saved, or the object-cache.php drop-in didn't get installed in wp-content/. The plugin auto-installs the drop-in when you save the Object panel; check wp-content/object-cache.php exists and is owned by the site user.

Common failure modes

LSMCD restarts in a loop, log shows failed to bind shared memory. The MemAllSz requested more virtual address space than the kernel allows for nobody. On a server with low vm.max_map_count, drop MemAllSz to 1024M or raise the sysctl: sysctl -w vm.max_map_count=262144.

WordPress admin loads but front-end is full of "could not connect to memcached". PHP is hitting LSMCD with no SASL credentials. Confirm the password in wp-config.php matches saslpasswd2, and that the memcached PHP extension was compiled with SASL support — php -i | grep -i sasl should print memcached support => enabled and sasl support => yes.

Cache works but eviction is happening every few minutes. MemMaxSz is too small. LSMCD's stats output (echo stats | nc 127.0.0.1 11211 | grep evictions) shows the eviction counter — if it grows steadily, double MemMaxSz and reload.

Two accounts on the same server see each other's cached options. WordPress object cache keys are prefixed by site URL, not username, and LSMCD has no concept of namespaces. This is fine for most hosts because the URL prefix already isolates the data, but if you need cryptographic isolation, give each account its own LSMCD instance on a separate port or use Redis with ACLs instead.

Tuning for resource-constrained boxes

LSMCD's memory is allocated from a single shared pool, not per-connection. On a 4 GB VPS, MemMaxSz 256M plus MemAllSz 1024M is comfortable. Stay under 15% of total RAM for MemMaxSz — going higher starts to compete with MySQL's innodb_buffer_pool_size and PHP-FPM worker memory, and you'll see swap before you see better cache hit rates.

For a host packing 100+ WordPress sites on a 32 GB box, MemMaxSz 3G / MemAllSz 12G gives roughly 30 MB of working-set per site at full saturation — enough headroom that the global LRU stays effective. Watch LVE statistics for any account whose entry-process count spikes after enabling object cache; a misbehaving plugin can hammer LSMCD with cache writes and the symptom shows up as LVE faults, not LSMCD errors.

Next steps

• If you haven't yet, turn on LSCache for WordPress — LSMCD as an object cache compounds with LSCache page caching rather than replacing it.
• Pair LSMCD with the LSCache crawler for warmup so first-visitor TTFB stays low after cache flushes.
• Activate or renew a LiteSpeed Enterprise license for the server if you're still on the trial.