super cache for logged in users really slow

  • The plugin is fantastic, and in conjunction with hyperdb and db cache reloaded and memcache, my website loads instantly even though there are a large number of queries and assets to get.

    However, i believe there is an issue with logged in users. I can accept that its not a good idea to serve cached pages as content will be specific to the user or user-level. So if i switch off caching for known users, then why does it take 5 seconds to render each page? It is as if it is generating a cache file anyway but not serving it.

    Here’s what i’ve found with the help of a server daemon “new relic” which is brilliant btw.

    Switching caching off completely it takes about 1 second for an average response time for the homepage for logged and non logged in users.

    Switching caching on with mod_rewrite mode, when there is a cached home page there to serve, it only takes 300ms to respond. Brilliant! The catch is though, it’s only for non logged in users. If i am logged in, it takes 4.5 seconds to respond.

    Why when I have tried known users on or off does it still take up to 5 seconds to respond, when if i disable the plugin it takes 1 second.

    There has to be something we can do about this. It’s not mysql, and it’s not browser caching and its not external content causing a delay. It is definitely related to generating a cache file regardless of being told not to.

    I am happy to pay for someone to come up with a solution!

Viewing 6 replies - 1 through 6 (of 6 total)

  • First thing to do is find out where the slow down is occurring. I’d use error_log() and log the date with seconds to a file. Start with wp-cache-phase1.php and then in wp-cache-phase2.php in the wp_cache_ob_callback() function.

    Thread Starter sessna8

    (@sessna8)

    Well, can’t produce any errors, however i’ve logged the debug for my own IP as a logged in user (with “do not cache for logged in users” unticked).

    01:27:58 /2011/05/unlike-many-areas-on-saturday-port-phillip-had-quite-a-bit-of-action-this-weekend/ Cookie detected: wordpress_logged_in_1cb6a53dd8576a409368bba3bda7699b
    01:27:58 /2011/05/unlike-many-areas-on-saturday-port-phillip-had-quite-a-bit-of-action-this-weekend/ supercache dir: /home/jamesmar/public_html/wp-content/cache/supercache/www.marketnews.com.au/2011/05/unlike-many-areas-on-saturday-port-phillip-had-quite-a-bit-of-action-this-weekend/
    01:27:58 /2011/05/unlike-many-areas-on-saturday-port-phillip-had-quite-a-bit-of-action-this-weekend/ Cookie detected: wordpress_logged_in_1cb6a53dd8576a409368bba3bda7699b
    01:27:58 /2011/05/unlike-many-areas-on-saturday-port-phillip-had-quite-a-bit-of-action-this-weekend/ No wp-cache file exists. Must generate a new one.
    01:27:59 /2011/05/unlike-many-areas-on-saturday-port-phillip-had-quite-a-bit-of-action-this-weekend/ Cookie detected: wordpress_logged_in_1cb6a53dd8576a409368bba3bda7699b
    01:27:59 /2011/05/unlike-many-areas-on-saturday-port-phillip-had-quite-a-bit-of-action-this-weekend/ In WP Cache Phase 2
    01:27:59 /2011/05/unlike-many-areas-on-saturday-port-phillip-had-quite-a-bit-of-action-this-weekend/ Setting up WordPress actions
    01:27:59 /2011/05/unlike-many-areas-on-saturday-port-phillip-had-quite-a-bit-of-action-this-weekend/ Created output buffer
    01:27:59 /2011/05/unlike-many-areas-on-saturday-port-phillip-had-quite-a-bit-of-action-this-weekend/ Cookie detected: wordpress_logged_in_1cb6a53dd8576a409368bba3bda7699b
    01:28:04 /2011/05/unlike-many-areas-on-saturday-port-phillip-had-quite-a-bit-of-action-this-weekend/ Output buffer callback
    01:28:04 /2011/05/unlike-many-areas-on-saturday-port-phillip-had-quite-a-bit-of-action-this-weekend/ Cookie detected: wordpress_logged_in_1cb6a53dd8576a409368bba3bda7699b
    01:28:04 /2011/05/unlike-many-areas-on-saturday-port-phillip-had-quite-a-bit-of-action-this-weekend/ Gzipping buffer.
    01:28:04 /2011/05/unlike-many-areas-on-saturday-port-phillip-had-quite-a-bit-of-action-this-weekend/ Writing gzipped buffer to wp-cache cache file.
    01:28:04 /2011/05/unlike-many-areas-on-saturday-port-phillip-had-quite-a-bit-of-action-this-weekend/ Renamed temp wp-cache file to /home/jamesmar/public_html/wp-content/cache/wp-cache-9b7bedd9ffc7c402e67d4439a5dbd854.html
    01:28:04 /2011/05/unlike-many-areas-on-saturday-port-phillip-had-quite-a-bit-of-action-this-weekend/ Writing gzip content headers. Sending buffer to browser
    01:28:04 /2011/05/unlike-many-areas-on-saturday-port-phillip-had-quite-a-bit-of-action-this-weekend/ wp_cache_shutdown_callback: collecting meta data.
    01:28:04 /2011/05/unlike-many-areas-on-saturday-port-phillip-had-quite-a-bit-of-action-this-weekend/ Writing meta file: /home/jamesmar/public_html/wp-content/cache/meta/wp-cache-9b7bedd9ffc7c402e67d4439a5dbd854.meta

    Thread Starter sessna8

    (@sessna8)

    Seems there is a 5 second lag from creating the output buffer and then performing the buffer callback. Whether it takes 5 seconds to buffer the output, or there is something else which happens in between the buffer and then the callback – i dont know. There’s no errors appearing in the error log.

    That 5 seconds is where WordPress runs and does it’s thing. You’ll probably need to do more debugging unfortunately.

    Thread Starter sessna8

    (@sessna8)

    the thing is donncha that when i disable your plugin, the non-cached pages actually load almost as fast as cached pages (but not quite). But with the plugin activated, it still appears to create a render (but not actually used) when asked “not to” for logged in users.

    could i interest you in paying for your time to help identify the issue in our setup?

    Thread Starter sessna8

    (@sessna8)

    hi donncha
    i’ve identified what is happening to cause the delay in the two stages of the log file.

    First delay is being caused by an external rss fetch. Second is being caused by an external js load. These must be holding up the onload time for the page when rendering it. The difference between browsing and rendering the page is that the page when browsed loads these two assets in the background not affecting user experience. However your cache wont start until the page is loaded.

    Now this i can accept if i choose to have logged in users cache pages. But I have selected for logged in users to not have cached pages. So why is your script still waiting for a page to render before serving it to the browser client. It should just simply ignore any super cache behaviour and load the page as if the plugin was disabled.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘super cache for logged in users really slow’ is closed to new replies.