Wrong nginx recommendations in docs

Yes, scheme-based caching was added (PR #94) so the file names have changed. Please check the note on the documentation:

Note: The following documentation is for versions 1.3.5 and below. As a result it may be out of date. The documentation is being updated for version 1.4.0 and will be released shortly.

In your case a temporary fix would be adding the scheme to the snippet (e.g. https-index.html).

Yes, I know how to fix the issue. But everyone how used to serve cache with Apache or Nginx will not be able to do that with new update without any notice.

I saw the problem due to the greatly increased load on my server.

Such changes must be announced in a conspicuous place with a recommendation on how to correct the situation.

The advanced configuration snippet is not required and in many cases not used. Due to certain events the release of version 1.4.0 was pushed up by about two weeks, which led to a few cuts being made.

I do agree that this specific change could have been handled better. We’ll make sure to keep this in mind going forward.

Anyway, thanks a lot for your plugin. This is the best and simplest cache plugin in the WordPress repository.

The plugin serves hundreds of sites and makes their work possible even on small server resources.

The advanced configuration snippet is not required and in many cases not used.

It is used and required, belive me.

With nginx serving pages, I have zero CPU load. But with the return through php (wordpress), the load increases to 30-50%.

You’re welcome, we’re really happy to hear that. Over the last few weeks I’ve been able to personally refactor the plugin and make many improvements. Keeping the plugin simple is one of our main focuses. If you’re able and haven’t already a review is always appreciated.

You’re right, the advanced configuration is used and is quite important. I was just stating that majority of users don’t use it. That doesn’t mean I think it’s less important, though.

Updates to the documentation will follow shortly.

@coreyk

See this graph: https://ibb.co/swFrcRS

On the left side is the CPU load when nginx stopped processing requests as a result of changing the names of the cache files.

On the right is when I re-enabled nginx processing.

Therefore, using direct file serving with nginx or apache is very important for performance.

• This reply was modified 4 years, 3 months ago by ram108.

I’m a little confused. do i have to modify the apache snippet if i use version 1.4.x?

@mobiflip yes, due to plugin cache filenames change, default apache and nginx snippets doesn’t work anymore.

This is very bad. The server load is higher as a result. How can it be fixed?

@ram108 thank you for sharing that great visual representation of the difference when using your server instead. Out of curiosity, was that comparing the difference between PHP (X-Cache-Handler: php) or the advanced cache (X-Cache-Handler: wp)? I believe it was PHP because there was a small bug in the advanced cache in version 1.4.0 that led to PHP always delivering the pages (fixed in version 1.4.2). In terms of performance, from the fastest to slowest, it would be the advanced configuration, advanced cache, and then PHP.

@mobiflip the Cache Enabler has been refactored and greatly improved in version 1.4+. If you’re encountering an issue with your advanced configuration simply update the snippet used to use the scheme that your website uses (as shown in the example above). Alternatively rely on the WordPress advanced cache (X-Cache-Handler: wp) until the documentation is updated.

Thanks. I don’t know exactly where to make this adjustment?

@mobiflip did you add the advanced configuration to your server configuration file (e.g. .htaccess or nginx.conf)? If yes, you would update the snippet you previously added in that file.

I have added the following code. I’m not sure where the change will affect.

# BEGIN Cache Enabler
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

# set blog sub path
SetEnvIf Request_URI "^(.*)$" SUB_PATH=/wp-content/cache/cache-enabler/

# set Cache Enabler path
SetEnvIf Request_URI "^(.*)$" CE_PATH=$1
SetEnvIf Request_URI "^(/)index.php$" CE_PATH=$1

<IfModule mod_mime.c>
# gzip HTML file
RewriteCond %{ENV:CE_PATH} /$
RewriteCond %{ENV:CE_PATH} !^/wp-admin/.*
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} =""
RewriteCond %{HTTP_COOKIE} !(wp-postpass|wordpress_logged_in|comment_author)_
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}%{ENV:SUB_PATH}%{HTTP_HOST}%{ENV:CE_PATH}index.html.gz -f
RewriteRule ^(.*) %{ENV:SUB_PATH}%{HTTP_HOST}%{ENV:CE_PATH}index.html.gz [L]

AddType text/html .gz
AddEncoding gzip .gz
</IfModule>

# default HTML file
RewriteCond %{ENV:CE_PATH} /$
RewriteCond %{ENV:CE_PATH} !^/wp-admin/.*
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} =""
RewriteCond %{HTTP_COOKIE} !(wp-postpass|wordpress_logged_in|comment_author)_
RewriteCond %{DOCUMENT_ROOT}%{ENV:SUB_PATH}%{HTTP_HOST}%{ENV:CE_PATH}index.html -f
RewriteRule ^(.*) %{ENV:SUB_PATH}%{HTTP_HOST}%{ENV:CE_PATH}index.html [L]

# wp override
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [END]
</IfModule>
# END Cache Enabler

@coreyk

was that comparing the difference between

Now I can’t say exactly what the handler was. But I noticed an unusually high load on the server, looked at the process list and found a lot of php-fpm processes creating the CPU load. After examining the problem, I saw that nginx does not serve files directly and uses the php interpreter instead.

Thus, it was found that the names of the cache files have changed.