large bot improvement docs #1016
Conversation
|
With guild_subscriptions, will there be any way to disable just typing events? It seems to be just a boolean that disables both events at the moment. |
|
Since user updates like username/avatar changes are currently sent as part of |
Not currently. Bots ideally don't need these guild subscription events at all. Making bots as stateless as possible allows for easier scaling to more guilds. One of the things I tend to recommend is making bots reactive to user actions (like a user posting in chat, which has the latest user/member data on it).
User updates actually trigger a presence update, but since This is also deployed. There are massive gains to bots which implement these changes. On my bot after applying this flag (in ~200k guilds), uncompressed traffic dropped from ~30Mbps to ~1Mbps avg. CPU also dropped from 20% down to 2-5% avg. Memory use is the same (but I already was following my documented best practices) at 6GB, and it could probably be made even less if I trimmed models. |
|
@night is it expected that you now receive GUILD_CREATE with only one user in them? I just tested this on my bot and it started with a single user in cache. |
|
@MinnDevelopment it is intended, but I forgot to document. when you connect to a guild the members is seeded from presence (which you are unsubscribing from) and voice states. you should still see users in voice in the members list, plus your bot. |
|
Oh, if you have guild subscriptions disabled, does guild member chunking still work? |
|
yes |
|
This change is awesome for bigger bots, but what if we WANT a presence object at some point? GUILD_MEMBERS_CHUNK does not include the presence in the payload, meaning we'd have to create something else to store presence data, which in the end would make this pretty worthless. Is there any planned / already existent way to fetch presences? This would go hand in hand with #666 which was opened almost a year ago 😅 |
What would be an use case for suddenly needing presences in the middle of a bot's lifetime? If you need presences at any point, don't turn off guild subscriptions. The point of the feature is that it's useless state for you and you don't need it at any time, so you can lower your memory footprint by tracking less information. |
Quite a few actually! What if I don't want the massive performance impact of the constant PRESENCE_UPDATE and TYPING_START, but I want to provide, say, a userinfo command that shows something based off your current presence? let's not forget you get a presence update per guild PER shard at times, instead of one request who knows when. I see your point, don't get me wrong, but I believe being able to fetch the presence at some point in a bots lifetime (even if they use this or not) would be helpful! It isn't NEEDED, but it could help a lot |
|
This is an awesome change! @MinnDevelopment was so nice to set up an experimental branch of JDA, and I'm seeing some really nice numbers. On a 150k guild bot that mostly does just responding to messages, CPU is down from 225% to 150%, overall also way less garbage collections. Instead of holding 4-5million user objects in memory and processing almost 1000 completely useless events per second all the bot has to do now is to occasionally fetch the user data from the REST api, whenever it actually does need that data (less than 0.1 requests per second on average). Thank you for deploying this improvement! |
|
It looks like this disables more events than advertised from my testing. The list of events that aren't sent when this is disabled:
The events related to members that are sent:
Additionally, the documentation doesn't mention the fact that the member array in GUILD_CREATE payloads is now limited to the self member and members with a voice state. Currently it just sounds like a flag to reduce traffic by disabling rather useless but frequent events, this doesn't seem to be the intention of this feature. Not receiving member remove and add events is a big issue when you want to implement something that dynamically chunks members of specific guilds or only needs this information for a whitelist of guilds. In JDA I implemented the member chunking on a per-guild basis rather than an on-off switch. It would be ideal if you could tell the gateway to disable subscriptions for specific guilds rather than all of them, or alternatively only enable it for a few guilds. Another issue I noticed is with reaction events since these don't offer any additional information about member and user. Reaction events only provide 3 IDs without context about the user who reacted. This means the bot has to request this information through the REST endpoint instead which can be problematic when you get rate-limited because of it. I'm not sure how to handle this nicely yet. I suppose I have to rewrite major parts of the library to completely disable member caching and chunking when subscriptions are disabled. |
|
Would be cool if it could take an array of event names, then send everything but those. For example in my bot I don't use typing events but I do use presence updates and almost every other member related event. It would be extremely useful to be able to customize which events don't get sent. Ideally along with disabling users in GUILD_CREATE as a separate property. |
|
Are the lack of member events intended? |
I don't think your recommendation can be blanket applied to all bots, it just isn't something everyone could implement and have work for their use-case. Some bots need these guild subscription events for proper functionality. In a perfect world, we'd have a system like macdja's proposal for filtering these events. |
|
I agree, having an option to whitelist/blacklist events would solve most of the issues. I understand the point of bots should only be reactive, but people can be creative and shouldn't be held back because that is what is the usual case. If other options were needed to help bots become more stateless, that could become part of the options too, so users could tailor the API for them and more people would be likely to make such fantastic bots for a platform we all love and use. |
This is a decent feature request. Perhaps we can add the member object to reactions.
Any presence data, including membership, is excluded. It should probably be clarified what "presence events" implies, though I alluded to this in my prior reply about members being derived from presence data already.
Just to clarify, this is an optional configuration you can apply to your bot. If it doesn't support your use case then don't set it to Opting out of specific events is not how guild subscriptions work (which is what our desktop clients use that I merely exposed to bots), and is not something we will likely support anytime soon (if ever). |
|
From what I understand this feature basically disables the automatic connection to the presence subsystem. Would it be possible to add a new op code similar to member chunking requests that allows to manually subscribe to it again? That would allow enabling it for a few special guilds (such as the bot hub server for instance). It seems like the infrastructure would be capable of supporting this. I can see a few use-cases for this kind of interaction. Something like: {
"op": 16,
"d": ["81384788765712384", "125227483518861312"]
} |
Could I ask why this is the case? |
|
While guild_subscriptions can be useful for some bots, it's actually not usable for bots that are reactive to user interactions, like as Minn pointed out for bots that watches member joins and/or leaves, and that tracks some role updates (like to check if an user got muted by manually adding a role). Member leave problem can be solved with #756 feature request which would make sense to receive according to the fact that you get ban events. For others, bots would have to enable guild subscriptions but there is still a lot of events bot don't care about (like PRESENCE_UPDATE or TYPING_START). What can be done to still allow those bots to get upgrades in performances is to allow them to filter only those events (Maybe by making guild_subscriptions an integer where 0 would be enabled, 1 filtering of only presence and typing events, and 2 for the current state of the feature. Field could also get renamed unsubscriptions because the bigger the int gets the less subscriptions you have, would make sense imo). Also i'm curious to know why per-event unsubscription won't ever become a thing. Some bots only need a very few events and it might (if people use it ofc) decrease the bandwidth used, and reduce the amount of payloads to encode. Though I can understand why it may be annoying to implement such a thing given how Discord is internally divided, each worker would continue to send events and subscriptions would have to be forwarded to workers. This might also be a problem for my proposal, but it only touches a single service (from what I understand), so it shouldn't be that annoying. |
If I may ask, what does GUILD_MEMBER_UPDATE / GUILD_MEMBER_ADD / GUILD_MEMBER_REMOVE have to do with PRESENCE_UPDATES? I fail to see a correlation between Presences (which are the Member's status, game, etc) and a member getting a role, joining or even leaving.. I understand that they're tied together, but I still fail to understand why ignoring PRESENCE_UPDATES would also remove my ability to know a member is updated. Are they THAT tied together? If so.. that isn't documented. And TYPING_START really has 0 relations to something like GUILD_MEMBER_ADD/REMOVE/UPDATE, while yes, it depends on a member and a text/news channel, it's got no ties with the mentioned events.. I'm all for this improvement, but as it is right now, this adds far too many changes than what was documented.. |
Internally (at least as how I understand Discord's backend), presences are handled on a per-guild basis, meaning that guild workers deal with presences at some point. As members are part of the guilds, it's the guild worker that handles that work too, explaining the link between them (at least according to my understanding of Discord's backend) |
That I know. A Guild Member has a presence. Makes sense. But what I can't understand is why GUILD_MEMBER_UPDATE, as an example, depends on a Guild Member's presence. They aren't tied together AT ALL in WS events, so clearly the separation can or has been done... I hope we can get an answer for this, as I am pretty curious, and I'm sure some others are too! |
|
The fact that all of those events got wiped together makes sense given how Discord is internally designed. Fundamentally, each guild is on Discord a worker, meaning it is an independent process handling tasks related to guilds. According to the field name and what the feature does I believe that this is the worker responsible of that feature, so it makes sense for those to also get included in the filter. (again, according to how I understand Discord backend) Also, given the fact that this feature aims to make bot entirely stateless that only reacts to users commands, giving those event seem pretty useless. But even if the point is to make bots stateless, I think it might be too strict for some bots that doesn't store much data but need at least live updates (see: modbots). Something between receiving everything and nothing would be ideal for a way bigger part of bots living on Discord. |
|
@night So why won't you just disable PRESENCE_UPDATE and TYPING_START events so this can benefit many more of us? Member events are a necessity for so many of us. |
Reaction add already doesn't behave as one would expect (#812) - why are we suggesting making more things rely on it is a good idea? |
My understanding of it is that a user's presence on a guild is composed of pretty much everything that we consider a user + member -- the username, avatar hash, discriminator, status, activity, roles, ... You can see changes to all of these in the |
All of those EXCEPT roles are parts of |
|
I might be misremembering, but I swear that I've seen member-related info in |
|
Oh.. interesting. I just noticed that
Nonetheless, I still hope we can get an update about this based on, well, the feedback dropped here 😅 |
This would fit, I think, because a user's presence is per-guild; adding/removing a user from a guild is inherently changing their presence on that guild. |
This includes - Server Boosting discord/discord-api-docs#960 - remove of _trace on Identify payload discord/discord-api-docs#967 - opt out for presence & typing events discord/discord-api-docs#1016
|
@night You said about how you will never implement event unsubscribing and should only ever use this guild subscription thing. But what if we want to retrieve other events but just specifically do not desire to retrieve the millions of presence updates that are sent to us. |
No description provided.