• Resolved ram108

    (@ram108)


    Has anything changed in the latest plugin update? May be cache file names? Before that, everything worked fine.

    Now I see these files in cache dir:
    /cache-enabler/domain.com/https-index.html

    But documentation say:
    set $cache_enabler_uri '${custom_subdir}/wp-content/cache/cache-enabler/${http_host}${cache_uri}index.html';

    Source: https://www.keycdn.com/support/wordpress-cache-enabler-plugin

    With new filenames they will never be served with nginx.

    • This topic was modified 4 years, 1 month ago by ram108.
    • This topic was modified 4 years, 1 month ago by ram108.
Viewing 15 replies - 1 through 15 (of 23 total)
  • Anonymous User 16850768

    (@anonymized-16850768)

    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).

    Thread Starter ram108

    (@ram108)

    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.

    Anonymous User 16850768

    (@anonymized-16850768)

    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.

    Thread Starter ram108

    (@ram108)

    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.

    Thread Starter ram108

    (@ram108)

    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%.

    Anonymous User 16850768

    (@anonymized-16850768)

    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.

    Thread Starter ram108

    (@ram108)

    @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, 1 month ago by ram108.

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

    Thread Starter ram108

    (@ram108)

    @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?

    Anonymous User 16850768

    (@anonymized-16850768)

    @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?

    Anonymous User 16850768

    (@anonymized-16850768)

    @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
    Thread Starter ram108

    (@ram108)

    @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.

Viewing 15 replies - 1 through 15 (of 23 total)
  • The topic ‘Wrong nginx recommendations in docs’ is closed to new replies.