FORM-2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
PROVISIONAL SPECIFICATION
(See section 10; rule 13)


CAPACITY PLANNING TOOL

TATA CONSULTANCY SERVICES LTD.,
an Indian Company
of Nirmal Building, 9th floor, Nariman Point, Mumbai 400 021,
Maharashtra, India;
THE FOLLOWING SPECIFICATION DESCRIBES THE INVENTION


FIELD OF THE INVENTION
The present invention is related to the field of capacity planning.
Particularly, the present invention relates to a tool for sizing hardware capacity for the Web/Application Servers required for hosting ASP.NET applications.
BACKGROUND OF THE INVENTION AND PRIOR ART
Typically, when designing a web application, development teams have to keep in mind that hundreds of thousands of users can concurrently access the application in production. This concurrent user load can place tremendous stress upon a system, causing unexpected delays in application response, and thereby resulting in a poor user experience.
Inadequate hardware sizing is one of the prime reasons for a web application to perform poorly. Applications designed with highly scalable architecture and all best practices for development also can perform poorly if the capacity planning for the hardware which hosts the application has not been performed adequately.
Moreover, IT Systems Integrators are required to budget the cost of hardware resources for the project well in advance before development, at the Pre Bid Stage or RFP (Request for Proposal) stage.
There is therefore a need to perform hardware sizing for ASP.NET based web applications. The sizing is typically done based on Tiered architecture with the Web Server and Application server deployed on the same server and Database deployed on separate server. The methodology can also be extended to applications deployed on N tier architectures. The typical deployment architecture


of ASP.NET applications that can be sized has been shown in Figure 1 of the
accompanying drawings.
TCA (Transaction Cost Analysis) is a typical sizing methodology that can be used for modeling Web/Application server performances. TCA is a good approach towards profiling a web application based on its workload profile, identifying the most viewed pages and then predicting the Web/Application Server sizing based on the performance of those pages under user load. There is a proportional relationship between website throughput and user load in TCA based analysis.
TCA allows calculation of cost of transactions of a web application profile by simulating client transactions on the host server. It can determine the resource utilization under varying user load by varying the user transaction rate. Usage profile can be designed to capture anticipated user behaviour. This usage profile can be used to determine the throughput target and other important transaction parameters from which resource utilization and capacity requirements are derived.
Typically, TCA can be used to measure the cost of individual shopper operations on an E-Commerce site, such as registering on the site, browsing items, searching items, and adding an item to the shopping cart, checking out, and the like. The capacity of a typical E-Commerce site can be determined by consolidating the costs of individual shopper operations and then converting this cost into the total resources required by the server. Transaction Cost Analysis typically comprises the following:
• Compiling a User Profile
• Measuring the Cost of Each Operation
• Estimating the Site Capacity

• Calculating the Site Capacity
• Verifying the Site Capacity
One major shortcoming which TCA suffers is that it can be applied only to a developed site and when the most common user profile is known.
For a situation when sizing has to be done before hand at project planning stage or RFP stage, TCA can't be applied in its present form. To overcome this shortcoming there is a need for sizing analysis at the RFP stage itself.
The invention envisages a performance model and hardware sizing methodology, based on which projects can perform capacity planning for their application needs. The sizing model is applicable for web server and this sizing methodology can be applied to applications at RFP stage.
OBJECTS OF THE INVENTION
It is an object of the present invention to provide a capacity planning and sizing tool.
It is another object of the present invention to provide a tool for calculating the hardware sizing based on the web application's needs.
It is still another object of the present invention to provide a user-friendly, portable and scalable ASP.NET based web application or a MS Excel based tool for capacity planning and sizing.
It is still another object of the present invention to provide a tool for calculating hardware sizing of applications at request for proposal (RFP) stage as well as developed web servers.


It is still another object of the present invention to provide a tool for calculating hardware sizing based on cost per operation approach,
It is still another object of the present invention to provide a tool for capacity planning of new applications when workload and the technical architecture are the only details available.
BRIEF DESCRIPTION OF ACCOMPANYING DRAWINGS
The capacity planning tool, in accordance with the preferred embodiment of the present invention will now be described in relation to the accompanying drawings in which,
Figure 1illusrates typical referance for applications;
Figure 2 in accordance with the preferred embodiment of the present invention,
illustrates typical test setup used for the load test of the present invention;
Figure 3 in accordance with the preferred embodiment of the present invention,
illustrates the workload modeling for various user profiles and scenarios;
Figure 4 illustrates a graph showing Request/Sec Vs User Load for a read
operation for an application;
Figure 5 illustrates a graph Requests in application queue Vs User Load for a
read operation for an application;
Figure 6 illustrates a graph showing Requests Execution Time Vs User Load for
a read operation for an application;
Figure 7 illustrates a graph showing Processor Time Vs User Load for a read
operation for an application;
Figure 8 illustrates a graph showing Request Execution Time Vs User Load for a
create operation for an application;


Figure 9 illustrates a graph showing Requests in Application queue Vs User Load
for a create operation for an application;
Figure 10 illustrates a graph showing Request/ Sec Vs User Load for a create
operation for an application;
Figure 11 illustrates a graph showing Processor Time Vs User Load for a create
operation for an application;
Figure 12 illustrates a graph showing Request/Sec Vs User Load for an update
operation for an application;
Figure 13 illustrates a graph showing Requests Execution Time Vs User Load for
an update operation for an application;
Figure 14 illustrates a graph showing Processor Time Vs User Load for an update
operation for an application;
Figure 15 illustrates a graph showing Request Execution Time Vs User Load for
a delete operation for an application;
Figure 16 illustrates a graph showing Requests in Application queue Vs User
Load for a delete operation for an application;
Figure 17 illustrates a graph showing Request/ Sec Vs User Load for a delete
operation for an application;
Figure 18 illustrates a graph showing Processor Time Vs User Load for a delete
operation for an application;
Figure 19 In accordance with the preferred embodiment of the present invention,
illustrates screenshot of a typical GUI and output provided by the capacity
planning tool; and
Figure 20 illustrates screenshot of typical input in the form of user profile to the
capacity planning tool.


DESCRIPTION OF THE INVENTION
The invention will now be described with reference to the accompanying drawings which do not limit the scope and ambit of the invention. The description provided is purely by way of example and illustration. Although the invention is being tested using specific applications such as Dotnet Nuke it is envisaged that the invention could be tested on other applications with or without modification or alteration of the invention.
In accordance with the preferred embodiment of the present invention, a typical capacity planning tool is envisaged. Particularly this tool can be used for sizing CPU capacity for the Web/Application Servers which are required for hosting ASP.NET applications, typically those with standard architectures involving browsers, wide area network (WAN), web server, application server, and database server as shown in Figure 1 of the accompanying drawings.
The present invention overcomes the shortcomings of TCA with Cost per operation approach by enhancing TCA analysis for sizing ASP.NET Applications at the RFP stage itself.
Particularly, the methodology of the present is to select a workload profile and further select a benchmark for testing the performance of multi tiered enterprise grade web applications.
Workload Profile:
A workload profile consists of an aggregate mix of users performing various operations. For example, for a load of 200 concurrent users, the profile might indicate that 20 percent of users perform order placement, 30 percent add items to a shopping cart, while 50 percent browse the product catalog. This helps in


identifying and optimizing the areas that consume an unusually large proportion of server resources.
Selecting a Benchmark:
Specifically, in .NET world there is no standard benchmark that can be used for
testing the performance of multi tiered enterprise grade web applications.
So, benchmarks like Nperf are evaluated, however they are still in the early
phases of development and not applicable to load tests for web applications.
Based on these findings, the present invention has developed its own performance
benchmark which can be used by projects to determine load and estimations
could be done for effective hardware sizing.
Cost per operation takes into account the basic data access operations which are part of every generic application developed using ASP.NET and have maximum impact on the application performance. These operations are typical ADO.NET calls to a database since ADO.NET calls have the maximum overhead.
These operations include:
• Create - A typical database insert operation which creates a record in a
table.
• Read - A typical database select operation.
• Update - A typical database update operation.
• Delete - A typical database delete operation.
• Batch Update and Batch Delete - A typical batch operation implies a state where the number of queries to be performed is large enough to grow the page response time beyond acceptable limits, as a result such


operations are normally done using Ajax calls or done under a separate thread and the page response is sent back.
Based on this methodology the cost of these individual operations at maximum requests per second (throughput) can be calculated.
As create, read, update, and delete are very atomic operations and any generic ASP.NET application can be broken down to these atomic operations at the base level, the cost per operation methodology proves much useful
The key terms and equations used in the present invention are:
Cost Per Request (Megacycles/Request): (Number of processors x Processor
Speed x Processors used)/Number of Requests/Second;
Cost Per Operation: (Number of Megacycles/Request) x Number of Pages for
an Operation;
Cost of Single Operation: Total Cost of Operation - Cost of Read Operation*;
*If this operation contains a read as an operation prior to it.
Calculated Cost of Single CRUD Operation Mix: (Cost of Single Create
Operation + Cost of Single Read Operation + Cost of Single Update Operation +
Cost of Single Delete Operation)/4;
Multiple: Calculated cost of CRUD Operation / Actual Cost of CRUD Operation;
Total Processor Capacity Used = 2.2 GHz x 4 = 8.8 GHz = 8800 Megacycles;
1 GHz = 1000 Megacycles; and
Usage Profile: The various profiles created to calculate costs of individual
operations like create, read, update and delete.
Key terms, notations and details of cost per operation approach can be listed as shown in Table 1


Notation Definition Comment
i=l...I Services deployed like http, ftp, ldap and Sql. In accordance with the preferred embodiment of the present invention, only http and SQL services have been tested.
N1 Number of users concurrently using service i at peak time. 100 users using http can be expressed asN100
CPR Cost Per Request. The cost of a request is CPU cycles needed to execute that request. A request is a simple http get or post.
CPO Cost Per Operation- An operation is a logical operation like create, read, update and delete. An operation can have more than one request.
CSO Cost of Single Operation - The cost of single operation is CPU cycles required to execute a single logical operation. Some operation like delete and update are accompanied by cost of read operation. To calculate the single operation cost the read operation's cost has to be subtracted.
Ox (C,R:U,D) Count of operations in a profile 023(c) means 23 Create operations.
Table 1: Keywords, notations and details of cost per operation approach


In accordance with the preferred embodiment of the present invention, methodology for calculating number of CPUs required for an application where 100 concurrent users access the application for a particular usage profile can be described as below:
For 500 Users at peak load i=100, Number of concurrent Users = N100
For Read Operation Profile with 10 Read Requests
CPR = (2200 x 4 x 0.0676)/265 = 2.2453
where,
Processor Speed in GHz = 2.2
Number of Processor Cores = 4
Percentage CPU Utilization in this profile test = 67.6
Maximum Requests per sec at IIS= 265
For Read Operations, CPR = CPO = CSO
Since, a read operation can have only one request. Same applies to create operation as well.
For Update and Delete Operations,
CSO = CPO - CPORead
Update and delete operations are always led by a read operation and hence the effective cost of update and delete operations are calculated by subtracting the cost of read operation.


Using the above equations the cost of each operation can be calculated as shown
below:
CSORead = 11.534 Mega Cycles
CSOcreate = 25.558 Mega Cycles
CSOUpdate = 20.593 Mega Cycles
CSOUpdate = 32.972 Mega Cycles
Number of CPU's required for 100 users can be calculated as:
Total number of operations = ∑Ox = Oc + Or + Ou + Od
For Example,
Oc = 4
Or = 5
Ou = 4
Od = 5
Numbers of individual operations in this profile are:
Oi = Ox/∑Ox * N100
0, (create) = 4/18* 100 = 22.22
Total CPU Mega Cycles Required COSTcpu = ∑ CSOi * Oi
COSTcpu - CSOc * Oc + CSOr * Or + CSOu * Ou + CSOd * Od
Target CPU Size = X Ghz
Target CPU Utilization = Y % (In percentage)
Effective CPU Available (ECPu) = X*Y/100


Number of CPUs Required = COSTcpu / ECPU
If SSL is implemented at web server, its cost is taken as 25% extra.
Experimental Details: Tests for benchmarking applications were DotnetNuke.
Based on the obtained performance results of DotnetNuke, performance model's
correctness has been measured.
• DotnetNuke Application - DNN is an open source portal building application powered by a strong built-in framework for content management. This application was chosen to benchmark data intensive web applications since DNN creates every page from the information stored in database and is a highly data intensive application.
Load Test: Load tests were performed with a step load pattern. Each test was run for 1 hour to 2.5 hours depending on when the maximum throughput was achieved in requests/sec at the web server. Tests were generated using VSTS 2008 on a Controller-Agent Setup as a remote configuration.
The test environment comprised the following: Web/Application Server details as shown in Table 2

Machine AMD Opteron Processor (848) x 4
Processor 2.20 GHz
RAM 7.83 GB
Storage 40 GB
OS Windows Server 2003 Enterprise Edition SP1
IIS 6.0
.NET Framework 2.0


Table 2
Database Server details as shown in Table 3

Machine Intel Xeon Processor x 4
Processor 3.20 GHz
RAM 1GB
Storage 70 GB
OS Windows Server 2003 Enterprise Edition SP1
Database SQL Server Enterprise 2005 SP1
Network 1 GBPS Ethernet connectivity on each Server
Table 3
The test rig that was setup for performing the tests is shown in Figure 2 of the accompanying drawings.
The tools used are described in Table 4

Tool Name Description
Visual Studio Team System 2008 - Tester Edition This is a latest Visual Studio released by Microsoft Corporation for Application Lifecycle Management. The tester Edition was used for conducting the tests.
.NET CLR Profiler The CLR profiler from RedGate Inc called as ANTS profiler was used to profile the applications for checking performance issues.


SQL Server Profiler The SQL Profiler which comes with SQL server was used to profile the database for any performance issues.
Fiddler Tool Fiddler is an http debugger and was used to record the web tests and test scripts used during testing.
Table 4
DotnetNuke: DotnetNuke (DNN) 4.8.1 was taken to perform the tests. DNN is portal building software from DotnetNuke Corporation and has been built on strong extensible framework. It is built on top of the IBuyspy portal building framework published by Microsoft.
The store module of DNN, which is a full fledged shopping cart application, was chosen to perform the tests. DNN was modified to include a delete operation, where a screen was made to delete a record from the cart table in the database.
Step load pattern was used in steps of 30 seconds, and the test was performed for a much longer duration of 2 hours 30 minutes each.
Testing methodology followed for the tests was:
1. User profiles of atomic Create, Read, Update and Delete operations were recorded using fiddler tool as VSTS web tests.
2. Step load for 2 hours 30 minutes, with initial load of 5 users and step count of 5 users on a step increment time of 30 seconds was done. The maximum load was maintained at 4000 users.


3. The processor utilization where the request/sec was the highest was picked up from the performance counters recorded at the web server end.
4. User profile having a mix of 70% read, 10 % create, 10% update, and 10% delete was also tested on a step load with same run settings.
5. Load Tests were performed on these mixed user profiles and Cost of Single Operation was calculated.
6. A comparison was done between the observed results and the mathematically calculated results and a multiple was calculated.
7. This multiple validates and verifies the present inventions basic capacity modeling methodology.
In the tests it was observed that the multiple was greater than 1, which indicates that the calculated Cost of Operations is always greater than actual cost obtained. So, if calculated Cost of Operations for sizing is used, a bigger size than what is actually required is used to be on the safer side.
Moreover, sizing has to be done for a consistent period of time where the database can grow considerably. As the sizing was done in multiples, the present invention handles this well.
Workload Profile:
Typically, a workload profile consists of only create operations or only read operations or only read or delete operations. Along with this a mix operational profile was also taken which had a mix of all the four operations is various percentages as seen in Table 6.


User Profile Percentage Simultaneous Users
Browse 70% 250/500/750/1000
Insert 10% 250/500/750/1000
Update 10% 250/500/750/1000
Delete 10% 250/500/750/1000
Table 6
In this scenario 70% of browse operations were performed and 10% each of other operations were performed. Similarly other operations were increased to 70% in the operation mix and tests were performed.
Workload Modeling:
Figure 3 of the accompanying drawings shows the workload modeling for various profiles and scenarios. The results of the workload modeling can be seen in Table 7.

Table 7 TEST RESULTS:

Operation A B c D
Percentage 25% 25% 25% 25%
Percentage 70% 10% 10% 10%
Percentage 10% 70% 10% 10%
Percentage 10% 10% 70% 10%
Percentage 10% 10% 10% 70%
DotnetNuke test results:
The test results for DNN in Figure 4 of the accompanying drawings show a graphical representation of 2 point moving average of number of requests/sec with increase in user load on the server for a read operation.

The test results for DNN in Figure 5 of the accompanying drawings show a graphical representation for read operation of requests in application queue Vs user load.
The test results for DNN in Figure 6 of the accompanying drawings show a graphical representation of increase in Request Execution Time with increasing User Load for read operations on the server.
The test results for DNN in Figure 7 of the accompanying drawings show a graphical representation of 2 point moving average of User Load for read operations on the server.
The test results for DNN in Figure 8 of the accompanying drawings show a graphical representation of increase in request execution time with increase in User Load for create operations on the server.
The test results for DNN in Figure 9 of the accompanying drawings show a graphical representation of increase in requests in application queue with increase in User Load for create operations on the server.
The test results for DNN in Figure 10 of the accompanying drawings show a graphical representation of 3 point moving average in requests per second with increase in User Load for create operations on the server.
The test results for DNN in Figure 11 of the accompanying drawings show a graphical representation of increase 3 point moving average in processor utilization with increase in User Load for create operations on the server.


The test results for DNN in Figure 12 of the accompanying drawings show a graphical representation of 2 point moving average of requests per second with increase in User Load for update operations on the server.
The test results for DNN in Figure 13 of the accompanying drawings show a graphical representation of increase in request execution time with increase in User Load for update operations on the server.
The test results for DNN in Figure 14 of the accompanying drawings show a graphical representation of 2 point moving average in processor utilization with increase in User Load for update operations on the server.
The test results for DNN in Figure 15 of the accompanying drawings show a graphical representation of 50 point moving average in requests per second with increase in User Load for delete operations on the server.
The test results for DNN in Figure 16 of the accompanying drawings show a graphical representation of increase in requests in application queue with increase in User Load for delete operations on the server.
The test results for DNN in Figure 17 of the accompanying drawings show a graphical representation of increase in request execution time with increase in User Load for delete operations on the server.
The test results for DNN in Figure 18 of the accompanying drawings show a graphical representation of 50 point moving average in processor utilization with increase in User Load for delete operations on the server.


Test Results Analysis:
The result obtained by DotnetNuke was used to test 2 live applications.
Project A: The sizing was validated with 24.83% errors. Details of the sizing and usage profile can be seen in Table 8.

Transaction Select Insert Update Delete
Registering Ticket 170 16 11 5
Common Queue 20 1 0 0
My Queue 100 1 6 0
History 90 1 2 0
Resolving Ticket 300 14 64 10
Updating Ticket 250 10 17 5
Table 8
The production setup for performing the sizing: 1 Intel Xeon 3.0 GHz Dual Core Processor Processor Utilization: 90% Users: 200 concurrent users
Project B: The sizing was validated with 30.75% errors on the upper side. Details of the sizing and usage profile can be seen in Table 9.

Transaction Select Insert Update Delete
Get catalog 400 10 4 0
Download Pictures 40 10 4 0
Upload content 0 10 0 0
Publish Pictures 45 120 20 0
Publish Audio 45 200 20 0
Publish Video 45 120 20 0
Download Audio 40 10 4 0
Download Video 40 10 4 0
Device Search - Audio 140 0 4 0


Device Search - File 200 0 4 0
Device Search - Folder 60 0 4 0
Desktop Slideshow 40 4 6 0
Desktop Thumbnail 40 4 6 0
Table 9
Production Setup:
4 Intel XEON E5345 ® 2.33 GHz Dual Core Processor
Processor Utilization: 80%
Users: 75 concurrent users
In accordance with the preferred embodiment of the present invention, Microsoft Excel is used to implement the invention. In the services industry there are a number of proposals to size for, and quite often the sizing expert needs to provide capacity estimates within the scope of stringent deadlines. The use of excel facilitates portability as well as usability.
Typically, the read module of the present invention will help users to create a profile and get the calculated Number of CPU's.
In accordance with the preferred embodiment of the present invention, Figure 19 of the accompanying drawings represents the screenshot of capacity sizing tool. Figure 20 of the accompanying drawings shows typically inputs provided to the invention in terms of user profile.
According to the invention, users have to fill up the following fields in the MS Excel based capacity planning tool:


5. Using the benchmarks the Total CPU is calculated.
6. If the web application works across a secure channel (https) additional processor usage is factored into the calculation. This is 25 %.
7. In addition any other factor that may lead to additional CPU utilization can be fastened in.
8. The following terms in the invention are explained as given below:
a. Default CPU size used under production: Typically, this is the target
CPU size which will be deployed. Sizes like 2.5 GHz or 3 GHz for
each core are normally used for deployments.
b. Target Cpu Utilization: Effective CPU that needs to be used at the
deployment servers.
9. Based on the above steps the Number of CPU's required is calculated.
The technical advancements of the present invention include:
• Providing a capacity planning tool
• Providing a tool for calculating the hardware sizing based on the web application's needs.
• Providing a user-friendly, portable and scalable MS Excel based tool for capacity planning.
• Providing a tool for calculating hardware sizing of applications at request for proposal (RFP) stage as well as developed web servers.
• Providing a tool for calculating hardware sizing based on cost per operation approach.
• Providing a tool for capacity planning of new applications when workload and the technical architecture are the only details available.


While considerable emphasis has been placed herein on the particular features of this invention, it will be appreciated that various modifications can be made, and that many changes can be made in the preferred embodiments without departing from the principles of the invention. These and other modifications in the nature of the invention or the preferred embodiments will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the invention and not as a limitation.

MOHAN DEWAN Of R.K.DEWAN&CO. APPLICANTS' PATENT ATTORNEY