problems with install, precache, and debug header

  • Resolved superawesomedude

    (@superawesomedude)


    10 years, 2 months ago

    We tried this out hoping for a simple, lightweight solution for WP page caching via memcache as we had run into problems with the now-very-old memcached/batcache combo.

    It looks really nice… unfortunately, we ran into 3 separate problems (and one “concern”) before giving up and deciding this might just need more time to bake. Seems like it just wasn’t made with our environment in mind. We could proceed and set this up, but decided we’d like to keep looking. We may come back to it, though. ??

    1) After installation once we seemed to be all done, nothing was actually working. The panel didn’t indicate any problems, but it also wasn’t caching. We had followed all the install instructions. Eventually while browsing around here it became apparent that there was supposed to be a wp-content/advanced-cache.php file… this isn’t provided, but *generated*. In our environment it couldn’t write that file due to permissions, and wouldn’t have worked anyway due to running on a cluster where each node is independent. We were able to work around this, but it is a rather annoying problem as it makes it impossible to change the config in the UI. Database-stored settings would be more convenient (at least in our case). File-based is okay too, but in our env the expectation is that file-based settings are managed by editing the file and not using the app (like editing wp-config.php), so this breaks our convention and a dependency on a shared filesystem or replication.

    2) The X-Cache-Engine header doesn’t work. Didn’t dig into this, but it appeared to be a problem along the lines of the “cannot modify headers; headers already sent” variety. The HTML comment worked fine.

    3) The Precache function didn’t work for us. Sadly I don’t have the exact error, but it was some sort of a php fatal error in the plugin. I know that’s not helpful. Sorry. ??

    Another concern is the inability to flush all of the cache and *only* this plugin’s cache. Having to flush the whole memcache node is problematic for us, as that wipes cache for several other apps’ cache as well, including session data. The other invalidation methods might be sufficient- we ran out of time and had to move on and try other plugins, so we didn’t get a chance to test them out.

    Our general impression is that this looks really slick (and potentially a modern replacement for batcache), but probably not for us just yet. Definitely looking forward to future versions. ??

    https://www.ads-software.com/plugins/wp-ffpc/

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Author petermolnar

    (@cadeyrn)

    1) The settings are in the db, but WordPress requires advanced-cache.php in order for the cache layer to work.

    2) & 3 ) I’ll look into them.

    Flush: unless someone comes up with paging or grouping in memcached, I’d recommend spining up a separate memcached daemon for it.

    Thread Starter superawesomedude

    (@superawesomedude)

    1) Would it be possible to then simply ship a valid advanced-cache.php in the plugin, rather than (or perhaps in addition to) generating it? The impression I got was that it had to be generated because the contents of it depended on the settings set in the UI. If that’s not the case and it never changes, that definitely helps in our case. ??

    Re: flush: my thinking on that was rather than actually flushing, simply prepend a fixed “salt” to all keys. Then when a flush happens simply change the salt. The old KV pairs would stay in memcache, but would no longer match anything and should eventually expire due to their TTL. It’s not as clean as actually removing them, but it guarantees a perfect, app-specific flush operation.

    Thanks!

    Plugin Author petermolnar

    (@cadeyrn)

    1) the advanced cache is generated from the UI settings unfortunately

    I like the flush idea, but I’d never be able to do it in an nginx-safe way.

    Plugin Author petermolnar

    (@cadeyrn)

    I have an idea for this.

    In theory, the advanced-cache settings could be stored in either the same or a separate memcached instance and then it could be spread across multiple machines from the same memcached hosts.

    Since memcached could be flushed ( from other programs as well ) I still need a local backup of the settings, just in case something goes wrong, but in theory this could work. What do you think?

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘problems with install, precache, and debug header’ is closed to new replies.