• First, thanks Frank for such a great and comprehensive plugin.

    I am using W3TC 0.9.2.11 with Woocommerce and some other standard plugins hosted on nginx + php-fpm.

    I’ve boiled the problem down to the disk_enhanced page caching (all other w3tc caching steps are turned off to isolate the issue). Concisely:

    ++ the caching module properly produces the _index.html and _index_ssl.html files on the first request to a given url and then nginx is able to subsequently serve these using nginx rules (thereby bypassing wp+php altogether). This behavior can be reproduced and tested using curl. These files are properly stored in the cache/page_enhanced/<site>/<uri>/ directories.

    — the problem is when “Accept-encoding: gzip” is included in the request (as all modern browsers add). In this case, the first request loads fine (and sends a gzipped response), but then subsequent requests fail. The _gzip version of the cache file is not produced in that same directory. The failure manifests itself in a few ways. At some point, there were 500 response codes. But I disabled everything else, and now the response can be consistently reproduced as a 200-code with the following headers, and no actual body:

    HTTP/1.1 200 OK
    Server: nginx
    Date: Wed, 19 Jun 2013 22:50:49 GMT
    Content-Type: text/html
    Transfer-Encoding: chunked
    Connection: keep-alive
    X-Powered-By: PHP/5.3.25
    Vary:
    Content-Encoding: gzip

    I am happy to do the legwork to track this down, but I just need a few hints on how to start debugging. Unlike rails, I don’t know how to interactively debug php-fpm, or this plugin. Blackbox debugging would be great; i can’t even seem to get the php log files to track down the code paths that are followed in the gzip request.

    Help appreciated.

Viewing 5 replies - 1 through 5 (of 5 total)
  • Thread Starter abb78790

    (@abb78790)

    >First, thanks Frank for such a great and comprehensive plugin.
    ————- ^^ I mean Frederick here.

    Thread Starter abb78790

    (@abb78790)

    Update: I believe that reverting to 0.9.2.10 has fixed the issue. gzip seems to work now, so i wonder if there is something in the update that changed the behavior on this point.

    @abb78790 is this the “blank page” issue?

    The blank page is only served (second visit of any user not logged in) when I have Page Cache Debug turned On. If I don’t turn that on, It works well, but I don’t really know how to find out if Page Cache is actually working (without using the debug mode). What would you suggest?

    I’ve had the same problem and have to turn Page Cache Debug off to get my page to load. Unfortunately my page performance dropped from 100/100 back down to 79/72 where it basically was before installing W3 Total Cache. I wish I had the option of reverting back to the earlier version of W3TC, but I just installed the plugin and all I have is the updated version. ?? Hopefully, the problem will be resolved soon.

    You can always revert to older versions:

    https://www.ads-software.com/plugins/w3-total-cache/developers/

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘W3TC disk_enhanced Page caching gzip debugging’ is closed to new replies.