• Resolved iamthedan

    (@iamthedan)


    In the documentation for WPP there’s a section on Caching Pageviews for high traffic sites. Step 2 of that process is “install and set up a persistent object cache plugin on your site” and it lists a few notable plugins as examples.

    We’re using W3 Total Cache to expose the Memcached object cache. Can you confirm whether or not WPP works with W3TC when caching pageviews?

    The page I need help with: [log in to see the link]

Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Author Hector Cabrera

    (@hcabrera)

    Hi @iamthedan,

    As long as Memcached is available then WPP should be able to detect that it’s there and use it (assuming you’ve followed all 3 steps mentioned in that link that is), so yep it should work.

    I believe Memcached provides some terminal commands that you could use to verify that WPP’s data is somewhere in there. Try looking for a key that contains _wpp_cache in its name, that’s where WPP stores its views data.

    • This reply was modified 1 year ago by Hector Cabrera. Reason: Added clarification about the setup part
    Thread Starter iamthedan

    (@iamthedan)

    Such a quick response! Thank you!

    I’ll look deeper into it and try to report back here with any updates in case anyone else has questions in the future.

    Plugin Author Hector Cabrera

    (@hcabrera)

    Don’t mention it, glad I could help!

    Do let me know though if you find any issues with this, I haven’t tested W3TC’s Memcached implementation since I don’t expect it to be any different from the other options but you never know.

    Thread Starter iamthedan

    (@iamthedan)

    Our WPP debug page does report that External object cache is “Yes” and that WPP_CACHE_VIEWS is also “Yes”. Unfortunately we have not been able to see WPP hit memcached using W3TC. Running memdump | grep wpp did not return any results while looking through our output, though there’s a decent chance we’re just missing it when it comes through. We’ve “resolved” our issue in other ways, seen below, so we’re done pursuing it for now.

    I did want to pass along though that the reason we were pursuing view caching is because the Google spider was triggering calls to the /wp-json/wordpress-popular-posts/v1/popular-posts endpoint (we’re running 6.3.4, you may have fully depreciated that endpoint for the /wp-json/wordpress-popular-posts/v2/views/* ones by now) and we were taking a performance hit. I had not expected Googlebot to trigger that since it lived in JS. Adding the endpoint to robots.txt solved the issue, but maybe that’s something you’d consider adding with the robots_txt filter as part of the plugin?

    Thanks again for your speedy help!

    Plugin Author Hector Cabrera

    (@hcabrera)

    Unfortunately we have not been able to see WPP hit memcached using W3TC

    Thanks for the report. I’ll try installing W3TC on localhost + Memcached for testing and get back to you once I have more info.

    Adding the endpoint to robots.txt solved the issue (…)

    Actually there are two endpoints named v1/popular-posts:

    • One that handles GET requests and returns a list of popular posts (which is what Google is trying to crawl)
    • One that handles POST requests, saves views data into the database (and this is the endpoint that was deprecated in favor of v2/views)

    For the GET one I may consider restricting access to bots via the robots_txt filter hook as you suggested, I don’t think Google should be looking in there for data since they can just crawl the site and/or its sitemap instead.

    Thread Starter iamthedan

    (@iamthedan)

    To be clear, the requests we were getting from Googlebot were the POST requests. We know this because we don’t have the block on the frontend of the site and don’t use AJAX to display results (they’re displayed from the PHP backend using the Popular_Posts_Data class). Additionally our logging allows us to filter by type of request.

    Plugin Author Hector Cabrera

    (@hcabrera)

    Alright, this took way longer than expected but I was able to test the memcached integration with W3TC and… it seems to be working but I’m not 100% sure.

    W3TC seems to use its own cache key names (and because there are a lot of items in the cache it would have been quite time consuming to check every single one of them hence why I’m not sure lol), like so for example (truncated for brevity):

    array(75) {
      [0]=>
      string(46) "w3tc_1055152965_0_pgcache_sitemaps_key_version"
      [1]=>
      string(48)
    (...) "w3tc_1055152965_wordpress.local_0_object_78b25acff342bf608cf26254b78c14ad"
      [20]=>
      string(73)
    (...) "w3tc_1055152965__0_pgcache_e5bf78389de0ac7ad7d3e410aaab68ee"
      [72]=>
      string(73) "w3tc_1055152965_wordpress.local_0_object_cee7f7aa0ef146b3defcdbd7815d3c94"
      [73]=>
      string(59) "w3tc_1055152965__0_pgcache_5cf3dbb3f0173ed690eaab96c28ad8bd"
      [74]=>
      string(73) "w3tc_1055152965_wordpress.local_0_object_24323edbccb901e5a0984528a27a01e7"
    }

    As a sanity check I installed a different plugin (Object Cache for Everyone by fpuenteonline) and I do see the _wpp_cache key in there (truncated for brevity):

    Array(139) {
      [0]=>
      string(35) "wordpressrootwp_wp_userlogins:admin"
      [1]=>
      string(34) "wordpressrootwp_wp_userslugs:admin"
      (...)
      [83]=>
      string(40) "wordpressrootwp_wp_:transient:_wpp_cache"
      (...)
    }

    As a side note, I also noticed that Automattic’s WP Memcached plugin seems to be broken at the moment (or at least it throws a fatal error on my local setup) so I’m updating the wiki to recommend another plugin instead.

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘Does WPP Work with W3TC to Cache Pageviews?’ is closed to new replies.