Not all presence updates should be sent out over federation immediately.

[erikjohnston]

Similarly to #8955, not all presence updates are urgent and are safe to delay for a short time (e.g. online to idle transitions which are done based on fairly arbitrary timers). By not immediately sending out these updates it allows Synapse to potentially batch up these presence updates with other data that needs to be sent, reducing the number of overall transactions sent.

[anoadragon453]

We could also do this based on whether a user shares a private room with another user.

Send out presence updates to users you share a private room with immediately, and wait until the next transaction for those users you only share a public room with.

[babolivier]

According to:

synapse/synapse/handlers/presence.py

Lines 1270 to 1273 in 473dfec

	if now - last_federate > FEDERATION_PING_INTERVAL:
	# Been a while since we've poked remote servers
	new_state = new_state.copy_and_replace(last_federation_update_ts=now)
	federation_ping = True

(which seems to be the central place fed pings that are purely presence are sent from, as far as I've crawled through the various code paths), it looks like we only let presence updates trigger immediate fed pings once every FEDERATION_PING_INTERVAL (25min) per user. So it sounds like we're already doing this?

[erikjohnston]

Ah right. That's making sure that we don't send out presence updates too often, but this issue is saying that even when we do send out presence updates we shouldn't necessarily immediately send a transaction and instead we can wait a short period to see if any other updates come in that need to be sent to the remote server. That way we can often batch up presence updates with other updates to reduce the number of transactions sent

[babolivier]

Ah right, that makes sense indeed, thanks for clarifying 👍

[realtyem]

Could I get some clarifying details on what you would like here? I'm looking at presence states of:

• online
• unavailable
• offline
• org.matrix.msc3026.busy (which I'll just call busy for brevity)
  Which would you like to see explicitly sent? Or is it really just as simple as it's stated in handle_update() that if state isn't offline then send it? It sounds from the original comment that unavailable is safe to add to that list. Is the potential delay of 25 minutes acceptable for what is essentially an 'idle'?

[deepbluev7]

For me a delay of 30s would be enough. Currently I sometimes have 2 clients fighting over presence changes and generating a lot of EDUs in rapid fashing, while some smoothing would be nice. Possibly synapse should just track presence per device and then send the "highest" presence, i.e. busy > online > unavailable > offline.

[realtyem]

That's interesting. There is already an anti-flicker mechanism coded in, I believe.

I went and took a peek to find it, it seems to only be used on worker deployments(but I may have missed it for monolith in my haste). Is that what you have?

I feel like I read something about this in an issue somewhere

[deepbluev7]

No, I can reproduce this on a worker setup. But I haven't tried it in the last 2 months or so, since it causes a lot of CPU use on my server.

[realtyem]

I found the original issue I saw this in, it was closed after a bunch of work was done to largely make the situation better(but apparently this segment wasn't addressed). I will add this to my to-do list to investigate. Perhaps open a new issue with the details you provided, as many details as you can. I'll see what I can do