SharePoint Visitors, Tubes passengers and Angry Villa Fans

How To Calculate How Many?

As promised in last week’s SharePoint Blog this week I am going to talk about Capacity Planning and how to calculate the approximate number of Requests Per Second your SharePoint Server will get.

I am going to explain the formula for calculating the Requests Per Seconds which is recommended for SharePoint.

(Number of users x % users active per day) x Number of requests per active user per day x peak factor
______________________________________________________________________________

360 000 x working hours per day

  

But what does it really mean! To help explain the different parts of the complex looking calculation I am going to use two real-life examples that have got me thinking during the last few days.

The first real-life example hit me on Tuesday evening when I was wedged between a smelly armpit of a long-haired youth and a business man with a rather large brief case on the Northern Line travelling back to Euston Station.  With my SharePoint hat on I considered if Transport London had used a similar calculation, to the one above, to see if the number of trains could cope with the number of commuters especially at peak times.

Secondly, you might have noticed in the news that many Villa fans are not happy that former Blues manager Alex McLeish (the legend who got the Blues Noses relegated twice) looks set to be named the new manager of the mighty Aston Villa. While many fans protested yesterday I queued up the purchase my season ticket in the Trinity Road for the 31^st consecutive year. So as I waited behind the only other person waiting at the Villa Ticket Office I was thinking how the appointment of Mr. McLeish would affect the number of tickets the Villa Ticket Office would have to sell in the new season.

1. Number of Users x % Users Active Per Day

So how does the calculation work? The first part is the number of users multiplied by the % Users Active per day.

Often when trying to calculate worse case scenarios for SharePoint it is best to use 100% for this figure. Also it makes it easier for the less gifted mathematicians.

With the underground the number of users would probably be how many people are usually in London (residents, tourists and workers) times by the percentage Active Users. The Active Users being those able to use the Underground. It is not really the place for very young children and I expect quite scary if you are blind and have a Guide Dog. Apparently around 11 million people are in London on a normal week day. So if 80% of them are capable of using the underground that would be 11000000 x 80 which is 880000000.

Back at Villa Park the calculation would be the number of Villa fans Worldwide times the percentage of active ones. The active ones are those that do attend Villa games. If we say there are one million worldwide Villa fans and maybe 20% of these attend matches then the first part of the calculation would be 1000000 x 20 which is 20000000.

2. Number of Active Requests per Active User per Day

The next part of the calculation is the number of active requests per active user per day. To help us Microsoft produced a common set of figures for users of SharePoint 2010. It describes frequency of use and a requests/second (RPS) to users ratio for each. These user figures are;

• Light user, access every 180 seconds (20/hr)
• Typical user, access every 100 seconds (36/hr)
• Heavy user, access every 60 seconds (60/hr)
• Extreme user, access every 30 seconds (120/hr)

So if you have 100 SharePoint Users and let’s say that 80 of them are ‘Light Users’ and 20 are ‘Extreme Users’ then all we need to know is numbers of hours they work in a day to find the ‘number of active requests per active user per day’.

If the usual working day is 10 hours (well we need to make them work) then the calculation is as follows;

i) Light Users :  80 x 20 x 10 = 16000 (Requests per Day)

[20 is from Microsoft’s set of figures for number of requests per hour for a Light User]

ii) Extreme Users : 20 x 120 x 10 = 24000 (Requests per Day)

We then add the Light Users and Extreme Users together to get the overall total Requests per Day;

iii) 16000 + 24000 = 40000 (Requests per Day)

As we have overall 100 users (simple for Maths again) we divide the total Requests per Day by 100 to get the ‘number of active requests per active user per day’.

iv) 40000 / 100 = 400 (Active Requests per Active User per Day)

Back in the Underground maybe the Tube Bigwigs have their own definitions to help calculate number of travellers a day. Maybe it is similar to the following;

Light User – Use Tube once every 10 days (0.1/days)

Typical User – Use Tube to go to and from work every day (2/days)

Heavy User – Use Tube for several journeys every day (5/days)

Extreme User – Always on the Tube (20/days)

So assuming that the 11000000 people in London are broken down as follows;

6000000 Light Users, 3000000 Typical Users, 1000000 Heavy Users and 1000000 Extreme Users.

Then the number of users per day is;

i) (6000000 x 0.1)+(3000000 x 2)+(100000 x 5) + (1000000 x 20) = 27600000 Journeys Per Day

We can then divide it by the total number of people in London to give the ‘Active Requests per Active User per Day’;

  

In the claret and blue world it might work as follows;

Light User – A fan who goes a couple of times a season for special occasions (0.01/days)

Typical User – A fair weather fan who goes to the big games (0.05/days)

Heavy User – A real fan who goes to virtually every home game even the one against Wigan (0.8/days)

Extreme User – Goes to every single game even the reserves (0.1/days)

So assuming that the 1000000 Villa fans are broken down as follows;

950000 Light Users, 25000 Typical Users, 15000 Heavy Users and 10000 Extreme Users.

Then the number of users per day is;

i) (950000 x 0.01)+(25000 x 0.05)+(15000 x 0.8) + (1000 x 0.1) = 21725 Tickets Per Day

We can then divide it by the total number of Villa fans to give the ‘Active Requests per Active User per Day’;

ii) 21725 / 1000000 = 0.021725 (Active Requests per Active User per Day). Meaning that the average number of tickets per Villa fan buys per day is about a fiftieth of a ticket. Maybe this example is not going to quite work out.  

3. Peak Factor

Peak Factor isn’t an old daytime soap opera but a value between 1 and 4 that indicates how long Peak Times lasts. If it was always Peak Time then the value would be 4, but for SharePoint Capacity Planning I usually use a value of 2.

With the London Underground probably Peak Hours are 8am to 10am and 4pm to 6pm. So as this is only 4 hours of the day we could use a Peak Factor of 2 as well.

Back in Aston the Peak Factor might be influenced by league position or manager. Maybe after the poor season last year and the possible negative feeling towards  a new manager we might settle for a Peak Factor of 1.

4. 360,000 x Working Hours Per Day

Nearly there, hope you are following this. We are trying to calculate the Requests per Second (RPS) so we take number of seconds in an hour. From a good clock not the one in my car which keeps gaining one minute every couple of days. There are 3600 seconds in an hour and as we used a percentage in stage 1 we times it by 100 to give 360000 (I sound like Johnny Ball with all this Maths).

Now we just multiply the 360000 by the number of hours in working day. So if SharePoint users work 10 hours then that is 3600000 for the number at the bottom of our big calculation.

It doesn’t matter if it is SharePoint Users, Tube Passengers or Disgruntled Villa Fans we still divide by 3600000.

5. The Final Calculation

Let’s remind ourselves of the calculation we now have all the parts to complete

(Number of users x % users active per day) x Number of requests per active user per day x peak factor 

______________________________________________________________________________

360 000 x working hours per day

So for SharePoint we used the following information;

a) 100 Users

b) 100% Active

c) 80 Light Users + 20 Extreme Users

d) 10 Hours a day are worked

e) Peak Factor of 2

This gives us :

(10000 x 400 x 2) / (360000 x 10) = 2.22 Requests Per Second

Just for fun let’s look at the Tube and Villa tickets. Don’t forget these are my figures and are totally fictional.

Starting with the Tube we used the following;

a) 11000000 people in London

b) 80% Active Users

c)  6000000 Light Users

d) 3000000 Typical Users

e) 1000000 Heavy Users

f) 1000000 Extreme Users

g) Trains run for 20 hours a day

h) Peak Factor 2

Which gives;

(88000000 x 2.51 x 2) / (360000 x 20) = 61.36 Travels Per Second

No wonder I didn’t get a seat and ended up re-enacting a Right Guard advert.

So to the mighty Aston Villa FC then where we used the following;

a) 1000000 supporters

b) 20% Active

c) 950000 Light Users

d) 25000 Typical Users

e) 15000 Heavy Users

f) 10000 Extreme Users.

g) Ticket Office open 8 hours a day

h) Peak Factor 1

Which gives;

(20000000 x 0.021725 x 1) / (360000 x 8) = 0.15 Tickets sold Per Second

As the Villa start to win next season maybe the Peak Factor will improve and that will dramatically increase the number of tickets sold a second.

Whoever is manager of Aston Villa next season they will be certain of one thing and that is the full support of this SharePoint Blogger.

The SharePoint Consultants at Office Talk are happy to provide Capacity Planning and Load Testing for any SharePoint environment be it 2007 or 2010. Just drop an email to marketing@office-talk.com

SharePoint Remote Locations - Don't Lose Your Sausage

Over the last few weeks I have been working closely with a multi-national company to Load Test their new SharePoint 2010 environment. To test that having the SharePoint Server Farm in one physical location can provide a fast and reliable worldwide solution.

Even though I have been testing connectivity from exotic locations such as Sidney, Dubai and Bangkok I have spent all my time during the testing period in the UK. This has meant staying a number of nights at a popular brand of hotels where Lenny Henry probably gets a discount.

One of my favourite parts of hotel stays is always the breakfast. At home I never feel like breakfast before leaving for work but when working away suddenly my morning appetite becomes huge. Now we have the popular buffet style breakfast I seem to eat even more. It is great because within seconds of sitting down you can be eating. A choice of cereals, cooked English breakfast, pancakes, toast, fruit even cakes are on offer. It really is a case of how much you can eat in ten minutes before you have to leave for work. Oh, and avoiding anything that might possibly stain your white shirt.

It is important where your table is in relation to the food and this made me think about where you position your SharePoint Servers. I started to think more about the comparison when on my return to my table after my second visit to the buffet table (well, I was planning to work through lunch) that I tripped on a step and sadly my crispy sausage rolled off my plate and onto the carpet. It continued to roll until it came to rest under a table where another suited business man was seated. Luckily nobody had noticed so I continued my walk to my table leaving my sausage behind. I felt that returning for another sausage would delay my progress so just ate my bacon, scrambled egg (less messy than fried), fried bread and mushroom disappointed that my sausage had not made it. In much the same way during my testing some page requests in SharePoint had not made it in there journey across the Atlantic.

When planning a breakfast buffet you need to think carefully where you position the different parts of the buffet. You need to think first of all about filling the buffet tables. It would be silly to put it miles from the kitchen as it has to be managed and maintained. With the SharePoint servers (Web Front Ends, Application Servers, SQL Servers) these need to ideally be in a location where you have IT staff who can work on them and a location where they can be backed-up. Also with the breakfast buffet it makes sense to put them quite near to the largest amount of diners. The further you have to walk with your hot food the higher the chance of it going cold or you losing your sausage. Also the more people have to walk with the food the more traffic there will be especially at peak times (for breakfast probably 7-30am to 8-15am). The more people moving around the more chance of collisions and dropped packages of cereals. With SharePoint again the servers should whenever possible be located where the highest amount of users are so that requests don't have so far to travel and bottlenecks are not created causing bandwidth issues. Calls to the SQL servers from the Web Front End servers are high with SharePoint so always have these in the same LAN.

It is difficult to know what kind of food a guest will want from the breakfast buffet, but if we did we could possibly position them better. For example, if we had a group of vegetarians you could seat them furthest from the sausages, bacon and black pudding. Maybe put them nearer the muesli. The waiter seating breakfast diners might perhaps look at the size of the guests and then put the slightly fatter ones (like me) nearer the breakfast buffet because they might be more likely to eat more. Also it is better to have skinny people walking around a lot than fatter ones as they take up less room. Again with SharePoint the smaller the size of requests the better. So if you have a large image file you really want to make sure it is cached somewhere and not being retrieved every time. With SharePoint there are different options to cache data. One of these is the Blob Cache which is not turned on by default. When enabled Blob Cache lets you store cached copies of certain file types.

With transporting breakfast items wouldn't it be great if you could make the food items 90% smaller to help you transport them. It sounds like something out of 'Dr Who' but there are hardware solutions available that can do exactly this with SharePoint and other network traffic. Products like Steelhead from Riverbed can dramatically decrease SharePoint traffic with files compressed by a staggering 95%.

Talking of things shrinking by 90% that does seem to have happened to Aston Villa's local rivals Birmingham City hopes this week. From the high of winning their first cup and thinking they are about to become the Kings of Birmingham to a championship side in less than three months. Good luck Blues in your games against the NPower League next season. I am sure you'll get to play the Villa again one day.

In next week's Blog I will talk about Load Testing and how to calculate the number of Requests Per Second your SharePoint system will experience in Peak Hours.


If you require any help Load Testing or Capacity Planning for SharePoint then just ask for an Office Talk consultant by emailing Frank at frank.faulds@office-talk.com.