Support

Account

Forum Replies Created

  • Sorry, not sure what happened there. See this gist with the local.php file

    https://gist.github.com/spacedmonkey/d5a4ae7ef4df86de10f7#file-local-php-L164-L173

    The highlighted lines are the important lines changed. We are using the on live and has fixed the issue for us.

  • I have been talking to Elliot about this over email. I have a patch for this bug, but I am not sure what he is going to do about it.

    The patched local.php is attached. All it does, is save the group to cache and only do the delete commands if something in the group has changed. It adds a get to memcache, but saves tonnes of deletes.

    Hope this helps.

  • For those who wish to help out can people please comment on the following files

    wp_cache_delete( “get_field/key={$field[‘key’]}”, ‘acf’ );
    wp_cache_delete( “get_fields/parent={$field[‘parent’]}”, ‘acf’ );

    In acf-pro/core/local.php on line 223.

    Let’s see what effect this will have. Hopefully these lines are not required.

  • I am just using the standard memcache plugin and elasticache cluster in AWS. Nothing special about it. When using memcache, calls to the wp_cache_* functions are stored in a persistent object cache called memcache. Persistent object cache are used to speed up sites, because values like queries, meta and objects are stored and kept in between sessions.

    When looking through my new relic data I notice an extremely high number call to the wp_cache_delete function. This is account for around 11.2% of page load. On a high traffic site (multiple million a day), it account for a lot of computing power wasted.

    I want to get a deeper understanding of the reasoning behind this move and see if they plugin was tested using a persistent object cache.

    Thanks.

  • This is very confusing. So here is what I am understanding is happening.

    The register acf group function is called. As WP / ACF doesn’t know if this field has been registered before or if it has changed, for good measure it is deleting the field set stored in object cache. Then it creates all the field again for this page load.

    This is madness. Object cache calls should never used to store data only used for a single page load. Persistent object caching is designed to keep data between user sessions. It the data is going to be created and deleted on the fly like this, a php / class level variable should used as it is none persistent.

    At the moment, these pointless deleting of objects in cache are resulting in for about 13% of my page load, every page load.

Viewing 5 posts - 1 through 5 (of 5 total)