WordPress.org

Ready to get started?Download WordPress

Forums

APC Object Cache Backend
set_transient() not working with APC object cache backend (9 posts)

  1. meeble
    Member
    Posted 1 year ago #

    Hi,

    I have APC installed on my server along with APC Object Cache Backend for WP. When I disable the object-cache.php by moving it out of my wp-content directory, I am able to successfully use set_transient() in my php code / plugins. i.e. rows are successfully written to my wp-options table. I need to be able to have persistent cache objects that won't expire for a month or longer, and WP's set_transient works perfectly for me.

    Is there a way to get this working with APC and the object-cache backend?

    http://wordpress.org/extend/plugins/apc/

  2. Mark Jaquith
    WordPress Lead Dev
    Plugin Author

    Posted 1 year ago #

    With an object cache backend, transients will be stored in that object backend <b>and will not get written to the options table</b>. So the "not writing to the wp_options table" part is expected.

    Throw something like this in your WP root then hit it up:

    <?php
    include( 'wp-load.php' );
    set_transient( 'foo', 'bar' );
    var_dump( get_transient( 'foo' ) );

    Next, comment out the set_transient() line to test the permanence of the transient. If that doesn't work, let me know:

    • What version of APC?
    • What version of the backend?
    • What version of WordPress?
    • Single server situation?
  3. meeble
    Member
    Posted 1 year ago #

    Hi Mark,

    Thanks for your quick response. The first time I ran the page, I got this response:

    string(3) "bar"

    After commenting out the set_transient line, I get this:

    bool(false)

    Here's the info you asked for:
    APC version: 3.1.13
    PHP version: 5.3.3
    Backend version: 2.0.4
    WP version: 3.5 RC2 (this is a new dev site)
    Single server? yes

    Thanks again!

  4. meeble
    Member
    Posted 1 year ago #

    Hi Mark,

    Any ideas about how to fix this?

    Thanks,
    Devin

  5. meeble
    Member
    Posted 1 year ago #

    Mark,

    Update: I migrated my site over to a new server with PHP 5.4.10 and now transients are working fine with APC object cache enabled. I also switched from mod_fcgid to php-fpm - not sure if that could have anything to do with it.

    Thanks,
    Devin

  6. RavanH
    Member
    Posted 1 year ago #

    Hi Devin,

    I did the transient test too but added one more step...

    On a WP 3.5 Multisite with APC Object Cache Backend 2.0.6 running on VPS with Debian Squeeze, Nginx 1.3.3, PHP-FPM 5.3.20 and APC 3.1.9

    Both times, the request showed me
    string(3) "bar"
    But then I removed wp-content/object-cache.php, refreshed a third time and got:
    bool(false)
    And moving the object-cache.php back into place, the old bar value is echoed again...

    Not completely sure what it means, but the result does worry me a bit :(

  7. RavanH
    Member
    Posted 1 year ago #

    Similarly, clearing the APC immediately after the first two requests, results in bool(false) on third request... The transient did not make it into the database.

  8. jaroat
    Member
    Posted 1 year ago #

    Hi all -

    Does anyone have a solution yet?

    Same problem on a customers server:

    set- and get-(site)-transient runs fine without APC Object Cache Backend (default db storage) - As soon as I copy object-cache.php to wp-content: no cache hits anymore.

    set_site_transient always returns TRUE
    i can't see my transients in apc.php (User Cache Entries)

    • 5.3.2-1ubuntu4.18
    • APC 3.1.3p1
    • WP 3.5.1
    • APC Backend 2.0.6

    Without object-cache.php, Marks test case returns String(3)"bar", with object-cache.php it returns bool(false).

    br from Salzburg,

    - Johannes

  9. RavanH
    Member
    Posted 1 year ago #

    Hi Johannes, my only solution has been to disable the APC Object Cache Backend plugin... As Mark (the developer) said:

    With an object cache backend, transients will be stored in that object backend and will not get written to the options table. So the "not writing to the wp_options table" part is expected.

    Too bad because the plugin did noticeably improve site speed. But then, it also caused a huge amount of cache fragmentation which worried me a bit. Plus these weird effects where options seemed to not get saved while they actually where and vise-versa, which is hard to explain to clients.

    Ah well... Stability before speed, hey?

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic