WordPress.org

Forums

WP Super Cache
[resolved] no improvement for feeds (13 posts)

  1. RavanH
    Member
    Posted 4 years ago #

    Hi Donncha,

    After running WP Super Cache on a WP3 Multisite install for a few days, I notice (looking at ismyblogworking.com graph results) that normal page response time has dropped from about 1 second to 0.5 which is excellent :)

    But the feed response time has remained exactly the same as before. When I open the folder /wp-content/cache/supercache/domainname.ext/feed/ there is no index.html(.gz) and when I open the feed in an anonymous browser and look at the source footer, then refresh and look again, there is a difference in the reported generation time:

    <!-- Dynamic page generated in 0.461 seconds. -->
    <!-- Cached page generated by WP-Super-Cache on 2011-04-08 13:53:27 -->
    <!-- Compression = gzip -->

    I do see a corresponding file in /wp-content/cache/ with a name like wp-cache-domainname.extxxxxxxxxx.html with matching feed content. So I suppose the feed is passed through WP-Cache instead of Super Cache... Is there a special reason for that? And why does it not improve the response time at all?

    Can I make some changes in WP Super Cache settings to improve it? I tried going from PHP to mod_rewrite mode but apart from mangled gzip files (but that's another issue for which I did not try switching off server compression yet) the issue remains the same ;(

    Thanks :)

    http://wordpress.org/extend/plugins/wp-super-cache/

  2. Donncha O Caoimh
    Member
    Plugin Author

    Posted 4 years ago #

    It's cached using legacy (wp-cache) caching because of the headers needed to be sent to the visitor's browser/bot. Unfortunately those headers aren't recorded for supercache files.

    You should probably enable debugging in the plugin. Perhaps your blog gets enough comments that the feed is invalidated between tests? Leaving a comment will delete the cache for the feed.

  3. RavanH
    Member
    Posted 4 years ago #

    Ok, although I see this also on a site that does not get very regular comments (but a lot of spam that gets caught... could that cause invalidation of the cached feeds?) I will investigate further with debugging ON. Thanks :)

  4. RavanH
    Member
    Posted 4 years ago #

    Before even going to DEBUG mode, I find in the error log some weird messages:

    (longer ago, during install maybe?)

    [05-Apr-2011 20:56:33] PHP Warning:  implode() [<a href='function.implode'>function.implode</a>]: Invalid arguments passed in /xxx/xxx/wp-content/plugins/wp-super-cache/wp-cache.php on line 2443

    (then, returning on a regular basis)

    [14-Apr-2011 17:49:07] PHP Fatal error:  Call to a member function get() on a non-object in /xxx/xxx/wp-includes/cache.php on line 93

    But I do not see any relation to a feed being requested...

  5. RavanH
    Member
    Posted 4 years ago #

    With DEBUG on, and requestion a feed three times shortly after each other (marked by me with blank line), I notice in the log output that each time the it states "No wp-cache file exists. Must generate a new one." even though both a .html and .meta file are created and available in the /cache/ dir.

    20:12:38 /feed/ supercache dir: /xxx/xxx/wp-content/cache/supercache/domainname.ext/feed/
    20:12:38 /feed/ No wp-cache file exists. Must generate a new one.
    20:12:38 /feed/ In WP Cache Phase 2
    20:12:38 /feed/ Setting up WordPress actions
    20:12:38 /feed/ Created output buffer
    20:12:39 /feed/ Output buffer callback
    20:12:39 /feed/ Feed detected. Writing legacy cache files.
    20:12:39 /feed/ Supercache disabled: GET or feed detected or disabled by config.
    20:12:39 /feed/ Gzipping buffer.
    20:12:39 /feed/ Writing gzipped buffer to wp-cache cache file.
    20:12:39 /feed/ Renamed temp wp-cache file to /xxx/xxx/wp-content/cache/wp-cache-domainname.ext33683e007440bd2aafe68d90089cdee7.html
    20:12:39 /feed/ Writing gzip content headers. Sending buffer to browser
    20:12:39 /feed/ wp_cache_shutdown_callback: collecting meta data.
    20:12:39 /feed/ Writing meta file: /xxx/xxx/wp-content/cache/meta/wp-cache-domainname.ext33683e007440bd2aafe68d90089cdee7.meta
    
    20:12:44 /feed/ supercache dir: /xxx/xxx/wp-content/cache/supercache/domainname.ext/feed/
    20:12:44 /feed/ No wp-cache file exists. Must generate a new one.
    20:12:44 /feed/ In WP Cache Phase 2
    20:12:44 /feed/ Setting up WordPress actions
    20:12:44 /feed/ Created output buffer
    20:12:45 /feed/ Output buffer callback
    20:12:45 /feed/ Feed detected. Writing legacy cache files.
    20:12:45 /feed/ Supercache disabled: GET or feed detected or disabled by config.
    20:12:45 /feed/ Gzipping buffer.
    20:12:45 /feed/ Writing gzipped buffer to wp-cache cache file.
    20:12:45 /feed/ Renamed temp wp-cache file to /xxx/xxx/wp-content/cache/wp-cache-domainname.ext33683e007440bd2aafe68d90089cdee7.html
    20:12:45 /feed/ Writing gzip content headers. Sending buffer to browser
    20:12:45 /feed/ wp_cache_shutdown_callback: collecting meta data.
    20:12:45 /feed/ Writing meta file: /xxx/xxx/wp-content/cache/meta/wp-cache-domainname.ext33683e007440bd2aafe68d90089cdee7.meta
    
    20:13:00 /feed/ supercache dir: /xxx/xxx/wp-content/cache/supercache/domainname.ext/feed/
    20:13:00 /feed/ No wp-cache file exists. Must generate a new one.
    20:13:00 /feed/ In WP Cache Phase 2
    20:13:00 /feed/ Setting up WordPress actions
    20:13:00 /feed/ Created output buffer
    20:13:01 /feed/ Output buffer callback
    20:13:01 /feed/ Feed detected. Writing legacy cache files.
    20:13:01 /feed/ Supercache disabled: GET or feed detected or disabled by config.
    20:13:01 /feed/ Gzipping buffer.
    20:13:01 /feed/ Writing gzipped buffer to wp-cache cache file.
    20:13:01 /feed/ Renamed temp wp-cache file to /xxx/xxx/wp-content/cache/wp-cache-domainname.ext33683e007440bd2aafe68d90089cdee7.html
    20:13:01 /feed/ Writing gzip content headers. Sending buffer to browser
    20:13:01 /feed/ wp_cache_shutdown_callback: collecting meta data.
    20:13:01 /feed/ Writing meta file: /xxx/xxx/wp-content/cache/meta/wp-cache-domainname.ext33683e007440bd2aafe68d90089cdee7.meta

    The resulting feed has a new timestamp for each request.

    The /cache/ dir and subdirs have 755 and all files inside have 644 access rights and same owner as all other WP files.

    Anything wrong with my install here? Thanks for any thoughts :)

  6. Donncha O Caoimh
    Member
    Plugin Author

    Posted 4 years ago #

    I don't know why that happens. Maybe check wp-cache-phase1.php for the code that serves cached pages?

  7. RavanH
    Member
    Posted 4 years ago #

    I would not have a clue where to start ;(

    But to recap: feeds are supposed to go through WP-Cache rather than Super Cache (so no issue there) but the fact that I see them recreated on each request is not normal, correct?

    Anybody else see this happening to feeds while normal pages are cached just fine? I'm on a LiteSpeed server. Could that affect anyting?

  8. RavanH
    Member
    Posted 4 years ago #

    I did another test and found I can make this issue happen on all pages/posts by switching from PHP to Legacy page caching mode.

    Which makes sence... So it's definitely WP Cache that's slipping on my LiteSpeed server. But why? Switching Compress pages ON also does funny things to my pages which seems LiteSpeed related too...

  9. RavanH
    Member
    Posted 4 years ago #

    PLOP! Found it... (Ok, stumbled across it, actually)

    When in Legacy page caching mode, and with Late init switched ON the wp-cache files are served like they should for all pages/posts/feeds on my LiteSpeed served WP site.

    When going back to PHP or mod_rewrite mode, feeds are still served from the wp-cache files :) ... This seems good for my feed-speed, but what does Late init do for my normal posts and pages?

    Will they suffer a speed hit now in either PHP or mod_rewrite mode (or both) compared to without Late init?

  10. Donncha O Caoimh
    Member
    Plugin Author

    Posted 4 years ago #

    Late init just causes the cached pages to be served when the "init" action fires. That means that all of WordPress is loaded. It should still be very fast, but not quite as fast as before.

  11. RavanH
    Member
    Posted 4 years ago #

    Late init just causes the cached pages to be served when the "init" action fires.

    Even when using mod_rewrite mode? I was under the impression the .htaccess rules make most requests completely bypass WP...

  12. Donncha O Caoimh
    Member
    Plugin Author

    Posted 4 years ago #

    No, just when using PHP mode or legacy mode.

  13. RavanH
    Member
    Posted 4 years ago #

    Excellent!

    So by checking Late init to make WP-Cache work on LiteSpeed for feeds (including my sitemap.xml) and using mod_rewrite mode for normal pages/posts, this issue is solved :)

Topic Closed

This topic has been closed to new replies.

About this Plugin

  • WP Super Cache
  • Frequently Asked Questions
  • Support Threads
  • Reviews

About this Topic