Recently, I’ve been asked a lot of questions about what Second Life’s user-concurrency actually means, and what factors influence it. It is, at once, a quite simple and yet rather intricate metric.

At its simplest, user-concurrency is simply the number of user-accounts logged in at any given tick of the clock, representing total usage of the service at that instant. This number currently swings between roughly 32,000 and about 70,000 during the course of a day.

Individual days may be more or less than that – traditionally, concurrency would peak in the early afternoon on a Tuesday, and be at its lowest on a weekend, but over the last couple of years mid-afternoon Monday has become the busier period, and weekend usage has boosted, while weekday usage has declined.

User-concurrency usually represents an unpredictable fraction of total daily usage – but it’s an important fraction!

The key factors that affect user-concurrency are: total users logging in during that day, the median length of a session, and temporal clustering.

Temporal clustering refers to the likelihood of users to log in at certain times of day (eg. Lunchtimes, evenings, after getting home from work, early in the morning and so on). Everyone has their own availabilities, but these tend to cluster together, because people in each time-zone tend towards certain commonalities.

Let’s look at how clustering and session length affect concurrency.

Let’s assume that there’s 24 users, and that there’s no clustering. Each user logs in about an hour apart (the first one at Midnight, the next at 1am, then 2am and so on). Each user is logged in for 30 minutes (that’s the session length).

From Midnight to 12:30AM, the concurrency will be 1, then zero until 1am, where it becomes 1 again, until 1:30 and so on. Simple enough.

If each user is logged on for exactly one hour, concurrency will remain at 1 through the whole day – exactly 1/24th of the total logons.

If the session length is 90 minutes, then the concurrency will be one or two (2 for the first half of each hour, as two users will be logged in at once).

Of course, people logging in at evenly spaced intervals doesn’t happen in practice. In Second Life, within any five minute period, dozens of users will be logging in or out. The net gain or net loss during those five minutes results in a new concurrency value that is higher or lower than the last.

How do alts or bots affect concurrency?

Well, not much. A bot is a single login session, and thus counts like any other single user for the time that it is logged into Second Life. Given the scale of concurrency we’re talking about here, you’d need hundreds or thousands of bots to make a large impact in user-concurrency.

As for alts, well, they generally impact things even less. A user who logs in on one account, then logs out and logs in on another is never contributing more than one point of concurrency, no matter how many alts they serially cycle through. In order to make a larger impact than that, the user must have more than one account logged in at the same time.

In order to boost concurrency by just 1% you’d need about seven hundred users each having a second (alt) account logged in at the same times as their regular account. Ditto for bots.

So, why does concurrency decline?

Well, three factors can influence that. One is less temporal clustering (that is users are less likely to log in at the same time of day as their peers). Given the shapes of the concurrency graphs have remained relatively stable over time, this is not likely to be a significant factor in the current decline.

The second (and perhaps overly obvious) factor would be fewer users logging in each day.

The third (and in my opinion, the most likely) factor is that session lengths are getting shorter. That is, users are spending less time logged into Second Life, on average, than they used to. Even a small decline in median session-lengths can have a noticeable impact in user-concurrency, and that is – I believe – what has been taking place these last two years.

Why has Second Life user-concurrency been declining lately?

Insufficient data is published to allow us to determine exactly which of these three factors (or a combination of them) is contributing to the current decline.

There’s no sudden crash in usage, nor any sign of a precipitous decline. It would actually be more comforting if there were, because that would mean that there was something simple and obvious that you could point to as a primary cause.

Such crashes in concurrency are common when certain kinds of problems arise on the grid, from login problems to failures in inventory or utility servers. By watching the pattern of such sudden declines you can diagnose what sort of problem is causing them.

There’s no such simplistic signs here. What we have is a small, but persistent decline that does not indicate any single clear and obvious cause. You, me, Linden Lab, and everyone else … well, we’ve all got our own opinions and hypotheses, but the fact is that none of us actually know why this is happening.

All we have is guesswork – though granted, the Lab’s guesswork is backed up with more figures than are available to the rest of us, but that doesn’t mean that their guesswork is necessarily any more or less accurate.

Likely there are dozens of issues contributing to the overall lengthy decline. It’s temptingly easy to focus on one or two or five of them – but realistically speaking, every one of them is playing their part, and contributing to the overall reduction in usage that is indicated by user-concurrency.

Tags: , , , ,



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