Welcome to MSDN Blogs Sign in | Join | Help

"Concurrent" users

Very frequently I get requests asking "how many concurrent users does Team Foundation Server support"?
 
I really don't like this question.  What is a "concurrent user"?  In a stateless request/response web based application, there really is no such notion.  However enough people really want to know that I spent half the day Friday trying to figure it out.  I searched the web for hours looking for a definition of "concurrent" users.  Most of what I found related to systems that have explicit "log in" and "log out" actions.  We don't (and neither do most scalable web applications - google, ebay, MSN, etc).  There were some references that said any notion of "concurrent" users on a web application is a bogus notion.  Others tried to define it.  Those that did, defined it as a time window during which all users who accessed the server were counted as "concurrent".  I saw a range from 5 minutes to 6 hours and there didn't seem to be any pattern.
 
I decided to go a similar but slightly different route with my analysis of TFS.  What we did was take a week's worth of TFS dogfood trace data and break it up into 10 minute intervals.  We then looked at each 10 minute interval and counted how many unique users used the system in the interval.  We also counted the total number of requests in each 10 minute interval and divided the # of requests by the number of users and then divided by 600 (the number of seconds in 10 minutes) to get the number of requests per second per "concurrent user".  You could say that we used a 10 minute window but I believe that by dividing by the number of requests we have made the result less sensitive to the exact choice of the width of the window.
 
We found that, in our data, this number is 1 request per second per concurrent user.
 
I have previously gone through a similar set of math (see one of my earlier blog posts) that concluded that the peak RPS is 0.1 requests per second per team member (I defined team member as any one who used the server within a week).  This means that there is a 10 to 1 ratio of requests per second per concurrent user and peak requests per second per team member.
 
I'm going to continue to quote TFS scalability in team size because I think it is a much more appropriate (and measurable) metric.  However, if you (or your boss, customer, etc) really wants to know what the "concurrent" user support is, you can take the team size measures that I give and divide by 10.  That's how many "concurrent" users a given TFS hardware/software configuration will support (approximately).
 
As I've said a few times, we are soon going to be publishing revised team size scalability numbers for TFS.  Our goals for V1 were 500 users but we have found that the server does dramatically better than that.  I'm hoping to get those updated results out this month.
 
Brian
Published Saturday, December 03, 2005 4:10 PM by bharry

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# re: "Concurrent" users

Wouldn't a natural definition of "concurrent users" be: two (or more) users whose requests are running at the same time, i.e. such that the time when one of the requests releases its last resource is later than the time when another allocates its first?

Even if your architecture is stateless, the tasks still uses some time to complete. For instance, an SQL statement could be defined as stateless if it is not running in a transaction; yet it will not necessarily complete at once, thus the interest in "how many concurrent requests do you support".
Sunday, December 04, 2005 4:37 PM by Roland Kaufmann

# re: "Concurrent" users

In the purest sense of the word, you're absolutely right. However I've never seen anyone who does it that way. Further it would yield some pretty unusual results.

For example, we have a server that can process over 300 requests per second. Let's say the average requestion time is .05 seconds (I just made that up but it's probably close). That means that no more than 15 requests are ever actually executing at the same time. So even though you had 300 people (potentially) use the server in the same second, we'd be saying that the server only supported 15 concurrent users. That would be pretty misleading to a customer trying to plan how big of a server they need to support their 100 person team.

It's also made complicated because just having multple requests "processing" at the same time doesn't mean that the server is delivering adequate response time for those requests. For example, a server that took a lot of requests and simply queued them but took a long time to respond may actually appear to support more users when, in fact, a server that processed a whole lot of requests and responded quickly so that very few overlap would appear to support very few users.

Brian
Monday, December 05, 2005 7:55 AM by bharry

# re: "Concurrent" users

When I did stress testing on an app a few years back, we were interested in both how many requests per second it could handle, and how long each request took ("turnaround time" I think we called it).

We had a hard max on the latter, and various goals of the former for a given CPU load. We simulated it by having "generators" spitting out requests, and added generators as needed (each generator had its own max throughput). So, we ended up with a similar set of data and (again) no clear picture of what "concurrent" means - we'd ask ourselves how many requests were in the queue, but it just wasn't interesting - if we were keeping up, it was 0, if we weren't, it was growing over time until we'd have to throttle back or start dropping requests.

Anyway - it seems to me is that you could look at a concurrent user similarly to the 'generator' we used. If you can simulate a typical user's request rate/request patterns (and I think we do this), the concurrent question might be answered by asking "how many 'simulated users' can we have hitting the system at once for a given amount of [CPU util/Network Bandwith/Request Latency" (and of course until 'something breaks'). The difference between a 'generator' and a real user is that each generator represents a person using the system 24/7, instead of periodically, but that's exactly the abstraction we're interested in, I think.

That's a different number than the "500" we've been talking about for v1, I think, isn't it? A team with 500 people is a lot different than 500 users actively using the system at a given moment in time.
Monday, December 05, 2005 4:57 PM by CRathjen

# Managing Quality (part 3) - Performance Testing

If you read my blog much, then you know performance and scale are near and dear to my heart. If you read

Tuesday, February 06, 2007 10:36 AM by bharry's WebLog

# re: "Concurrent" users

You don't like that question?

Mmmh, you must be working for Microsoft....

Monday, April 02, 2007 3:48 PM by Bas

# re: "Concurrent" users

what people are asking is a very simple explanation of what is a concurrent user as lets see maybe a user?

such as I ran in a winXP os that said +1 concurrent user I am just trying to figure it out and see if that means it can be installed on 2 pc's or only one

kenneth_skelton_sr@yahoo.com

Friday, March 14, 2008 10:01 AM by kenneth skelton

# re: "Concurrent" users

what people are asking is a very simple explanation of what is a concurrent user as lets see maybe a user?

such as I ran in a winXP os that said +1 concurrent user I am just trying to figure it out and see if that means it can be installed on 2 pc's or only one

kenneth_skelton_sr@yahoo.com

Friday, March 14, 2008 10:02 AM by kenneth skelton

# re: "Concurrent" users

I think Concurrent is very important !

Example,

Our engineer is training custom . When he operate on login,customs also do this . Then ,our system breakdown.

This is course by Concurrent ...

Wednesday, October 01, 2008 3:37 AM by higkoo

Leave a Comment

(required) 
required 
(required) 

  
Enter Code Here: Required
 
Page view tracker