Difference between revisions of "Talk:Message Queue Evaluation Notes"
Jump to navigation
Jump to search
Silver Key (talk | contribs) (some comments about the numbers given) |
Which Linden (talk | contribs) (Replying about the numbers) |
||
| Line 14: | Line 14: | ||
[[User:Silver Key|Silver Key]] 15:27, 1 April 2009 (UTC) | [[User:Silver Key|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. [[User:Which Linden|Which Linden]] 23:19, 1 April 2009 (UTC) | |||
Revision as of 16:19, 1 April 2009
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)