How do I? – Calculate the number of SharePoint Web Front End servers I need.

I am going to take you through my journey for Capacity Planning in this entry. Given the topic, this will be quite a lengthy post so if you're really in a big hurry and don't care to understand the intricate details of the capacity planning equation you could just skip this article and go directly to the link for SPCAP – SharePoint Capacity Planning Tool. Now as any seasoned SharePoint Architect would tell you, one of the key components to planning your SharePoint deployment, is Capacity Planning. Unfortunately, Capacity Planning is such a confusing topic and there's not a whole lot of really good documentation around it. What is available can be confusing to say the least. In addition, there are so many factors that affect your planning in this area that it is almost impossible for anyone to come up with a solid number. Your performance would be affected by the server hardware, the client hardware, the concurrency rate of your users, the throughput rate required, the response time your organization deems acceptable etc. These are just the factors that we actually CAN calculate into our formulae. Additionally, your general network load and other factors that could cause interference with your expected performance will from time to time wreck havoc with your stats, but for the most part we can make a good judgment call as to the type of farm setup that would be required in most cases. I STRONGLY recommend that you at least try and read the Capacity Planning Guide on TechNet, found here: http://technet2.microsoft.com/Office/en-us/library/eb2493e8-e498-462a-ab5d-1b779529dc471033.mspx?mfr=true Now once you read this, you may come away with a clear understanding of your capacity needs, but if you're like most of us, me included, you'll come way from this even more confused than before. So why did I recommend you read it? Because I do not want you to blindly rely on my formulae as the golden rule for capacity planning. My formulae generally are on the conservative side. For example, instead of using the "Read" transaction numbers in my calculations, I use the "Mixed" numbers which is about half as much and as a result, my formulae would recommend you into a 2x1 farm long before a calculation done using the "Read" numbers. Of course, I believe that, especially on an Intranet scenario, transactions will in fact be "Mixed" rather than "Read". On an Internet scenario, the "Read" numbers would in most cases be accurate, but by playing it safe, the formulae would rather give you too much horsepower than too little. Now on to the guide… When you get to the "Estimate performance and capacity requirements…" section you'll note firstly the hardware recommendations. As you can see, the server setup that was used to provide us with actual transaction throughput benchmarks are all 64 bit servers. As a result, their performance is going to be far superior to 32 bit servers so if you're deploying 32 bit servers, be aware of this as everything is subject to the hardware specified in the guide. We find the recommended hardware being: WFE Server - 2 x Dual Core Intel Xeon 2.8 GHz CPU, 4 GB RAM, 64 bit SQL Server - 4 x Dual Core Intel Xeon 2.8 GHz CPU, 32 GB RAM, 64 bit Client PC - 1 x Pentium 3 1.2 GHz CPU, 1 GB RAM, 32 bit Note the massive amount of memory in the SQL Server. If you server has less memory, be aware that it will impact your performance. Next you'll find a section on "Usage profile" which is really not relevant to our calculations but is only intended to provide you some perspective on the test environment from which the statistics was drawn. Go ahead and skip by this section. Next you'll find a section on "Hardware recommendations". This is really confusing for many because we now have two sets of hardware specs on the same page. All this section is doing is to list the recommended specs for your SharePoint farm even though the test environment hardware was vastly superior. Go ahead and skip by this section. The "Estimating throughput targets" section provides you a description of how to estimate your required throughput. What makes this section confusing is the fact that it contains references to both Requests per Second as well as Requests per Hour. The important section here is the Analyzing Log Files (IIS 6.0) section which will help you analyze your current SharePoint 2003 traffic and determine the targets you need. The "Estimate throughput targets" section is an important section for us because it contains the performance matrix that we will use as the basis of our formulae in calculating our farm requirement. We're only really interested in the first two columns noting the farm configuration in the first and the Requests per Second in the second column. These are the base numbers we use in our formulae. Given the drop off in performance beyond a 5x1 configuration, we don't even consider anything beyond that. In the "Estimate user response time" section the important thing to note is the three levels of response time i.e. 3-5 seconds, 1-2 seconds and sub 1 second response time that are available. There's a grid that attempts to draw the throughput and response times together, but it just confuses most people. Just note the response time options for now. In the "Estimate concurrency rate" section, the really tricky question comes up. How many users are using the system at the same time? We have to estimate this unless you have some cool tools that does stats analysis that can actually give you the numbers, but generally using a 10% concurrency rate is a good rule of thumb. The subsequent sections talk about the indexing window, disk space requirements and performance monitoring. You can skip over this at this point. OK, so we've got all this data. Now how do we convert it into useful information i.e. a server farm requirement number? This is where I had to dust of the good old high school algebra. The first principle in calculating algebraic formulae is to get everything into a consistent unit of measure i.e. compare apples to apples not oranges. We begin with the Estimated Throughput Target (ETT) which is simply a question of how heavily your users use the environment. ETT is usually expressed in Requests per Hour (RPH) and is based on a Throughput Concurrency Rate (TCR). As we mentioned, a TCR of 10% is a good rule of thumb value to use. Based on a TCR of 10%, usage levels are defined as follows: Light usage = 20 RPH Typical usage = 36 RPH Heavy usage = 60 RPH Extreme usage = 120 RPH Taking the Farm Throughput Capacity (FTC) grid we have a RPS value for each farm configuration. Apples to apples remember? So we need to multiply that number by 3,600 to get it into a RPH number that we can use with our existing ETT values. Doing that we get: 1x1 = 180,000 RPH 2x1 = 356,400 RPH 3x1 = 414,000 RPH 4x1 = 432,000 RPH 5x1 = 489,600 RPH Now we take the Estimate Response Time (ERT) values grid. If we use the 1,000 user line as our benchmark we take the 0.7 RPS, multiply it by 3,600 seconds in an hour and divide it by 1,000 users and we'd get a RPH value per user. We do the same for all three response time levels and we get: Slow = 3-5 seconds, server target = 2.52 RPH per user Recommended = 1-2 seconds, server target = 3.6 RPH per user Fast = <1 -----------------------="ERT" ---="-------------------" 1000="1000" 100="100" 1="1" 1x1="1x1" 2000="2000" 20="20" 25="25" a="a" accurate.="accurate." actively="actively" adjusted="adjusted" affecting="affecting" all="all" also="also" an="an" and="and" application="application" are="are" as="as" avoid="avoid" back="back" be="be" but="but" by="by" c="c" call="call" can="can" capacity="capacity" concurrency.="concurrency." concurrency="concurrency" concurrent="concurrent" configuration="configuration" count="count" created="created" data="data" day.="day." determine="determine" determines="determines" div="div" divided="divided" do="do" don="don" during="during" each="each" easier="easier" else="else" equal="equal" equation.="equation." equation="equation" ert="ert" estimated="estimated" everyone="everyone" example="example" farm.="farm." farm="farm" feedback="feedback" final="final" for="for" formulae="formulae" ftc="108,000" get="get" guide="guide" handled="handled" have="have" heavy="heavy" here.="here." hours="hours" i.e.="i.e." i="i" if="if" in="in" indexed="indexed" indexing="indexing" input="input" into="into" is="is" it="it" keep="keep" know="know" lastly="lastly" later="later" leave="leave" lot="lot" make="make" match="match" matrix="matrix" mentions="mentions" mistake="mistake" must="must" need.="need." need="need" no="no" normal="normal" not="not" now="now" number="number" of="of" off="off" ok="ok" on="on" order="order" our="our" per="per" performance="performance" planning="planning" prompts="prompts" proportionate="proportionate" put="put" question="question" quick="quick" rate="rate" re="re" represented="represented" require="require" requiring="requiring" response="response" rph="rph" s="s" same.="same." same="same" save="save" scenario="scenario" second="second" sers="sers" server="server" sharepoint="sharepoint" since="since" so="so" solve="solve" spcap.="spcap." spcap="spcap" statistics="statistics" stats="stats" style="background-color: white; border: 0px; margin: 0px; padding: 0px; vertical-align: baseline;" substituting="substituting" system="system" t="t" table="table" target="target" tcr="tcr" that="that" the="the" then="then" they="they" thing="thing" this="this" throughput="throughput" thus:="thus:" time="time" times="times" to="to" tool="tool" translates="translates" try="try" trying="trying" uc="uc" under="under" up="up" usage="usage" user="user" users="users" using="using" value="value" values="values" volume="volume" we="we" web="web" what="what" when="when" which="which" whole="whole" will="will" window="window" with="with" would="would" you.="you." you="you" your="your">