There’s an idea I’d like to convey here. I’ll form it into a sentence and you can say it with me:
“Peak concurrency varies independently of actual total usage”
Got that? Good. Now a little detail…
Given the same number of users, logging in for the same amounts of time during the day, totalling the same number of people, hours, minutes, seconds, and microseconds of actual usage, it is not unreasonable for peak concurrency to shift by as much as 25%.
Peak times happen partly because we’re creatures of habit, but also because we’re creatures of circumstance and opportunity, and it is the latter that causes the shifts in peak concurrency.
Basically, the daily peak is caused by lots of people being logged in at the same time – being logged in at the same time is what user concurrency actually is. It peaks, when the most people are logged on simultaneously. That’s often at a particular time of day, when more of us have the opportunity to do so.
That might be over lunch, or it might be after work, or it might be after the kids are tucked away in bed or when the majority of our friends are online, or when a particular event or meeting is on.
It’s those circumstances which guide the clustering behaviour responsible for the daily pattern of concurrency. However, imagine that you’ve got fewer constraints on your time for some reason – a vacation, or a change in day-care, or a long-weekend, or a thousand other things. You might not spend any more time in Second Life, but you might do it at a different time of day.
That means your usage might not contribute to the usual peak. Hundreds, thousands, or even tens-of-thousands of other users have their various circumstances and opportunities. The premiere showing of a new motion picture at the cinema might suddenly spread out the times at which various users log in during a given day (or across a week or more). The overall usage may remain the same, but the peak drops and the curves look much less steep.
This sort of thing makes a mess of averages (that is to say, of arithmetic means), which are not a robust statistic and looking at peaks and arithmetic means is a but of a mug’s-game if what you’re interested in is actual trends in usage. For concurrency, the median value of the daily concurrency set – while more intensive sort of statistic to calculate prior to the advent of computers – provides a much more robust and meaningful usage value.
Which, in case you were wondering, is why I use it. I’ve written about means and medians (and modes) before, and you might want to take a look at that, if you’re curious as to how they’re calculated, how they can go wrong, or can’t recall what you learned about them in school.
Why is everyone so focused on peak concurrency then? Well, in some services, peak concurrency is the only published figure available, because that’s the number that causes the service to lag and/or servers to crash – or is the figure that the service provider is proudest of (a large number of simultaneous users without the service collapsing is a good thing). Otherwise, it’s just laziness, I suppose, or a lack of understanding of the arithmetic we all theoretically got in elementary school.
Nevertheless, the thing to remember is: “Peak concurrency varies independently of actual total usage”
And we’re done.
If you smooth out the peak concurrency over time, does it show any relation to the actual total usage?
You cannot, alas, derive total usage from concurrency. All you can see are trends in usage from the concurrency medians.
An average total usage indicator would be something like the total number of unique log-ins a month set into relation to the total time unique users spent online a month, right?
Nevertheless concurrency medians aren´t that bad as an indicator.
Yes, ideally you’d want unique monthly users, median session length, total user hours and concurrency. Between the four figures, that would give you a pretty comprehensive picture that you could slice several ways.
I agree Tateru, statistically peak usage is pretty useless. It’s twin sister concurrency (users on line at any given time) used to be very important, much above 70,000 and things stopped working. I suspect if we ever get back near 88,092 which is the highest I have ever recorded, we will see the return of performance issues associated with concurrency. I will keep my SL Population Meter active, and stop building when population gets high.
Well, it doesn’t seem that long ago to me that everyone knew that the grid melted down at 5,000 concurrent users. Or 10,000 or 20,000. Because it did… but the capacity of the grid kept being improved.
I agree. Lindens improved overall capacity. As they improved the “sim entry with 500 resizer scripts attached lag” lately (tho it´s impossible for them to fix this kind of user habit), and region border crossings as well as overall sim performance obviously have become fairly better. 50,000 simultaniously logged in users (which is average nowadays) would have caused a global crash in 2006/07 – and two days closure for fixing it. So, if one of their main problems is “the not-returning newbie” this is progress – back in the old days the question was :”Can i log in AT ALL?”.
With the data LL is currently publishing, very little of any consequence can be said. It’s sad that users are providing more useful data (e.g., region changes) than LL. Especially since they used to publish some pretty good metrics.
I find myself wondering how the peak figure relates to the number of regions.
@Wolf There’s a relationship – but it is a complex and unpredictable one in which the number of regions is probably one of the least important terms in the equation.