Capacity planning for server resources

This is a continuation of U.S. patent application Ser. No. 09/549,816, filed on Apr. 14, 2000, entitled “Capacity Planning For Server Resources”, listing Matt Odhner, Giedrius Zizys and Kent Schliiter as inventors, and which is assigned to the assignee of this application, now U.S. Pat. No. 6,862,623, which is hereby incorporated by reference. This application is related to U.S. patent application Ser. No. 10/897,645, filed on Jul. 23, 2004, which is a divisional of application Ser. No. 09/549,816, and which is also assigned to the assignee of this application.

This invention relates to server systems, and more particularly to systems and methods for server resource capacity planning in server systems.

Capacity planning is forward-looking resource management that allows a computer system administrator to plan for expected changes of system resource utilization and alter a system to adequately handle such changes. Server performance and capacity planning is a top concern of computer administrators and business managers. If a lack of proactive and continuous capacity planning procedure leads to unexpected unavailability and performance problems, the downtime that results could be financially devastating to a company that depends heavily on server performance, such as an Internet-based merchant.

The importance of superior capacity planning is heightened by the continuous growth in server-dependent companies and potential customers for such companies. Even a solid company that has millions of customers can quickly decline in popularity if it does not increase its resources to handle a constant increase in customers. Excessive downtime of such a company can cause customers to take their business elsewhere.

Capacity planning requires both scientific and intuitive knowledge of a server system. It requires in-depth knowledge of the resource being provided and an adequate understanding of future server traffic. The difficulty of the problem has increased by the development of technology in which multiple servers, or a server cluster, is employed to handle a network or an Internet website.

Current capacity planning methods do not adequately estimate a number of servers having certain resources that a system will need to handle expected loads (number of requests per second). Therefore, a capacity planning method and system is needed in which a user can provide an expected load that the system needs to handle and receive information on how to increase servers and/or resources to adequately handle that load.

Methods and systems for providing capacity planning of server resources are described herein. The methods and systems contemplate using measured data, estimations and extrapolation to provide capacity planning results that are more accurate than current schemes. Server resources for which utilization is calculated are processor utilization, communication bandwidth utilization, memory utilization, and general server utilization.

Utilization is expressed in terms of actual use of the resource in relation to the total amount of resource available for use. For example, processor utilization is expressed as a percentage of total processing power available. Communication bandwidth utilization is expressed as a percentage of total communication bandwidth available. Memory utilization is expressed as a percentage of total memory available. General server utilization is expressed as a ratio between a current service rate (number of requests per second served) and maximum possible service rate (maximum number of requests the server is capable of serving). This is less specific than showing the processor, bandwidth, and memory utilization, but it is useful for viewing resource constraints that do not fall under the other three categories.

In a first implementation described herein—referred to as a ‘manual’ method—a user provides several server parameter values that indicate operating parameters for one or more servers in a server cluster. The parameters include, but are not limited to, a specified load to be handled by the server cluster, the number of servers in the cluster, the available communication bandwidth, the processor type and speed for each machine, and the number of processors and amount of memory per machine.

In addition, the user provides document type information that includes the types of documents the server cluster will transmit in response to requests from clients. In the manual method, the documents are classified according to type and size of document, and the user provides the capacity planner with the percentage of each type of document as it relates to the entire amount of documents.

The user also provides information regarding the percentages of different client connections, e.g., 14K, 56K, ADSL, T1, etc. The differences in client connection types affect the resources of the server. For instance, if a client connects to the server cluster at a lower connection speed, then that connection will be held open for a longer period of time to accommodate data transmission and more server resources will be consumed than if the client had connected at a higher connection speed.

A theoretical maximum load value is obtained from a pre-defined load table that contains empirically-derived maximum load values handled by servers having a known amount of memory and a processor having a known speed. If the server does not have a processor speed and memory that exactly matches a load table entry, then the closest match is found and the load value for that match is used as the maximum load that can be handled by the system. This maximum load value is used in calculations to obtain the server resource utilization estimates.

Once the server resource utilizations have been derived, a recommendation is made to the user as to what changes, if any, need to be made to the server cluster to accommodate the specified load. For instance, if a specified load input by the user produces a processor utilization estimate of, say 90%, the capacity planner would recommend that another processor be added to the server cluster to safely handle the specified load.

In a second implementation described herein—referred to as a ‘historical’ method—a filter, such as an ISAPI (Internet Server Application Programmer Interface) filter, collects actual server communication parameter values at certain time intervals from the server cluster. Also, a monitor on each server in the server cluster collects other types of server parameter values at certain time intervals. The collected server parameter values are then used to extrapolate a maximum load that the server cluster can handle. The extrapolated maximum load is used to calculate utilization of server resources, similar to the method described above. The user inputs a load desired to be handled by the server cluster and receives a recommendation for server cluster changes that will enable the server cluster to adequately handle the load. The historical method provides a more accurate result than the manual method because it uses actual server cluster data.

A more complete understanding of the various methods and arrangements of the present invention may be had by reference to the following detailed description when taken in conjunction with the accompanying drawings, wherein:

FIG. 1 is an illustration of a server-client system having a server cluster that supports a website on the Internet.

FIG. 2 is a high-level block diagram of a server cluster having capacity planning capability.

FIG. 3 is a screen shot of a capacity planning worksheet utilized in a manual method of capacity planning.

FIG. 4 is a three-dimensional table of load figures based on processor speed and memory.

FIG. 5 is a graph of load vs. processor utilization for a manual method of capacity planning.

FIG. 6 is a screen shot of a capacity planning worksheet utilized in an historical method of capacity planning.

FIG. 7 is a graph of load vs. processor utilization for an historical method of capacity planning.

FIG. 1 shows a typical Internet-based server-client system 100 . The system 100 includes several clients 104 a , 104 b , 104 c , 104 d connected to the Internet 102 . A website 106 runs on a server cluster 108 comprised of three servers 110 a , 110 b , 110 c . Although the server-client system 100 is shown operating within an Internet website context, it is noted that the server-client system may operate in any server-client network context, such as a local area network (LAN) or a wide area network (WAN).

FIG. 2 depicts a server cluster 200 in accordance with the described implementations. The server cluster 200 comprises a primary server 202 having a processor 204 and a monitor 205 resident in memory 206 , a first secondary server 207 having a processor 208 and a monitor 209 , and a second secondary server 210 having a processor 212 and a monitor 213 . The monitors are software applications that collect server parameter values while the server cluster 200 is in operation. It is noted, however, that the monitors can be hardware units or firmware modules that perform the same function as described herein. The server cluster 200 communicates with a client 214 via a communications connection 216 . Although only one client 214 is shown in communication with the server cluster 200 , it is understood that many clients may be similarly connected to the server cluster 200 .

The primary server 202 also includes an operating system 220 resident in the memory 206 . The operating system 220 provides resource management for primary server 202 resources. The memory 206 of the primary server 202 includes a cluster controller 222 , which controls communications between the primary server 202 and the secondary servers 206 , 210 and between the server cluster 200 and the client 214 . To accomplish this, the cluster controller 222 is provided with a communications program 224 .

A capacity planner 226 is included in the cluster controller 222 . The function of the capacity planner 226 and its components will be described in greater detail below. Generally, the capacity planner 226 comprises benchmark data 228 in which empirically-derived test data from similar systems is stored, a calculation module 230 which stores the equations necessary to derive server resource utilization estimates, and plans 232 which store server parameter values and recommendations.

In addition, the capacity planner 226 includes a user interface 234 and a filter 236 . The user interface 234 provides areas wherein a user of the server cluster 200 in general and, more specifically, the capacity planner 222 can enter server parameter values and/or a specified load for which the user wants to see server resource utilization and recommendations. The filter 236 is used to collect actual server parameter values from the server cluster 200 while the server cluster 200 is operating.

The implementations and functions of the components of the server cluster 200 outlined above will become more clear as the discussion progresses with continuing reference to the components of FIG. 2 .

The server resources that are discussed herein are: (1) processor utilization (also referred to herein as CPU utilization), expressed as a percentage of total processing power available; (2) memory utilization, expressed as a percentage of total memory available; (3) communication bandwidth utilization, expressed as a percentage of total communication bandwidth available; and (4) general server utilization, expressed as a ratio between current service rate (number of requests served per second) and maximum possible service rate (maximum number of requests the server cluster 200 is capable of serving per second). The general server utilization does not show specific utilization estimates such as the processor, bandwidth, and memory utilizations, but it shows an overall view of resource constraints that do not fall under the other categories.

Manual Method

FIG. 3 shows a screen shot of a user interface 300 for the manual method that is in the form of a capacity planning worksheet, wherein the user enters the specified load for which the user desires to observe the effects on the system of handling such a load. The user is required to manually enter several server parameter values. These server parameter values include: number of servers in the server cluster, available communications bandwidth, processor type, number of processors per server, processor speed, and amount of memory per server.

In addition, the user must enter information regarding document types and client connections. These parameters have an affect on server resources due to their size and speed. For example, a larger document will require more communication bandwidth for transmission than will a smaller document, and it will require more computing power to process. Also, a client connected at a slower speed, e.g., 14K BPS, will consume server resources for a longer period of time than a client connected at a faster speed, e.g., 56K BPS, because the client connection will be held open longer to accommodate the slower connection transmitting the document. Therefore, these are important considerations that must be taken into account.

The user provides document type information in terms of the percentage of total documents that each document type comprises. In the manual method described herein, documents are divided into six document types. These document types are categorized in terms of the kind of document, hypertext markup language (HTML) documents or active server pages (ASP), and the size range of the documents. The six document types utilized in the manual method are: HTML documents from zero to ten kilobytes; HTML documents from eleven to one thousand kilobytes; HTML documents greater than one thousand kilobytes; ASP documents having zero COM (component object model) objects; ASP documents having one COM object; and ASP documents having more than one COM object. The user enters a percentage for each document type that the user expects the server cluster 200 to service. The user must estimate these percentages, but if there is sufficient history available to the user, the estimates can be fairly accurate.

Similarly, the user provides client connection information in terms of the percentage of total connections that each connection type comprises. In the manual method discussed herein, client connections are divided into six types: (1) 14K BPS; (2) 28K BPS; (3) 56K BPS; (4) ADSL; (5) T1; and (6) T3 and above. The user enters a percentage for each client connection type that the user expects the server cluster 200 to service. As with the document type estimates, the user's knowledge of the history of types of client connections to the system will help to provide more accurate server resource utilization estimates.

The user interface 300 also provides the server resource utilization estimates and recommendations to the user after the capacity planner 222 has completed its calculations. For convenience purposes, these results will be discussed in detail below.

FIG. 4 shows, in detail, the benchmark data 228 stored in the capacity planner 222 . A load table 400 is a pre-defined, three-dimensional matrix of empirically-derived results from tests performed on a variety of hardware configurations. It is noted that the load table 400 is used only in the first embodiment—the “manual approach”—described herein.

The load table 400 has three dimensions: processor type/speed 402 , memory 404 , and document type 406 . The processors depicted are PII-400, PII-450, PIII-500, K6-500, although any type and speed of processor could be used in a benchmark configuration. Likewise, memory amounts depicted are 128 M, 256 M and 512 M, although any amount of memory could be used in a benchmark configuration. As previously discussed, six documents types are utilized, although more or less could be implemented. Therefore, the load table 400 is a 2×2×6 matrix in this particular depiction, and the document types 406 designated in the load table 400 are 406 a , 406 b , 406 c , 406 d , 406 e , and 406 f.

Each entry in the load table 400 comprises five values: a maximum load handled by the hardware configuration, a first processor regression constant (a i ), a second processor regression constant (b i ), a first bandwidth regression constant (c i ), and a second bandwidth regression constant (d i ). The subscript i in these examples represents the document type associated with the constant. The load table 400 shown in FIG. 4 shows an arbitrary representative maximum load value (X number of requests per second) for discussion purposes only. The other values are represented simply by their corresponding constant, a, b, c and d.

In making the calculations in the implementations described herein, it is assumed that the server cluster 200 is a single service point with infinite queue size. Queuing theory is then applied to determine most server resource values. Analysis shows that there exist certain functional dependencies between an incoming request rate (load) and other server resource values. In each case, two values are sought to be determined: (1) maximum load (maximum number of requests per second the server is capable of serving); and (2) functional dependency between incoming request rate and different resources.

Processor utilization and communication bandwidth utilization are calculated using functional dependency approximation between resource utilization and load. For functional dependency approximation, linear regression is utilized. For processor utilization, the functional dependency is transformed into linear form by applying standard logarithmic transformation.

The linear equation to be solved has the form of:

y=a+b·x

where y equals utilization and x equals load.

The results of the empirical testing referred to above result in a number of pairs (x, y). Linear regression is used to solve this equation using the (x, y) pairs:

=

where:

b

xy

=

Therefore, processor regression constants a and b are:

a = y _ - b yx · x _

and

b=b yx .

The calculations to derive the bandwidth regression constants c and d are similar to those described for processor regression constants a and b.

In that case, the linear equation to be solved has the form of:

y=c+d·x

where y equals utilization and x equals load.

The results of the empirical testing referred to above result in a number of pairs (x, y). Linear regression is applied to solve:

=

where:

d

xy

=

Therefore, bandwidth regression constants c and d are:

c = y _ - d yx · x _

and

d=d yx .

It is extremely difficult to find a functional dependency of memory usage, so the manual method uses a heuristic formula for calculating the required memory. Also, the calculated amount of memory depends on the number of incoming requests. The memory utilization formula will be discussed in greater detail below.

In deriving server resource utilization estimates, the server parameter values for memory, processor type and processor speed that are input by the user are compared to the load table 400 . If there is an exact match, then the values (load, a i , b i , c i and d i ) for the entry corresponding to the processor and the memory are utilized in the utilization calculations.

If, however, there is no exact match, the calculation module 230 of the capacity planner 226 determines the closest match to the input server parameter values and substitutes the values in the entry for the closest match in the utilization calculations. FIG. 5 demonstrates how this matching process closely approximates the exact utilization values, but could cause some degree of error in the utilization calculations.

FIG. 5 depicts a load vs. utilization graph of the function for processor utilization, as explained previously. An exact match results in function curve 500 , which shows a point 502 that indicates the processor utilization for the specified load 504 . If, however, there is no match, the closest match found in the load table 400 is used. Function curve 506 shows the result when the closest match found is reasonably close to the actual server hardware configuration. In this instance, the error is reasonably insignificant. Function curve 508 shows the result when the closest match found is not sufficiently representative of the server hardware configuration. The error is greater than the error in function curve 506 , but it still provides a utilization figure that is a reasonably adequate to provide a user with useful planning information.

When the server parameter values have been input, the server resource utilization estimates are calculated. The general server utilization is derived by solving:

U

=

wherein:

i is the document type;

q i is the document value for document type i, i.e., the percentage that document type i makes up of the total documents (expressed in decimal form);

L is the specified load input by the user; and

X i is the load value obtained from the load table for document type i.

The processor utilization estimate is derived by solving:

U

=

wherein:

U CPU is processor utilization;

i is the document type;

a i is the regression constant a for document type i (from the load table 400 );

b i is the regression constant b for document type i (from the load table 400 );

q i is the document value for document type i; and

L is the specified load.

The communications bandwidth utilization estimate is derived by solving:

U

B

=

wherein:

U B is communication bandwidth utilization;

F TCP is a transmission overhead factor for each document type that, when applied to a certain size page of the document type, results in the actual bandwidth necessary to transmit the page (for example, a 1 KB HTML document may actually require 1.3 KB to transmit; in such a case, F TCP is 1.3);

i is the document type;

c i is the regression constant c for document type i;

d i is the regression constant d for document type i,

q i is the document value for document type i;

L is the specified load; and

B is the total communication bandwidth available.

The memory utilization estimate is derived by first solving the following equation to determine the number of concurrent connections:

N

=

wherein:

i is the document type;

q i is the document value for document type i;

L is the specified load;

X i is the load value obtained from the load table for document type i; and

S 1 is a connection memory factor that is the adjusted average of the incoming connections at different speeds. For example, suppose that the user has input the following percentages for connection types in the user interface 300 :

56K: 50%

ADSL: 20%

T 1 : 20%

T 3 : 10%.

Then S 1 is the adjusted average of these connection speeds:

S 1 =488.8 KBytes/Sec.

Memory utilization is then derived by solving:

U

M

=

wherein:

U M is memory utilization;

M TCP is an amount of memory for TCP buffers (32 KB per connection);

M IIS is the amount of memory required by a server communication program (50 MB for IIS (see note below));

M IISStruct is the amount of memory necessary to support communications program data structures associated with each connection (50 KB per connection for IIS (see note below));

M OS is the amount of memory required by a server operating system (64 MB for Windows® NT by Microsoft® Corp.) and

M is the amount of total memory available.

It is noted that the designation IIS and IISStruct for the communications program and the data structures related thereto is derived from the communications program “Internet Information Server” from Microsoft® Corp. The figures may be different is a different communication program is used.

Referring now back to FIG. 3 , the server resource utilizations are displayed to the user via the user interface 300 . Although the server resource utilizations are shown displayed as a graph, the utilizations may be displayed to the user in any number of ways.

The calculation module 230 uses the server parameter values and the server resource utilizations to recommend a plan to the user. The plan will advise the user as to what configuration changes need to be made to the server cluster 200 to ensure that the specified load will be adequately handled, thus virtually eliminating down time that could be costly to the user. The calculation module 230 may use various rules to determine when different resources should be added. For instance, if the processor utilization is greater than 90%, the calculation module may display a message to the user that recommends an additional processor.

Historical Method

The historical method is a second implementation of the present invention that is useful for: (1) projecting future capacity based on current capacity; and (2) providing more accurate projections than the manual method described previously. The monitors 205 , 209 , 213 collect data for the following parameters from each server 202 , 206 , 210 :

Processor Utilization (% time that processor is utilized) Concurrent Client Connections Memory Utilization (total KB).

In addition to data collection by the monitors, the filter 236 collects data for the following parameters:

Number of Incoming Requests Average Response Time

It is noted that if the server cluster capacity cannot be determined from the time window selected by the user, an appropriate message is displayed to the user and the user is provided the opportunity to select another time window.

FIG. 6 shows a user interface 600 for the historical method that is in the form of a capacity planning worksheet, wherein the user enters the time window for which the user wishes to collect server parameter values. The user is also required to manually enter the current load (requests/second) handled by the server cluster 200 , the increase in terms of percentage that the user wants the server cluster 200 to handle, the number of servers currently in the server cluster 200 , and the available bandwidth. The new load (requests/second) is automatically calculated and displayed using the current load and the specified load increase. Alternatively, the user may enter the new load and, in that case, the percentage increase is automatically calculated.

It is noted that in the historical method—as opposed to the manual method—it is not necessary for the user to estimate the percentages of document types and connection types serviced by the server cluster 200 . This is because the filter 236 collects this data. Since real data is utilized instead of estimated data, the historical method is inherently more accurate than the manual method. Also, it is noted that the load table 400 is not utilized.

The server resource utilization calculations require knowledge of the maximum load that the server cluster 200 can handle. If any of the server resources being measured happens to reach a maximum during the measurement time window, then that determination is simple, as it is simply the load value at the time the particular server resource was 100% utilized. However, it is unlikely that will happen. Therefore, the maximum load that the server cluster 200 can handle must first be extrapolated from the collected server parameter values so that the server resource utilization calculations can be made.

The maximum load that the server cluster 200 can handle is calculated from historical data that have been collected in the following manner.

A set of values (L i ; CPU i ; TotalBytes i ) is recorded simultaneously at time i. L i is the incoming server load at time i, CPU i is the processor utilization at time i, and TotalBytes i is the total number of kilobytes transmitted by the server cluster 200 at time i.

Now processor regression constants a and b can be found by transforming processor utilization into linear form. The processor utilization equation is:

U

=

a

ⅇ

b

·

L

and becomes: ln( U CPU )=ln( a )−b·L

The natural logarithm function is applied to CPU i of measured pairs of (L i ; CPU i ), which gives pairs of (L i ; CPU i ′), where CPU i ′ is ln(CPU i ).

L i is substituted for x and CPU i ′ is substituted for y in the following formula:

y=a+b·x

Linear regression is applied to solve this equation:

g ( x )= y +b yx ·( x− x )

where:

b

xy

=

Therefore, processor regression constants a and b are:

Processor utilization is then derived by solving:

U

=

where: a′=ln(a); and b′=−b.

FIG. 7 shows a load vs. processor utilization graph. The above function is shown in two sections. A first section 700 , is graphed using actual data that has been collected from the server cluster 200 . A second section 702 is extrapolated from the collected data using a first derivative of U CPU as a function of L:

U CPU =e a′ ·b′·e b′·L

The value of this function at the largest value of L from the collected data will be the function slope, i.e., the tangent between the function curve and the x-axis (load axis). If the derivative value at that point 704 is greater than a pre-determined value, for example, tan((4·II)/9), then it is assumed that the collected data is sufficient to accurately extrapolate the maximum load that can be handled by the system. Thereafter, a value of L is found where U CPU has a value of 100%. This value 706 is the variable X for equations stated below.

General server utilization is derived by solving:

U

=

L

X

wherein:

U=general server utilization;

L=specified load; and

X=maximum load that can be handled by the server cluster 200 .

Communications bandwidth utilization is derived by solving:

U

B

=

wherein:

U B is communication bandwidth utilization;

F TCP is a transmission overhead factor that, when applied to a certain size page, results in the actual bandwidth necessary to transmit the page;

L is the specified load;

B is the total communication bandwidth available; and

c and d are bandwidth regression constants derived as shown previously.

The memory utilization is derived by first solving the following equation to determine the number of concurrent connections:

N

=

wherein:

N is the number of concurrent connections;

L is the specified load;

X is the maximum load that can be handled by the server cluster 200 ; and

S 1 is a connection memory factor that is the adjusted average of the incoming connections at different speeds (as explained above).

The memory utilization is thus derived by solving:

U

M

=

wherein:

U M is memory utilization;

N is the number of concurrent connections;

M TCP is an amount of memory for TCP buffers (32 KB per connection);

M IIS is the amount of memory required by a server communication program (50 MB for IIS);

M IISStruct is the amount of memory necessary to support communications program data structures associated with each connection (50 KB per connection for IIS);

M OS is the amount of memory required by a server operating system (64 MB for Windows® NT by Microsoft® Corp.) and

M is the amount of total memory available.

The described implementations advantageously provide for capacity planning for a server-client system and, particularly, to a server cluster within a server-client system. The manual method is easier to implement and provides an adequate method for capacity planning that is superior to similar methods and systems known in the art. The historical method, while more difficult to implement, provides an advantage over the manual approach in that it collects server parameter values from the server cluster during operation. Using these actual values provides an even more accurate capacity planning scheme. Other advantages will be apparent to those of skill in the art.

Although the invention has been described in language specific to structural features and/or methodological steps, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features or steps described. Rather, the specific features and steps are disclosed as preferred forms of implementing the claimed invention.