• Summary: In Expert Mode Apache correctly serves cached page via mod_rewrite, then incorrectly passes every page request to PHP, effectively nullifying the entire caching process. This takes down high traffic sites in a few seconds.

    Steps to Reproduce:

    Opcache disabled for all testing.

    To duplicate.

    Enable Expert Mode with all recommended options enabled.

    At this point Update Status also updates mod_rewrite rules, which is new behavior + is good.

    Verified mod_rewrite rules now exist in .htaccess as expected.

    Now run a load test on site…

    h2load -ph2c -t16 -c16 -m16 -n1600 https://foo.com/
    ... ... ...
    finished in 2.00s, 801.07 req/s, 38.86MB/s
    status codes: 1600 2xx, 0 3xx, 0 4xx, 0 5xx

    Good. All requests processed with 100% success rate.

    Camping on cache file of main index.php looks good.

    inotifywait -mrq ./wp-content/cache/supercache/foo.com/index-https.html

    Show file is being opened + read + closed without updating, so all appears well.

    ./wp-content/cache/supercache/foo.com/index-https.html OPEN
    ./wp-content/cache/supercache/foo.com/index-https.html ACCESS
    ./wp-content/cache/supercache/foo.com/index-https.html ACCESS
    ./wp-content/cache/supercache/foo.com/index-https.html ACCESS
    ./wp-content/cache/supercache/foo.com/index-https.html ACCESS
    ./wp-content/cache/supercache/foo.com/index-https.html CLOSE_NOWRITE,CLOSE

    And… why so slow…

    Checking /var/log/php7.1-fpm/access.log explains why.

    Every single https://foo.com/index.php access is showing up as being processed by PHP. Appears after cache file is served, then a duplicate request is passed to WordPress to process again.

    I also tried removing index\.php from the strings (not a filename) that forces a page not to be cached section of settings + this produced same effect.

    When mod_rewrite is being used, I’d expect Apache to return the file + never hand off a duplicate request to PHP.

    If you can’t reproduce this, let me know + I’ll clone an LXD container w/root ssh access for a developer to determine a fix.

Viewing 7 replies - 1 through 7 (of 7 total)
  • There’s an easy way to find out if Expert mode is working properly.

    1 Enable debugging and set it to cache requests from your IP only.
    2 Open an Incognito window and visit a post on your blog. Entries for that page view may or may not appear in the log file, depending on if the page is cached or not.
    3 Reload the incognito window a few times. You shouldn’t see a request in the debug log for that page again, at least until the cached page is deleted.

    I’m not using FPM. I’m using Apache+mod_php and I haven’t seen this issue.

    Thread Starter David Favor

    (@dfavor)

    Apache+mod_php no longer supports HTTP2, so best if you change to testing with FPM.

    I’ve already documented what’s working + what’s not.

    The problem is mod_rewrite requests should serve from cache + end the request.

    What’s occurring it the request is then being incorrectly forwarded to PHP, so caching is effectively nullified.

    If you’re unable to setup a test environment to test this, I can setup an LXD container for you with root ssh access.

    Checking logs it’s easy to see the problem.

    It would be very useful to be able to see this in action, thanks. The rewrite rules use very standard notation, ending with [l] flag so processing is supposed to stop when a file is served. If you enable mod_rewrite debugging it’ll tell you more about what’s happening and why it’s ignoring the [l] flag.

    Can you fill in the contact form at the end of https://odd.blog/y/2o and I’ll get back to you. It might be a few days before I can reply however.

    Thread Starter David Favor

    (@dfavor)

    Submitted a contact form + included my Skype ID.

    Thanks for your assistance.

    same thing happend to me.. wp-supercache 1.5.8, wordpress 4.8.3, i’m also using FPM and nginx on my server, php 7

    when i verify if supercache is working from incognito mode it seems that is not working properly

    when i’m logged in on wordpress it’s work fine

    @luckystar2016 – your issue is a different one, and one I can’t help with as we don’t officially support Nginx. The most I can suggest is to look for the Nginx rewrite rules that are on www.ads-software.com or use Google to find a tutorial.

    Thread Starter David Favor

    (@dfavor)

    @luckystar2016 – Using NGINX, if you hit this bug, you can work around it by retooling your NGINX config to do more aggressive caching.

    I don’t use NGINX, as NGINX tends to glitch heavily (crash + restart) under heavy workloads + most of my client sites are heavy workloads.

    You might just drop NGINX + use native Apache, as Apache + mod_event tends to run 20%-30% faster than NGINX, in my testing.

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘WPSC-1.5.8 runs mod_rewrite then passes a duplicate request to PHP’ is closed to new replies.