Talk:Message Queue Evaluation Notes
I think those are no valid numbers at all...
* online residents: ~68,000
You should always calculate with the maximum reached, which is about 86,000 currently. Sure there are bots, but who says those don't send/receive group messages?
* avg number of groups/resident: 9.3
Each person *I* know has the group number maxed. Probably you counted in the probably 9,000,000 dead/inactive members into that average number. Make it 20.
* average group size: 4.8
Who cares about the average group size? Group chat/messages/notices have to work for ALL groups, and the largest is well over 10,000 members now (Fashion Consolidated)
Silver Key 15:27, 1 April 2009 (UTC)
- We gathered that data a while ago, so every number is smaller than it is today. It should be made more clear that anyone viewing these numbers should extrapolate them out farther to account for growth since the time when they were gathered, and also to account for future growth. I don't think we should be continually re-gathering those numbers as concurrency grows ever-higher -- that would be expensive and wouldn't give any new information. The "avg number of groups/resident" is based on online members who were actively participating in group chat, not on the inactive users in the database. It's just memberships divided by concurrent residents (629637/68000). I agree with you that average group size is not nearly as relevant as the size of the largest group; it's included alongside the stdev for completeness' sake. In general, we should make the most pessimistic assumptions possible when evaluating software to solve long-term technical problems, and that's why we set the minimum bar for success at >4x the then-current load. Ideally we want much more than that, but, those criteria should at least separate the wheat from the chaff. So, I think I agree with you that the numbers are misleadingly low, but I want to be as honest as possible about what we know for sure to prevent ourselves from having the wrong expectations. For example, when we started the project we assumed that the message rate far outstripped the churn rate; and we were surprised by the incorrectness of that assumption. Which Linden 23:19, 1 April 2009 (UTC)
I am not very confident a "one-scheme-fits-all" will really be possible or desirable here, even if I understand the reasoning. In the case of XMPP, there are some benefits to it that extend far outside the stated goals.
- Extending the existing SL identity into the instant messaging space through XMPP gateways. A logged in resident able to send an XMPP message through the SL-to-ICQ,AOL,Yahoo,MSN,etc gateways, and people using those services able to message in-world residents? To me, a huge win. I could scrap pidgin.
- Group chats, notices, proposal voting - any fix, sooner rather than later, would be a huge win.
- Any of the *other* solutions being mentioned and tested on this page could ALSO be gatewayed to/from the XMPP servers in LL's net, too.
- Keep with IETF standard protocols rather than rollyourown over and over again.
So, yes... my idea for a strategy here is divide and conquer, subdivide and conquer completely. --Allen Kerensky 16:57, 12 April 2009 (UTC)
Regarding: XMPP - XMPP seems to not be the best fit for generic applications -- it seems that it could at best solve the group-chat and person-to-person IM cases, if at all.
- Person to person IM is the absolutely most important case. Exposing it in a well known public protocol would have orders of magnitude more benefit than anything else, even group chat.
- Linden Lab knows how important person-to-person IM is, or they wouldn't have privileged it over group chat with persistence or _already_ exported it in a limited way with "IM to email".
So, I'm 100% in agreement with Kerensky here. -- Argent Stonecutter 03:29, 28 February 2013 (PST)