Admin

Suppressing Non-Critical Banners

Sometimes the LiteSpeed Cache plugin for WordPress adds informational banners to your WordPress Dashboard, such as this one:

!

These banners are meant to be informational, but they are not critical to the functioning of the plugin. As of LSCWP v3.0, these banners are opt-in only, meaning by default, such non-critical banners will not be displayed. If you would like to opt in to seeing LiteSpeed news (hotfixes, new releases, available beta versions, promotions, etc.) displayed on your dashboard, navigate to LiteSpeed Cache > General > General Settings and set Notifications to ON.

Note

This setting does not suppress notifications such as Purged all caches successfully. and other messages related to the functioning of the plugin.

Admin IP Commands

The following commands are available to the admin and do not require log-in, providing quick access to actions on the various pages:

  • NOCACHE - This is used to display a page without caching it. An example use case is to compare a cached version of a page with an uncached version.
  • PURGE - This is used to purge most cache tags associated with the page. The lone exception is the blog ID tag. Note that this means that pages with the same cache tag will be purged as well.
  • PURGESINGLE - This is used to purge the first cache tag associated with the page.
  • SHOWHEADERS - This is used to show all the cache headers associated with a page. This may be useful for debugging purposes.
  • before_optm - Use this parameter to view a page without any of the optimizations enabled.

To trigger the action for a page, access the page with the query string ?LSCWP_CTRL=ACTION.

Example: https://www.myblog.com/2017/todays-blog-post/?LSCWP_CTRL=PURGE

Note

Actions are case-sensitive.

WordPress CLI

This documentation has moved to it's own page. Please see WordPress CLI.

Using Multiple Optimization Plugins

LiteSpeed Cache for WordPress has many optimization features in addition to our signature full-page cache, and as such, you probably don't need any other similar plugins. If you still want to use one of the other WordPress optimization plugins for whatever reason, that shouldn't be a problem, as long as you don't try to use the same features in both.

For example, if you are using our full-page cache and our CDN support, then you will need to make sure that page cache and CDN support are disabled in whatever other plugin you use. Similarly, if you are using a minification function (for example) in another plugin, you will need to keep minification disabled in our plugin.

Duplicating functionality at best bogs down your server, and at worst breaks your site. So don't do it!

To learn more about this, see our blog.

Compatibility Check

Not all cache plugins are good candidates to pair with LiteSpeed. In order to avoid duplicating our functions, a plugin must either:

  1. not include the same cache and optimization functions as LiteSpeed Cache at all, or
  2. include cache and optimization functions that can be disabled one-by-one.

Set up Other Plugin

Before you install and activate LiteSpeed Cache, you should first get the other plugin working to your satisfaction. Doing this part first will make it easier because you can follow the plugin’s given directions without having to worry about how it will impact LiteSpeed’s setup.

Once the plugin is installed, activated, and set up to your liking, purge that plugin’s cache to ensure there are no conflicts from the start, and then disable the cache and all of the duplicate optimization functions that you plan to use in LSCWP.

Set up LSCWP

Install and activate LSCWP. Upon activation, you should see the following warning message:

!

This message indicates that there is another cache plugin activated and that it is using the WordPress advanced-cache.php file. This is normal behavior! If you see this warning, it means everything is working as expected.

If you don’t see the above message, we need to figure out why. Try refreshing your screen a few times. If it’s still not there after that, it can mean one of two things:

  • The other plugin you installed doesn’t use advanced-cache.php
  • There is an underlying issue that needs to be addressed

In either of these cases, it’s best to let us know. We’ll be able to tell you if this is normal for the other plugin you’re using, and if it’s not, we can troubleshoot the underlying issue.

Configure LSCWP

Assuming you’ve seen the message above, the last step is to configure LSCWP not to use advanced-cache.php. If the other plugin wants to use that file, we are going to let it do so. Navigate to LiteSpeed Cache > Cache > Advanced, and uncheck Check Advanced Cache.

Save your changes, and the warning should no longer display. If the message is still there, let us know.

Enable the cache and any optimization features you wish to use in LSCWP.

Verify

At this point, you should have both plugins working together in harmony, but you’ll want to do a quick test, just to be sure. To verify that your pages are actually being cached by LiteSpeed, you can follow these steps.

If the page was not cached by LiteSpeed, then something in your setup is not quite right. Contact us, if you need help!

If the page was cached by LiteSpeed, then the setup is finished. Don’t forget to take a look at your LiteSpeed Cache settings and see if anything needs adjustment. In general, the default settings are fine, but you might want to tweak a few things since you’ve got the other plugin running, too.

Translate LSCache for WordPress

LSCWP is written in United States English, and so we rely our our international users to help us translate the plugin for worldwide use. If you are fluent in a language other than English (US), and you have a few minutes to contribute to our plugin, we would appreciate it!

Is Your Language Needed?

!

We have a few languages very well covered, so you'll want to check the Translating WordPress page for LiteSpeed Cache and look for your language (and geographic location if applicable). If there are red or yellow boxes next to the language, then your expertise is needed.

As you can see, we have quite a few red boxes as of this writing (and several pages more of them past where the screenshot ends). The most important column is the "Stable" column. Languages with shades of red in the stable column have less than a third of the plugin translated.

Submit a Translation

All you need is a wordpress.org login. Once you are logged in, you can click the link and start translating at your own pace.

The instructions will be the same for whichever language and geographic location you choose, but for simplicity's sake, let's say you're from Spain and would like to contribute to the Spain Spanish translation.

Click Spanish (Spain) to be brought to the es_ES translation page.

!

The most important section to work on first is Stable (latest release), so click on that to see what strings are still missing translation.

!

You'll be brought to a list of strings and their current translations (if any).

This list, if it's not well-populated, may look overwhelming. However, it is not required for you to translate every single string. You could spend half an hour and do thirty of them. Or ten. Or even just one. Every contribution, even a small one, gets us closer to full translation.

When you see a string you'd like to translate (for example, Communicated with Cloudflare successfully), double click on the Translation column for that string, and enter your translation in the box.

!

Click the Suggest new translation -> button. Congratulations, you have successfully translated your first string.

Approval

All translations must be approved by an editor for your language before they are incorporated into the plugin.

If you would like to be a translation editor for LSCache, just keep translating! We will notice you, and apply to wordpress.org to give you editor access. Additionally, we'll add you to our Slack team, where you can communicate with our other editors, and be kept in the loop for new plugin updates and needed translations.

Thank you for helping us make LSCWP accessible for a global audience!

Enabling and Limiting the Crawler

These instructions apply to the WordPress LSCache crawler and other CMS LSCache crawlers where available.

Due to the potential of the crawler to consume considerable resources, we have put the on/off switch in the hands of the server administrators. In a control panel environment, such as cPanel, the crawler is disabled by default and can only be enabled by an admin through Apache configuration. In the LSWS Native environment, the crawler is enabled by default and can be disabled at the server level or virtual host level in LSWS v5.3.5 and above.

Warning

We do not recommend enabling the crawler for shared hosting setups unless the server has enough capacity to handle it!

Shared Hosting / Control Panel Environment

As of LSWS v5.1.16, there are four different approaches you can take to crawling on your server:

  • You can disable it for the entire server
  • You can disable it for the entire server, and selectively enable it for specific vHosts
  • You can enable it for the entire server
  • You can enable it for the entire server, and selectively disable it for specific vHosts

Enabling the Crawler

To enable the crawler in either of the second two scenarios, you need to add this “Crawler Snippet” to the appropriate configuration or include file:

    <IfModule Litespeed>
     CacheEngine on crawler
    </IfModule>

The exact location of the relevant configuration or include file varies, depending on the control panel you use (or if you use no control panel at all), and which of the above options you are looking to enact. See below for instructions relevant to your setup.

After you've added the Crawler Snippet in the appropriate location, you should gracefully restart the server.

Note

If you are on v5.1.16 and are having difficulty getting this to work, please force reinstall to the latest build.

Limiting the Crawler

Currently, the following variables are available for use with the Crawler function:

  • CRAWLER_USLEEP puts a minimum allowed value on the Delay field.
  • CRAWLER_LOAD_LIMIT sets a default for the Server Load Limit field.
  • CRAWLER_LOAD_LIMIT_ENFORCE sets a maximum allowed value on the Server Load Limit field.

To use these variables, add them one-per-line to the appropriate configuration file. For example:

    <IfModule LiteSpeed>
    CacheEngine on crawler
    SetEnv CRAWLER_USLEEP 1000
    SetEnv CRAWLER_LOAD_LIMIT 5.2
    </IfModule>

Disabling the Crawler

Starting from LSWS v5.3.5 or later, you may disable the crawler for an Apache virtual host, in any situation. Simply add CacheEngine -crawler to the Apache virtual host configuration, like so:

    <IfModule LiteSpeed>
    CacheEngine -crawler
    </IfModule>

cPanel/WHM

Server Level

Change your working directory to:

  • /usr/local/apache/conf/includes/ for EA3 or
  • /etc/apache2/conf.d/includes/ for EA4.

Add the Crawler Snippet and optional server variables to the pre_main_global.conf file.

Global Virtual Host Level

Change your working directory to:

  • /usr/local/apache/conf/userdata/for EA3 or
  • /etc/apache2/conf.d/userdata/ for EA4

If these directories do not exist, create them.

Add the Crawler Snippet and optional server variables to the lscache_vhosts.conf file.

Apply these changes to all Virtual Hosts by running the following command:

    /scripts/ensure_vhost_includes --all-users

Note

You only need to run this command once and it will activate for all users, including new users created by WHM later. There is no need to edit the cPanel skeleton file.

Individual Virtual Host Level

Change your working directory to:

  • For EA3: /usr/local/apache/conf/userdata/std/2_4/<user>/<domain>/
  • For EA4: /etc/apache2/conf.d/userdata/std/2_4/<user>/<domain>/

If your site supports HTTPS (SSL), please also change that working directory to:

  • For EA3: /usr/local/apache/conf/userdata/ssl/2_4/<user>/<domain>/
  • For EA4: /etc/apache2/conf.d/userdata/ssl/2_4/<user>/<domain>/

Note

The 2_4 in the path is an example. You can replace it with your appropriate version, such as 2 or 2_2.

If these directories do not exist, create them.

Add the Crawler Snippet and optional server variables to the lscache_vhosts.conf file. This will enable the crawler for this Virtual Host only.

Apply these changes by running the following command:

    /scripts/ensure_vhost_includes --user=$user

Plesk

Server Level

Change your working directory to:

  • /etc/httpd/conf.d/ for CentOS
  • /etc/apache2/conf.d/ for Debian
  • /etc/apache2/conf-enabled for Ubuntu

Add the Crawler Snippet and optional server variables to lscache.conf. If it doesn’t exist, create it.

Global Virtual Host Level

Change your working directory to /usr/local/psa/admin/conf/templates/custom/domain

Create it if it doesn’t exist.

Copy /usr/local/psa/admin/conf/templates/default/domain/domainVirtualHost.php to this location.

Edit the file and add the Crawler Snippet and optional server variables after the mod_suexec.c block.

Reconfigure all virtual hosts (this will regenerate new configuration files for all vhosts), like so::

    /usr/local/psa/admin/bin/httpdmng --reconfigure-all
Individual Virtual Host Level

Change your working directory to /var/www/vhosts/system/<domain_name>/conf/

Create a file called vhost.conf if it does not already exist ( or vhost_ssl.conf for HTTPS sites).

Add the Crawler Snippet and optional server variables to this file.

Reconfigure this Virtual Host (this will regenerate new configuration files for this vhost), like so:

    /usr/local/psa/admin/bin/httpdmng --reconfigure-domain <domain_name>

DirectAdmin

Server Level

Add the Crawler Snippet and optional server variables to the /etc/httpd/conf/extra/httpd-includes.conf file.

Global virtual host level

Create a /usr/local/directadmin/data/templates/custom/cust_httpd.CUSTOM.2.pre file and add the Crawler Snippet and optional server variables to it.

Apply these changes to all Virtual Hosts by running the following commands:

    cd /usr/local/directadmin/custombuild
    ./build rewrite_confs

LiteSpeed Native

The cache crawler is enabled by default in a LSWS Native environment.

To disable it at the Server Level, you will need to use LSWS 5.4 and above. There was a Cache Features function added to control this.

In the LSWS WebAdmin interface, navigate to LSWS Admin > Configuration > Server > Cache. In Cache Features, check On, uncheck Crawler, check ESI, and uncheck Not Set.

If Not Set is checked, the other three values will be ignored and the default values will be used. (By default, all three are checked.)

!

To disable the cache crawler at the LSWS Native Virtual Host level, navigate to LSWS Admin > Configuration > Virtual Host > VH Name > Cache >, and set Cache Features in the same manner as above. If Not Set is checked, the other three values will be ignored and the server-level configuration will be inherited.

Warning

Do not set Enable LiteMage to On, as this setting will also enable the crawler, even if Crawler is unchecked.

!

To add any of the optional server variables, navigate to Server > External App and add the variable(s) to the Environment setting, one per line. For example:

    CRAWLER_USLEEP=1000
    CRAWLER_LOAD_LIMIT=5.2

!

Testing

The LiteSpeed Web Server cache engine will set environment varibles for X-LSCACHE. You can always check Environment Variables through the phpinfo page to see if the crawler is on or not. If the crawler is not there, then it has been disabled successfully. LSWS can only disable the LiteSpeed Cache plugin or LiteSpeed crawler since such LiteSpeed crawlers will check X_LSCACHE environment variable. LSWS can not stop any third party crawler from working since they don't check X_LSCACHE to act accordingly.

    $_SERVER['X-LSCACHE'] on,esi

!

In the LiteSpeed cache for WordPress plugin, under Crawler > Summary, it should show Crawler Cron set to Disable, and

    Warning: The crawler feature is not enabled on the LiteSpeed server. Please consult your server admin.

Setting Up CloudFront CDN

Create CDN with CloudFront

!

  1. Set up AWS CloudFront CDN
  2. Get your CloudFront Domain Name
  3. Make sure your site can be visited directly through the CloudFront Domain Name

Set Up in LSCache Plugin

  1. From the WP Dashboard, navigate to LiteSpeed Cache > CDN > CDN Settings.
  2. Set Use CDN Mapping to ON
  3. Enter CDN URL as your CloudFront Domain Name
  4. Enable the relevant Include buttons. e.g. Images and CSS. For this example, if we don't Include JS, then we also need to remove .js from Include File Types
  5. Set up Original URL as your original domain name (and sub-folder if you are using one)

Verify

Check that the CSS is served from CloudFront

!

Check that the JS is served from the original domain

!

Turning WordPress Shortcodes into ESI Blocks

You can turn WordPress shortcodes into ESI blocks with LiteSpeed Cache. This allows you to cache the contents of the shortcode in a different way than you've cached the rest of the page. (You can learn more about ESI on our blog, if this concept is new to you.)

If you have a mycalendar shortcode, for example, and it inserts a calendar into your page, you might use it like this:

    [mycalendar month="November" year="2018"]
To turn it into an ESI block, you would instead use it like this:
    [esi mycalendar month="November" year="2018"]
By default, shortcode contents are stored in public cache, and the TTL defaults to whatever value you have stored in LiteSpeed Cache > Cache > TTL > Default Public Cache TTL, but you can change that with a few parameters. To store the shortcode contents in private cache for five minutes (or 300 seconds), you can say this:

    [esi mycalendar month="November" year="2018" cache="private" ttl="300"]

Limitations

While LiteSpeed Cache can easily cache your shortcode contents, it is not possible for LSCache to purge the shortcode contents on demand. Shortcode ESI blocks can naturally expire when the TTL is reached, but a purge cannot be triggered by particular events. This makes sense, because LiteSpeed can't know which occurences should trigger a purge. Different shortcodes all have different events that render them out-of-date, and there's no way for LiteSpeed to know what they are.

Using the example of the calendar plugin above, let's say you use the following shortcode:

    [esi mycalendar month="November" year="2018"]
This will cache the mycalendar block for the same length of time as your site's default TTL. If someone edits an event before the TTL is reached, then the ESI block will, unfortunately, be out-of-date.

There are two ways to handle this issue:

  • Have the shortcode's plugin author use our API to trigger a purge when block content changes.
  • Use a short TTL, and live with the possiblity that contents may be out-of-date for a short time.

Get the Plugin Author Involved

If it's important that the shortcode contents be purged by specific events, you can share this API call with the author of the shortcode's plugin (just be sure to replace mycalendar with the actual name of the shortcode you want to purge:

do_action( 'litespeed_purge', 'esi.mycalendar' ) ;

This is the most precise way to keep the content in the shortcode up-to-date and accurately cached according to the shortcode's own requirements.

Do it Yourself

If it is not critical for the contents of the shortcode to have up-to-the-minute accuracy, then you can use the ttl parameter to cache the content for a short time. If you can live with content that is an hour old, set ttl="3600". If you are thinking more along the lines of five minutes, set it to ttl="300".

While it is possible to set the content to not be cached at all ( ttl="0"), it is not recommended. Any time there is uncached content on a page, PHP must be invoked in order to generate that content. PHP uses valuable resources, and significantly slows down a page. It's far better to cache your content for a small amount of time than to set it not to be cached at all.

Cookies and Cache

The relationship between cookies and caching can be easily misunderstood. When you talk about "caching cookies" or "not caching cookies," it's not the cookies themselves that are being cached or not cached. It's the pages of the site that are being cached or not cached based on whether a user has those cookies stored.

Cookies, generally, are ignored unless you specify otherwise. Cookies become important when they impact the user experience in some way.

Cookies Set or Read by WordPress

If a cookie must be set or read by WordPress, then it has to be excluded from cache. And, if the cookies are set on your site (i.e. they are not set somewhere before arriving at your site), then you will also have to exclude the page that sets the cookie's value.

Example

Let's say your site is part of an affiliate network. When a user arrives at example.com/afilliate_home an aff-example cookie is set. As they navigate the site, the cookie is updated with tracking information.

In this case, the cookie aff-example must be added to the Do Not Cache Cookies list in LiteSpeed Cache > Cache > Excludes, and ^/afilliate_home must be added to Do Not Cache URIs list on the same page. (For more on the Excludes page, see the screen-by-screen documentation.)

If, in this example, the cookie was set at example.com/afilliate_home, but then never referenced again, you would not have to exclude the cookie from cache.

Alternately, if the cookie was set offsite somewhere, but was used for tracking as the visitor wandered around your site, then you would have to exclude the cookie from cache, but you wouldn't have to exclude the ^/afilliate_home URI.

Cookies That Indicate Variations

Sometimes cookies can be used to indicate important information about the user to WordPress, to help determine what content should be shown to the user. In these cases, you can use the cookies to create cache varies. When LSCache varies on a cookie, it caches separate public versions of the pages of the site, based on the value of the cookie.

Example

Let's say your WP site is a shop, and you have special pricing for your friends that is activated when they visit example.com/friends_home. That page sets a myfriend cookie, and from that point on, every page they visit in your shop shows pricing that is 20% less than normal. When a visitor without the myfriend cookie looks at the pages in your shop, they see regular prices.

Because the cookie is set on the example.com/friends_home page, that URI will need to be excluded from cache as described above.

There are two ways to deal with the cookie itself:

  • You could do as the previous example, and exclude it from cache. That's the easiest way, but it means your friends will always have uncached content, and that's not an ideal experience for them.
  • You could create a cache vary based on the myfriend cookie.

Example

Assume you have a WooCommerce site with a "woocommerce_products_per_page" cookie. For some users, the value will be 10. For others it will be 100. And still others may have a value of 200. These three scenarios require three different views.

There are two ways to handle different views based on a cookie value:

JavaScript

The more efficient option is to find a JavaScript-based solution. A JavaScript plugin would only need to store one copy of the page and would build the display based on the existence of the cookie.

Rewrite Rules

If a rewrite rule-based answer is preferred, the site can be configured to vary on the cookie by adding the following rule to your site's .htaccess file:

<IfModule LiteSpeed>
CacheLookup on
RewriteRule .* - [E=Cache-Vary:woocommerce_products_per_page]
</IfModule>

When a user visits your WooCommerce site, the woocommerce_products_per_page=xxxxxxcookie will be created. Using the rewrite rule above, the cache will vary on that cookie. This means the cache will store multiple copies: one for every value of the cookie that requests the page.

Warning

woocommerce_products_per_page is an example. Be sure to substitute the appropriate cookie name.

Further Reading

You can learn more about cookies and cache varies in our Developer's Guide to Cache Vary.

Memcached, LSMCD and Redis (Object Cache) Support in LSCWP

As of version 1.8, LiteSpeed Cache for WordPress supports Object Cache.

What is an Object Cache?

An object cache stores the results of expensive and/or frequent database queries in a way that makes them easy to retrieve, and eliminates the need for repeated access to the database. Object caching greatly reduces the time it takes to retrieve query results.

For example, your WordPress site's options are stored in the database. Site options include things like the site's name and URL. Every time a page is assembled for a visitor, it is necessary to access the database to read the site options. As you can imagine, these repeated queries for the same information represent wasted resources. With an object cache, you can query the database once, and save the results for a set period of time. During that time, whenever a page must be assembled, WordPress can get the site information from the cache. Accessing object cache is a much less resource-intensive prospect than accessing a database.

Some queries are time-consuming, and other queries are repeated frequently. Both of these scenarios can be improved by storing the query results in object cache.

Note

If you have a site that is fully-cached by LSCWP, you won't use object cache very often. Object cache is only necessary when WordPress is building a page through PHP. If PHP is not being invoked (and minimizing PHP usage is the goal with LSCache) then there are no queries to process and therefore nothing to look up in object cache.

How to set up Object Cache Support

LSCWP doesn't provide object caching directly. Rather, it supports your use of an external object cache such as Memcached or LiteSpeed's drop-in Memcached replacement, LSMCD.

Install Memcached, LSCMD or Redis and PHP Extension

You will need a working and fully tested installation of Redis, Memcached, or LSMCD, as well as the related PHP extension (i.e. php-memcached or php-redis) in order to make your object cache work properly with WordPress.

Installation of the above software is outside of the scope of this document, but we have other wikis that may help:

Config Object Cache in LSCWP

If you are using LSMCD, Memcached or Redis, you can set up LSCWP support in the Cache Settings tab. Navigate to LiteSpeed Cache > Cache > Object. You will need to give LSCWP some parameters, including where your Memcached or LSMCD lives, which objects you'd like to have cached, and how long you want objects to remain in cache, among other things.

Before enabling Object Cache, the default values with already be filled in for you.

After enabling Object Cache, the LSCache plugin will automatically run both connection testing and Memcached/Redis extension detection.

Detailed instructions for all of these settings can be found here.

How to Verify

There are not too many methods to check the Object Cache log, but if you set LiteSpeed Cache > Toolbox > Debug Settings > Debug Log to ON or Admin IP, and view your page source code, you should see something like this at the bottom of the code:

    <!-- Object Cache [total] 5190 [hit_incall] 5056 [hit] 6 [miss_incall] 21 [miss] 107 [set] 171 ->

  • total is the total number of objects the page requested.
  • hit_incall is the number of objects that did not hit Memcached but hit the runtime data from above.
  • hit is the number of objects retrieved from Memcached.
  • miss_incall is the number of objects not set in runtime. That is to say, when php ran into the current line, no data was set before.
  • miss is the number of objects not found in Memcached.
  • set is the number of objects set in Memcached.

How to Debug

If your Connection Test shows Failed, there are a few things you can try.

  1. Try service memcached status, to make sure the service is active (running).
  2. Try ss -lptun | grep 11211, to make sure the Memcached port is listening.
  3. Try telnet localhost 11211, to make sure you can connect to localhost successfully.

Test files

You can create test PHP files to test connection

For Memcached:

    <?php

    $conn = new Memcached ;
    $address = '/path/to/memcached.sock' ; // set the address here
    $port = 0 ; // set the port
    $conn>addServer( $address, $port ) ;
    var_dump( $address ) ;
    var_dump( $port ) ;
    var_dump( $conn>getStats() ) ;
    echo '<hr>';
    var_dump($conn>getServerList());
    ?>
For redis:
    <?php

    $cfg_host = 'redis address' ;
    $cfg_port = '6379' ; // or 0 if use socket
    $cfg_pswd = '' ; // Set if has
    $cfg_db = 0 ;


    $conn = new Redis() ;
    $conn>connect( $cfg_host, $cfg_port ) ;
    if ( $cfg_pswd ) $conn>auth( $cfg_pswd ) ;
    if ( $cfg_db ) $conn>select( $cfg_db ) ;

    var_dump( $conn>ping() ) ; // Should give a `+PONG`
    ?>

Using Memcached in a UNIX socket

Memcached can run in a UNIX socket, which provides better performance than a TCP connection.

Note

If Memcached fails to start, it is usually due to permission and user problems. Please use root privilege to execute the following instructions, and verify that the socket path is writable to the designated user.

Centos7.X

  1. Stop Memcached systemctl stop memcached
  2. Copy the service file cp /usr/lib/systemd/system/memcached.service /etc/systemd/system/memcached.service
  3. Add the following content to /etc/systemd/system/memcached.service. After [Service], please change username to the same user that runs PHP: User=username Group=username The contents of the file should look like this:
    !
  4. Edit /etc/sysconfig/memcached, changing the path to your desired location, and the username to the same one used in Step 3: OPTIONS="" USER="memcached" becomes OPTIONS="-s /path/to/memcached.sock -a 0770" USER="username"
  5. Start Memcached again: systemctl start memcached
  6. Verify it started successfully: systemctl status memcached
  7. Check if everything is working well: nc -U /path/to/memcached.sock stats
  8. If there is still a permission issue, please check selinux status: getenforce
  9. Disable selinux if status shows Enforcing: setenforce 0 (reboot will re-enable selinux)
  10. To permanently disable selinux, edit /etc/selinux/config, change enforcing to permissiveordisabled and then reboot.

Centos6.X

  1. Stop Memcached systemctl stop memcached
  2. Edit /etc/sysconfig/memcached and change OPTIONS="" USER="" to OPTIONS="-s /path/to/memcached.sock -a 0770" USER="username" where USER is the same user that runs PHP.
  3. Start Memcached service memcached start
  4. Check if everything is working well: nc -U /path/to/memcached.sock stats
  5. If there is still a permission issue, please check selinux status: getenforce
  6. Disable selinux if status shows Enforcing: setenforce 0 (reboot will re-enable selinux)
  7. To permanently disable selinux, edit /etc/selinux/config, change enforcing to permissiveordisabled and then reboot.

Ubuntu 17.10, Ubuntu 16.04, Debian 8 and Debian 9

  1. Stop Memcached systemctl stop memcached
  2. Edit /etc/memcached.conf, comment out host and port, add socket path and permission -s /path/to/memcached.sock -a 0770 and change -u memcache to -u username where username is the same user that runs PHP.
  3. Start Memcached again systemctl start memcached
  4. Check if everything is working well: nc -U /path/to/memcached.sock stats

Ubuntu 14.04 and Debian 7

  1. Stop Memcached service memcached stop
  2. Edit /etc/memcached.conf, comment out host and port, add socket path and permission -s /path/to/memcached.sock -a 0770 and change -u memcache to -u username where username is the same user that runs PHP.
  3. Start Memcached again service memcached start
  4. Check if everything is working well: nc -U /path/to/memcached.sock stats

Using Redis in a UNIX Socket

Please use root privilege to execute the following instructions. If Redis fails to start, please verify SELinux is disabled , and all mentioned directories and files have correct permissions to the designated user.

Centos 7.X

  1. Stop Redis. systemctl stop redis
  2. Copy the service file. cp /usr/lib/systemd/system/redis.service /etc/systemd/system/redis.service
  3. Edit /etc/systemd/system/redis.service. User=username Group=username Change username to same user that runs PHP.
  4. Edit /etc/redis.conf and change the following (Change port to 0 if TCP socket is no longer needed):
        unixsocket /path/to/redis.sock
        unixsocketperm 770
        logfile /path/to/redis.log
        dir /path/to/redis
    
  5. Change owner of redis.conf to same username in step 3. chown username:group /etc/redis.conf If /path/to/redis directory does not exist, please manually create it, and make sure above mentioned socket path, log pathand dir path and are writable by the designated user.
  6. Start Redis. systemctl start redis
  7. Verify it started successfully. systemctl status redis
  8. Check whether everything is working well. nc -U /path/to/redis.sock info

Last update: May 1, 2020