System and method for sizing computer systems with variable ramp-up periods by calculating a throughput for target configuration based on data obtained from a computer subsystem

[0002] The present invention relates to the design, evaluation, and sizing of computer systems.

[0003] The performance of a computer system in executing a particular application is determined by the complex interactions of its component parts. An application is a set of instructions executed in a particular sequence (but not always the same sequence), referencing data in a variable pattern. The particular hardware on which the application runs provides a variety of components that the application accesses in variable and complex manners to form the whole system.

[0004] Therefore, in order to evaluate the performance of a computer system as a whole, designers typically focus on individual subsystems independently, understanding the performance of each subsystem and then evaluating its interactions with other subsystems. Any one subsystem that is receiving excessive use can cause a bottleneck for the entire computer system, thereby creating unacceptable user response times. Accordingly, the goal of computer system design and sizing is to create a computer system whereby all of the individual subsystems meet or exceed the capacity necessary to provide acceptable user response times. General categories of computer subsystems include: processor/cache; memory; input/output (“I/O”); operating system data structures; networking; etc.

[0005] The necessary subsystem capacity for a particular application has typically been determined based on empirical data derived from observing steady-state behavior of the system. Steady state refers to when the computer system has generally reached equilibrium in terms of the number of application users. Computer systems, however, do not always operate at steady state. Rather, computer systems must first “ramp-up” to a steady-state number of users. For example, the computer system at a bank may host a thousand users during the majority of the working day, but the number of users may increase from zero to one thousand from 8:00 a.m. to 8:30 a.m., as employees arrive for work. The period between zero (or low) usage to steady-state usage is referred to as the “ramp-up” period.

[0006] Sizing computer systems based on only steady-state information can result in serious errors because it is based on the assumption that the maximum utilization for the computer system (and its individual subsystems) occurs during steady-state operation. That assumption is correct only if the per-user utilization of the computer system is the same or less than utilization during steady-state operation. For many applications, however, per-user utilization of the computer system (and/or individual subsystems) is greater during ramp-up than during steady-state operation.

[0007] For example, as shown in FIG. 1, the I/O queue length (number of instructions waiting to be executed by the I/O subsystem), increases exponentially during ramp-up for many applications. This phenomenon is caused by increased I/O activity per user when users first activate an application (e.g., when users first access a web browser, significant I/O activity is created because the application must download outside libraries, specific data structures, etc.). As shown in FIG. 1, the increase in per user I/O activity causes the peak utilization of the I/O subsystem to occur during ramp-up 100, not during steady-state operation 110. Accordingly, an I/O subsystem sized for steady-state operation will cause unacceptable customer response times during ramp-up due to an I/O bottleneck.

[0008] This problem is often ignored by salespeople and engineers charged with designing a custom computer system for a particular application, thereby resulting in computer systems that are undersized and perform poorly during ramp-up. Alternatively, those computer system designers who have become aware of the problem will sometimes use a “fudge factor” to estimate the additional system capacity necessary during ramp-up for certain applications. For example, some system designers will configure a system based on steady-state data and then increase the capacity of particular subsystems by 50% to account for increased utilization during ramp-up. This “fudge factor” method, of course, can be extremely inaccurate—often resulting in oversized computer systems that are a waste of the customer's money or undersized computer systems that perform poorly during ramp-up.

[0009] No method or system for accurately compensating for increased utilization during ramp-up has previously been developed. The reasons for this are apparent—time and money. Computer systems (and subsystems) have typically been sized based on empirical data derived for a particular configuration running a particular application. That empirical data is derived using a benchmark analysis, wherein the application is run (or modeled by computer simulation) for each potential configuration assuming a certain number of users during steady-state operation. For example, in order to determine the steady-state I/O utilization in a certain configuration for a particular application, a system designer performs a benchmark analysis. The benchmark analysis indicates the amount of I/O activity per user during steady state (i.e., (I/O activity during steady-state)÷(number of users in benchmark analysis)). The steady-state I/O requirements for a different number of users than used in the benchmark analysis can then be calculated linearly for each configuration (i.e., (I/O activity per user)×(number of users)).

[0010] Taking into account the ramp-up period makes this empirical approach much more difficult because, as discussed, per-user utilization is often different during ramp-up than during steady-state. That fact makes a linear extrapolation from a single calculation of per-user utilization impossible. Moreover, different customers have varying ramp-up periods, which can also significantly affect per-user utilization of system resources. In general, shorter ramp-up periods cause certain subsystem queue lengths to grow more rapidly. Accordingly, in order to size a computer system accurately using the typical benchmark-analysis approach, one would need to test, for each application, all possible ramp-up periods against all possible system (and subsystem) configurations using varying numbers of users. The resulting test matrix would be immense and impractical, especially considering that benchmark analyses often take hours to run.

[0011] Perhaps for this reason, ramp-up periods have often been ignored in computer-system sizing. However, ramp-up can significantly affect a customer's perception of the system's performance. Accordingly, what is needed is a system and method for accurately sizing computer systems that does not require massive numbers of benchmark analyses and avoids the severe undersizing and oversizing errors inherent in the previous systems.

[0012] The present invention provides a system and method for accurately sizing a computer system and its component subsystems. The present invention requires only limited benchmark analysis to design varying configurations, having varying numbers of users, and accounting for varying ramp-up periods. In addition, the the severe undersizing and oversizing errors of previous systems are avoided without requiring repeated trial and error benchmark analyses.

[0013] According to a preferred embodiment of the present invention, diagnostic data for a known subsystem configuration B is derived from a single benchmark analysis. From that diagnostic data a “terminal queue length,” Q_BL, for configuration B can be derived. Terminal queue length, as used herein, refers to the maximum subsystem queue length that can be permitted during ramp-up, beyond which application-user response time is unacceptable. Once Q_BLis empirically determined from the diagnostic data, it can be used to determine, without further benchmark analysis, the necessary throughput for a “target configuration,” A. Target configuration A is the subsystem configuration being sized and can be designed for a different number of users and/or a different ramp-up period than configuration B.

[0014] The basic method of the present invention requires: (1) obtaining empirically derived diagnostic data for a known configuration, B, of a computer subsystem, the configuration B accommodating a number of users, N_B, and a ramp-up period, R_B; (2) calculating, based on the diagnostic data for known configuration, B, the necessary throughput for target configuration, A, the target configuration A accommodating a number of users, N_A, and a ramp-up period, R_A,and providing an acceptable application-user response time during R_A; and (3) configuring the target configuration A.

[0015] The basic system of the present invention includes: a storage device and a processor operatively connected to the storage device, wherein: (1) the storage device: (a) stores a program for controlling the processor; and (b) receives empirically derived diagnostic data for a known configuration, B, of a computer subsystem, the configuration B accommodating a number of users, N_B, and a ramp-up period, R_B; and (2) the processor is operative with the program to: (a) calculate, based on the diagnostic data for known configuration, B, the necessary throughput for target configuration, A, of the computer subsystem, the target configuration A accommodating a number of users, N_A, and a ramp-up period, R_Aand providing an acceptable application-user response time during R_A; and (b) configure the target configuration A.

[0016] The invention is described in greater detail with regard to the following drawings.

[0017] FIG. 1 is an exemplary graph illustrating the approximate change in queue length over time for a particular I/O subsystem configuration running a particular application.

[0018] FIG. 2 is a flow chart of the basic method steps of the present invention.

[0019] FIG. 3 is an exemplary graph illustrating the approximate change in queue length versus number of users during the ramp-up period of a particular I/O subsystem configuration running a particular application.

[0020] FIG. 4 is a flow chart of a preferred embodiment of the method according to the present invention.

[0021] FIG. 5 is an exemplary graph illustrating the approximate change in the natural log of the queue length versus a change in ramp-up period duration of a particular I/O subsystem configuration running a particular application.

[0022] FIG. 6 is an exemplary graph illustrating the approximate change in the natural log of the queue length versus a change in number of users during the ramp-up period of a particular I/O subsystem configuration running a particular application.

[0023] FIG. 7 is a block diagram of the apparatus of the present invention.

[0024] The method and system of the present invention eliminates the errors and wasted empirical efforts of previous systems by extrapolating from limited benchmark analysis to correctly size computer systems and subsystems. FIG. 2 illustrates the basic method steps of the present invention. First, empirically derived diagnostic data for a known computer subsystem configuration is obtained 200, such as through a benchmark analysis. As used herein, configuration “B” refers to a known computer subsystem configuration that has been, or is being, subjected to a benchmark analysis for a particular application. In performing the benchmark analysis, the number of users at the end of ramp-up is presumed to equal N_B, and the ramp-up period for the application being tested on configuration B is referred to as RP_B.

[0025] Next, the diagnostic data from configuration B is used to calculate 210 the necessary throughput for target configuration, A. As used herein, target configuration A refers to the subsystem configuration that is being designed using the present method and system. In general, a subsystem configuration can be represented by its maximum throughput capability. For example, the configuration of an I/O subsystem can be represented by the maximum number of transactions (e.g., reads, writes, etc.) per second that it can accomplish. The present invention is intended to aid in accurately determining that throughput, although it is recognized that a number of particular combinations of subsystem elements (e.g., disk drives) can be used to achieve any particular maximum throughput capability.

[0026] Once the necessary throughput for target configuration A is calculated 210, target configuration A is designed 220. Again, the actual design 220 of target configuration A involves matters of design choice that can be affected by a variety of factors. For example, if a salesperson is using the present invention as a sizing tool, he is likely to suggest a combination of subsystem elements that he sells to achieve the necessary throughput of target configuration A. The combination of components to achieve the correct throughput can be automated by any number of known methods and systems. The present invention, however, facilitates calculation of the throughput requirement that makes an accurate design possible, whether or not the final design process is automated.

[0027] Preferred embodiments of the present invention are described in greater detail with regard to FIGS. 3-7. Subsystem queue length, which refers to the number of transactions waiting at any one time to be executed by the subsystem, is a good indicator of whether a subsystem is creating a bottleneck in the overall computer system. FIG. 3, for example, details a typical increase in I/O queue length as users are added during ramp-up. The raw data (shown by the jagged line 300) are well approximated by the exponential line 310. This is a common pattern among applications that are I/O bound during ramp-up. For the purposes of the present invention, ramp-up is generally presumed to result in an exponential increase in queue length for certain subsystems, such as the I/O subsystem. Indeed, for some applications, if the I/O subsystem is undersized, the computer system as a whole can become unstable during ramp-up.

[0028] As discussed, there is, for a given application and a given configuration, a maximum subsystem queue length that can be achieved during ramp-up, beyond which user response time is unacceptable. This is referred to herein as the “terminal queue length,” and it varies from configuration to configuration depending on throughput. Configurations with higher throughput can accommodate a longer queue before response times become unacceptable. For example, a configuration with a throughput of 1,000 transactions per second will generally have a terminal queue length that is twice as long as a configuration that can perform only 500 transactions per second.

[0029] As detailed in FIG. 4, the preferred embodiment of the present invention generally uses the empirically derived terminal queue length, Q_BL, of a known subsystem configuration B to accurately design target configuration A. As discussed, “terminal queue length,” as used herein, refers to the maximum subsystem queue length that can be permitted during ramp-up, beyond which application-user response time is unacceptable. Acceptable application-user response times will vary depending on the application at issue and its users. For example, some complicated CAD-CAM applications may involve very long user response times; however, because those response times are expected, they are acceptable to the users. On the other hand, a user of word processing system typically will not accept response times that exceed a few seconds. Consequently, as used herein, “acceptable application-user response time” means whatever response time that is acceptable to the users of the application at issue. One of ordinary skill will recognize that acceptable application-user response times vary but can be determined on an ad hoc basis depending on the application, type of users, user expectations, etc. Often, the application-user response time will be dictated by the customer for whom the computer system is being designed.

[0030] Typically, computer systems are designed to accommodate a known number of steady-state users operating a particular application. The first step in the preferred method is to obtain 400 results from an appropriate benchmark analysis. A benchmark analysis for a particular application need not be performed each time a new computer system is to be configured. Rather, it is anticipated that benchmark data for particular applications will be stored to permit repeated use in sizing and resizing computer systems for those applications.

[0031] However, because the present invention concentrates on sizing individual subsystems within an overall computer system, choosing the appropriate benchmark analysis involves first determining the subsystem to be analyzed. The subsystem of interest is the one likely to create a system bottleneck during ramp-up, and it can be identified using a variety of known techniques, including analysis of previous benchmark runs for the same application. For example, the present invention can be used to right-size I/O subsystems in overall computer systems that are I/O bound during ramp-up.

[0032] It is preferred that the benchmarked computer system resemble as closely as possible the system being designed to minimize the effect of variations in other parts of the computer system on the performance of the subsystem of interest. For example, if it is determined that a computer system is I/O bound during ramp-up for a particular application, it is preferred that the benchmarked computer system be identical to the system being designed in all respects except for the I/O subsystem (which is being right-sized).

[0033] The benchmark analysis of subsystem configuration B includes data collected during ramp-up. Numerous system-monitoring utilities can be used to perform the benchmark analysis of subsystem configuration B, including “Perfmon” in Microsoft's Windows NT operating system. Many of those same utilities, including Perfmon, can be used to derive 410 specific parameters for subsystem configuration B, including the terminal queue length, Q_BL. As discussed, Q_BLis the maximum queue length for subsystem configuration B that can exist before application-user response times become unacceptable.

[0034] In addition to Q_BL, the following information can be derived from the benchmark analysis of subsystem configuration B:

[0035] N_BNumber of users at end of ramp-up, configuration B.

[0036] R_BResidence time, configuration B.

[0037] S_BService time, configuration B.

[0038] X_BThroughput, configuration B.

[0039] Q_BTTime in queue, configuration B.

[0040] RP_BRamp-up period, configuration B.

[0041] Many of these abbreviations and some of the basic queuing network theories discussed below are derived from “Quantitative System Performance: Computer System Analysis Using Queueing Network Models,” by Lazowska, Zahorjan, Graham and Sevcik; Part I; Prentice-Hall, 1984, which is hereby incorporated by reference.

[0042] According to a preferred embodiment of the present invention, the empirical data from configuration B can be used to design, without further empirical analysis, a target subsystem configuration, A, having a different number of users and a different ramp-up period from configuration B. As used herein, the corresponding parameters for target configuration A are referred to as follows:

[0043] N_ANumber of users at end of ramp-up, configuration A.

[0044] R_AResidence time, configuration A.

[0045] S_AService time, configuration A.

[0046] X_AThroughput, configuration A.

[0047] Q_ATTime in queue, configuration A.

[0048] Q_ALTerminal queue length, configuration A.

[0049] RP_ARamp-up period, configuration A.

[0050] Both N_Aand RP_Amay (and usually will) differ from N_Band RP_B, respectively. However, according to the present invention, these two variables are addressed separately. First, terminal queue length, Q_AL, is calculated 420, assuming that the ramp-up period RP_Aequals RP_B(i.e., the ramp-up period is held constant while the number of users is permitted to vary between known configuration B and target configuration A). Configuration A is then configured 430 based on Q_AL. Next, a throughput factor is calculated to compensate for any difference between RP_Aand RP_B, and target configuration A is reconfigured 450 based on the throughput factor. Once subsystem configuration A is correctly sized for both N_Aand RP_A, each of the other computer subsystems are checked 460 to determine whether it needs resizing. If so, steps 400 through 450 are repeated 470 for that different subsystem. Finally, the computer system as a whole is configured 480.

[0051] The calculation 420 of Q_ALcan be accomplished as follows. Q_BL,N_A,and N_Bare known. In addition, it is assumed that the overall computer system incorporating target configuration A will have the same response time as the computer system used to benchmark subsystem configuration B. This implies that each of subsystem configurations A and B has the same residence time:

[0052] R_A=R_B  [0]

[0053] In addition, Little's Law indicates that:

[0054] R=N/X

[0055] so

[0056] N_A/X_A=N_B/X_B.  [1]

[0057] In addition, it is known that:

[0058] S_k=B_k/C_k=U_kT/C_k=U_k/Xk

[0059] where k refers to a particular service center (for example, the I/O subsystem), B is the time busy, C is the number of completions, T is the observation interval, and U is the utilization. It can be assumed here that the U_A=U_B=1 (i.e., that the I/O subsystem is fully utilized during the times of interest). Otherwise, the queue length would not increase exponentially during ramp-up. Thus:

[0060] S_A=1/X_A

[0061] S_B=1/X_B,

[0062] which implies that

[0063] S_A/S_B=X_B/X_A  [2]

[0064] and

[0065] S_A/S_B=N_B/N_A.  [3]

[0066] (by equation [1] above).

[0067] Given that time in queue is denoted as Q_ATand Q_BTfor A and B, respectively:

[0068] R_B=Q_BT+S_B  [4]

[0069] (i.e., residence time equals time in queue plus service time).

[0070] In addition,

[0071] Q_BT=Q_BL*S_B.  [4a]

[0072] Q_BLis known, and S_Bcan be arbitrarily assigned a value of 1 because, for these purposes, it is unitless. Therefore:

[0073] Q_BT=Q_BL.  [5]

[0074] Then, since:

[0075] R_B=R_A=Q_AT+S_A  [6]

[0076] (from [0] and [4]) and

[0077] Q_BT+S_B=Q_AT+S_A  [6a]

[0078] (from [4] and [6]) and

[0079] Q_BT+1=Q_AT+N_B/N_A  [6b]

[0080] (from [6a], [3] and S_B=1), then

[0081] Q_AT=Q_BL+1−N_B/N_A  [7]

[0082] (from [6b] and [5]), which allows calculation of Q_ATdirectly, because N_B/N_Aand Q_BLare known. In addition, because S_B=1:

[0083] S_A=N_B/N_A  [8]

[0084] (from [3] above) and

[0085] Q_AL=Q_AT/S_A  [9]

[0086] (from [4a]) (i.e., the length of the queue equals the time in queue divided by the service time), then:

[0087] Q_AL=Q_AT*N_A/N_B  [10]

[0088] (from [9] and [8]), which allows calculation of Q_ALdirectly, using the known quantities of Q_AT, N_A, and N_B.

[0089] In sum, the average time in queue for configuration A, Q_AT, can be calculated from Q_BL(the terminal queue length for configuration B), and from N_Band N_A(the number of users on both configurations at the end of ramp-up) as follows:

[0090] Q_AT=Q_BL+1−N_B/N_A  [7]

[0091] (from [6b] and [5]).

[0092] Once Q_ATis known, the terminal queue length Q_ALfor configuration A can be calculated:

[0093] Q_AL=Q_AT*N_A/N_B  [10]

[0094] (from [9] and [8]).

[0095] Once the terminal queue length, Q_AL, is calculated 420, configuration A can be configured 430 to accommodate N_Ausers of configuration A (assuming R_PAequals R_PB). In particular, the throughput, X_A, necessary for the target configuration A can be determined and used to design a particular configuration capable of ensuring that the queue for subsystem configuration A does not exceed Q_AL. The exact calculation of X_Ais dependent on the subsystem being configured and the application at issue. Moreover, the particular implementation of a target configuration A is subject to a variety of design choices beyond the scope of the present invention. What follows, however, is an exemplary outline of preferred considerations for that process, where the target configuration is an I/O subsystem. One of skill in the art could adapt these methods and considerations to other subsystems, such as memory, networking, and CPUs.

[0096] 1. Determine approximate number of I/O transactions/second needed.

[0097] Assume that some fraction of N_A(c/N_A) requests an I/O transaction every second. By the “flow balance assumption” arrivals at a given resource equals completions at that resource for some period of time during the application. Otherwise, the subsystem will become astable. Therefore, if the arrival rate is c/sec, then the throughput for the I/O subsystem, X_A, also equals c/sec. Of course, the flow balance assumption is not always true, and when the arrival rate exceeds the completion rate for a subsystem, a queue begins to form. Accordingly, “c” is derived such that, when the flow balance assumption is violated, the queue at the I/O subsystem does not exceed Q_AL. The derivation of c cannot be simply quantified because it involves empirical knowledge of the application, particularly the so-called “think times” of the application, and the amount of time spent waiting for other system resources. However, one of skill in the art will recognize that for any given application, c can be derived from Q_AL. Because X_Ais defined as c/sec., X_Acan also, therefore, be determined for any given Q_AL.

[0098] 2. Determine number of disk drives needed.

[0099] Knowing the throughput, X_A, required is c/sec, one next determines the number of disk drives required. Every disk drive “i” can handle a set number of disk accesses/second (d_i/sec). “Handling” a disk access means to process it without a queue forming either at the I/O interface level or within the disk sub-system. Importantly, d_i/sec is usually less than the drive manufacturer's rating. The algorithm for determining the number of necessary disk drives is simple and represented by the following pseudo-code:

[0100] temp=c

[0101] drives=0

[0102] while (temp>=0)

[0103] {

[0104] temp=temp−di

[0105] drives++

[0106] }

[0107] In other words, the number of disk drives equals c/di+1, except where c/di produces an integer, in which case the number of disk drives needed equals c/di.

[0108] 3. Determine type of IF

[0109] Typically an interface card (IF) can deliver higher throughput than the number of drives attached to it can provide, so the IF card is rarely the bottleneck within an I/O subsystem. However, I/O throughput is affected by drive RAID (Redundant Array of Independent Disks) configurations as well. Various RAID configurations are possible to provide for data integrity via data redundancy. These RAID configurations increase I/O traffic in the IF, thereby reducing the overall throughput of the IF, and sometimes requiring the use of multiple IF cards where one would otherwise be required. In many cases there is also a limit to the number of drives that an IF can maintain based upon the RAID configuration and card type. Hence, the choice of IF and RAID level somewhat determines the number of disk drives needed to provide the necessary throughput, X_A.

[0110] 4. Determine number of IF cards

[0111] Each interface card, IF, can handle (without a queue forming) a certain number of bytes/sec, denoted here as “t.” From empirical data, the average size of disk accesses for the application of interest is generally known. Therefore, the number of IFs needed can be calculated via the following pseudo-code:

[0112] temp=c*average_size

[0113] interfaces=0

[0114] while (temp>=0)

[0115] {

[0116] temp=temp−t

[0117] interfaces++

[0118] }

[0119] As discussed, these are just some of the considerations that are necessary to design accurately an I/O configuration necessary to provide the appropriate throughput, X_A. Other considerations will be apparent to those skilled in the art.

[0120] Recall that Q_ALand, therefore, X_Awere calculated assuming that R_PAequals R_PB. If that assumption is not correct, and R_PAis different from R_PB, configuration A should be resized to account for the different ramp-up period. In particular, it has been found that the queue length for a particular configuration increases as the ramp-up time decreases. In what follows, the maximum throughput of configuration A, X_A, is used to represent configuration A, itself.

[0121] FIG. 5 illustrates that, for an exemplary I/O subsystem, the faster the ramp-up, the longer the resulting queue. In FIG. 5, the “queue length” depicted in logarithmic form on the y-axis is not necessarily the terminal queue length, it is simply the final queue length after ramp-up, regardless of whether the resulting response time is adequate or not. As shown by line 500 in FIG. 5, if RP_Ais shorter than RP_B, and no further adjustment to configuration A is made, the queue length for the subsystem will exceed Q_AL, resulting in unacceptable user response times. In extreme cases, the entire computer system could even become astable.

[0122] FIG. 6 illustrates the same principle from a different perspective by plotting the increase in the number of users against the natural log of the resulting queue length. FIG. 6 again assumes that RP_Ais less than RP_B. As indicated by the difference in slopes between the two lines 600 and 610, subsystem queue length increases more rapidly for the shorter ramp-up period, RP_A, despite that the same number of users, N_A, are eventually added during ramp-up.

[0123] Since the maximum number of users is N_A, the slope of the line 600 for the RP_Bramp-up is

[0124] m_AL=LN(Q_AL)/N_A.  [11]

[0125] Actually, it has been found that only the second half of ramp-up needs to be modeled; the first half is unstable and violates the assumption that the utilization of the sub-system is 100% (i.e., U_A=U_B=1). Therefore,

[0126] m_AL=LN(Q_AL)/(N_A/2).  [12]

[0127] In order to calculate the final queue length for the RP_Bramp-up, however, the slope of line 610 is calculated. To state the problem more generally, for any ramp-up period RP_ifor configuration A, there is a slope m_i. There is, therefore, some function f, such that

[0128] m_i=f(RP_i).  [13]

[0129] It is assumed for these purposes that f is a linear function (because the increase in the subsystem queue is generally presumed to be exponential). Accordingly,

[0130] m_i=c*RP_i  [14]

[0131] where c is a constant. More precisely, m_iis a function of users-added per minute (or other time quantum), so that

[0132] m_i=k_A*N_A/RP_i.  [15]

[0133] Because users-added/minute is given by N_A/RP_i, then:

[0134] k_A=m_AL*RP_B/N_A.  [16]

[0135] In addition, because all the terms on the right side of equation [16] are known, k_Acan be calculated directly. With a known k_A, m_ican be calculated directly via equation [15]. In other words, the slope of line 610, m_AA, can be calculated for any ramp-up period, RP_Aas follows:

[0136] m_AA=(m_AL*RP_B/N_A)*N_A/RP_A=m_AL*RP_B/RP_A.

[0137] Knowing the slope, m_AA, of line 610, it is simple to determine the final queue length, Q_AA, of configuration A for a given RP_A:

[0138] LN(Q_AA)=m_AA*N_A/2  [17]

[0139] and

[0140] Q_AA=EXP(m_AA*N_A/2)  [18]

[0141] Given both Q_AAand Q_AL, one can derive a throughput factor, T_F, which facilitates re-scaling the configuration X_Ato account for the difference between RP_Aand RP_B. In particular:

[0142] T_F=Q_AL/Q_AA  [19]

[0143] such that

[0144] Q_AL=Q_AA*T_F=EXP(m_AA*N_A/2)*T_F.  [20]

[0145] The new subsystem configuration, X_A′ is then given by:

[0146] X_A′=X_A/T_F.  [21]

[0147] In other words, T_Fis used to resize the configuration A (represented here by its throughput, X_A) to a new size X_A′ such that, in FIG. 6, the final queue lengths for both ramp-up intervals equal Q_AL. Doing so allows application-user response times to remain acceptable despite that RPA is shorter than RP_B.

[0148] Importantly, the response time for configuration X_A′ will not be exactly the same as the response time for configuration X_A. This is because when the throughput of a subsystem is increased, the subsystem is capable of completing more transactions per time quantum. Therefore, although the final queue lengths for both X_Aand X_A′ equal Q_AL, it will take configuration X_A′, with its increased throughput, less time than configuration X_Ato complete Q_ALtransactions. Stated another way, the terminal queue length for configuration X_A′ falls somewhere between Q_ALand Q_AA, although it cannot be calculated directly.

[0149] Accordingly, where RP_Ais shorter than RP_B, the calculation of X_A′ recited above will result in a slightly oversized configuration A (because the queue length will never reach the actual terminal queue length for the resized configuration X_A′). Although this method is not exact, it is significantly more accurate than the “fudge factor” method. Moreover, it is preferable to err on the side of oversizing the subsystem. In the case of an I/O subsystem, for example, exceeding the terminal queue length can result in unacceptable user response times.

[0150] By the same token, however, where RP_Ais longer than RP_B, the calculation of X_A′ recited above will result in a slightly undersized configuration A. When the throughput of a subsystem is decreased, the subsystem is capable of completing fewer transactions per time quantum, thereby increasing the terminal queue length for the configuration. Accordingly, the final queue length may exceed the altered terminal queue length for the resized configuration X_A′. As discussed, although this undersizing may be slight, it is always preferable to err on the side of oversizing the subsystem. As such, it is preferred that the benchmark analysis of configuration B, discussed above, always include a ramp-up period, RP_B, that is greater than or equal to RP_A. In that manner, X_A′ will not be undersized.

[0151] In addition, some exceptional cases require practical limits and/or changes to the method of resizing set forth above. For instance, in some cases T_Fmay be very small, which will result in impractically large subsystem configurations. If, for example, T_F<0.1 for an I/O subsystem configuration, the customer may be asked to either reduce the number of users or increase the ramp-up period, RP_A.

[0152] Further, if Q_ALis very small (e.g., <=2.5), the relationship between queue length and addition of users is presumed to be linear, and not exponential. There is no need to log-transform already-linear data. Accordingly, if the calculated terminal queue length, Q_AL, is below a preset threshold, the equations set forth above can be simplified. In particular:

[0153] m_AL=Q_AL/N_A

[0154] k_A=m_AL*RP_B/N_A

[0155] m_AA=k_A*N_A/RPA

[0156] Q_AA=m_AA*N_A

[0157] and

[0158] T_F=Q_AL/Q_AA.

[0159] It is also recognized that resizing of a computer subsystem for a variable ramp-up period can be accomplished directly, without first calculating Q_AL, where the number of users in the target configuration N_Aequals the number of users in the benchmark analysis, N_B. In that instance, solving for Q_ALis unnecessary, and Q_BLcan be substituted such that:

[0160] T_F=Q_BL/Q_AA

[0161] T_Fis then used to resize configuration B (represented as X_B) directly, such that:

[0162] X_B′=X_B/T_F.

[0163] Referring again to FIG. 4, once subsystem configuration A has been correctly sized for the application of interest, it is preferred that other subsystems are checked 460 to determine whether the resizing in subsystem configuration A has caused a different subsystem to become the system bottleneck. For example, if the throughput of the I/O subsystem is increased by steps 400-450 such that a different subsystem becomes the system bottleneck (or rate-limiting step), steps 400-450 should be repeated 470 for that new bottlenecking subsystem. Whether another subsystem has become the system bottleneck is determined empirically by monitoring (or modeling) the computer system, including the newly configured subsystem configuration A. Once all bottlenecking subsystems have been correctly sized, the overall computer system can be configured 480.

[0164] FIG. 7 is a block diagram of a computer system 700 that can be used to implement the methods embodying the present invention. The computer system 700 includes as its basic elements: a CPU 710 with associated cache memory 720, a main memory 730, and an I/O controller 740. The CPU 710, memory 730, and I/O controller 740 are all connected via a bus structure. The I/O controller 740 (which may comprise a combination of different I/O controllers) controls access to and information from external devices such as a keyboard 750, a monitor 760, permanent storage 770, and removable media unit 780. In addition, the computer system 700 may be connected through a network connection 790 to other computer systems.

[0165] It should be understood that FIG. 7 is a block diagram illustrating the basic elements of a computer system. This figure is not intended to illustrate a specific architecture for the computer system 700 of the present invention. For example, no particular bus structure is shown because various bus structures, and combinations of bus structures, known in the field of computer design may be used to interconnect the elements of the computer system 700 in a number of ways, as desired. The CPU 710 may be comprised of a discrete arithmetic logic unit (ALU), registers, and control unit or may be a single device in which these parts of the CPU 710 are integrated together, such as in a microprocessor. Moreover, the number and arrangement of the elements of the computer system 700 may be varied from what is shown and described in ways known in the art (i.e., multiple CPUs, client server systems, computer networks, etc.)

[0166] Some or all of the method steps described in relation to FIGS. 2-6 can be, but need not be, accomplished via computer system 700. In particular, a program for controlling CPU 710 to perform those method steps can be stored in any of the storage devices 730, 770, or 780, or may be accessed from another storage device and/or CPU via network connection 790 (such as a computer program hosted on an internet web site).

[0167] It will be recognized by those skilled in the art that the methods and apparatus of the present invention can be altered from those particularly described herein without departing from the scope of the present invention. For example, Q_ALcan be utilized without being calculated directly, such as by utilizing some function of Q_ALin its place. In addition, it should be recognized that the present invention can be used with minor modifications to size subsystem configurations for variable ramp-down periods as well. Accordingly, the scope of the present invention should not be limited except by the appended claims.