• About us…

  • The archives

  • RSS The Gaming Session

  •  Better and faster with IPv6

  • ipv6 ready

Peak time in Second Life

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.

Tags: , , , , , , ,

Got a news tip or a press-release? Send it to [email protected].
Read previous post: