[buddypress-trac] [BuddyPress Trac] #7245: Updating user last_activity doesn't bust activity query cache

buddypress-trac noreply at wordpress.org
Tue Sep 6 02:12:25 UTC 2016

#7245: Updating user last_activity doesn't bust activity query cache
 Reporter:  boonebgorges            |       Owner:
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  2.7
Component:  Members                 |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |

Comment (by boonebgorges):

 Thanks for the review, @DJPaul.

 > Off-topic: the phpdoc for bp_core_reset_incrementor is incorrect. Was
 that function MEANT to return a bool, or is it the documentation that's

 Fixed in [11060].

 > Such a short-lived cache would have little value to the significant
 majority of BuddyPress of sites.

 I'm not sure enough about numbers to say that it'd affect a "majority" or
 "significant majority", but I agree that the cache will be of little for
 low-traffic sites, or sites where all members are logged in. But sites
 that have any significant number of logged-out users - as many of my
 client sites do - will see meaningful performance benefits from having
 last_active queries cached.

 > I think using strpos to identify the query is going to be too naive, but
 the idea's sound.

 Yes, that was meant to be an illustration only. Unfortunately, we do have
 to do string sniffing (rather than argument detection) because the SQL
 statement goes through a filter. [attachment:7245.2.diff] uses a regular
 expression to detect clauses of the form `a.type NOT IN ( ...
 'last_activity' ... )`; this clause should exist in all default activity
 queries, as BP excludes 'last_activity' items from activity queries unless
 specifically requested.

 > Another idea is updating the last_activity timestamps less frequently.
 Say, every 15 minutes instead of every 5 minutes.

 5 minutes is pretty arbitrary. You're right that we should probably
 consider this separately, though, since what I'm proposing here is
 required either way.

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7245#comment:7>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac

More information about the buddypress-trac mailing list