[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
wrong?
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