CN102263659B - 用于计算服务器阵列的容量的方法及系统 - Google Patents

Abstract

本发明涉及服务器阵列容量管理计算器。提供了用于基于诊断数据估计容量的服务器阵列容量计算器系统和方法。例如，一种系统，包括数据库和估计器计算设备，该估计器计算设备包括图形用户界面(GUI)和存储在存储器中并执行在处理器上的容量管理模块，该容量管理模块包括指令用于从不同服务器类型的多个服务器接收诊断数据，经由GUI接收用户输入，并响应于该用户输入以及对于每一服务器类型，从当前服务器效率和已使用的服务器的当前数量计算服务器的当前参考数量；从用户的计划数量和当前并发用户的计数之比计算增长倍数；通过将服务器的当前参考数量与增长倍数相乘产生服务器的计划数量，并在GUI上显示服务器的计划数量。

Description

用于计算服务器阵列的容量的方法及系统

技术领域

本发明涉及计算机系统，尤其涉及服务器阵列容量管理计算器系统和方法。 

背景技术

诸如游戏门户、搜索引擎等许多基于web的应用从服务器场被提供至最终用户。这些服务器场包括不同类型的服务器的阵列，不同类型的服务器被配置为响应最终用户的各种类型的请求。随着服务的用户数量增长，服务器场中的服务器数量也可增长。这样的服务器场的管理员所面对的一个困难是随着用户基础的增长，难以估计将需要多少服务器来满足用户请求的负载。部署的服务器太多是昂贵而且浪费的，而部署的服务器太少则可能导致性能问题，而且使用户不满意，特别是在峰值需求期间。 

发明内容

提供了服务器阵列容量管理计算器系统和方法。例如，提供一种用于基于所观察的诊断数据估计服务器阵列容量的系统，该系统包括数据库和估计器计算设备。估计器计算设备可包括图形用户界面和由处理器使用部分存储器执行的并包括从多个不同服务器类型的服务器接收诊断数据以及经由图形用户界面接收用户输入的指令的容量管理模块。响应于用户输入且对于各服务器类型，容量管理模块可被配置为基于当前服务器效率和已使用的服务器的当前数量来计算服务器的当前参考数量，基于用户的计划数量和当前并发用户的计数之比来计算增长倍数，通过将服务器的当前参考数量与增长倍数相乘产生服务器的计划数量，并在图形用户界面上显示服务器的计划数量。 

提供本发明内容是为了以精简的形式介绍将在以下具体实施方式中进一步描述的一些概念。本发明内容并不旨在标识出所要求保护的主题的关键特征 或必要特征，也不旨在用于限定所要求保护的主题的范围。此外，所要求保护的主题不限于解决在本发明的任一部分中提及的任何或所有缺点的实现。 

附图说明

图1示出了用于根据本发明的实施例计算服务器阵列容量的估计系统。 

图2示出了根据本发明的实施例的图形用户界面。 

图3示出了图2所示图形用户界面的实施例的一部分。 

图4示出了图2所示图形用户界面的实施例的另一部分。 

图5示出了根据本发明的实施例的一种方法的流程图。 

具体实施方式

对基于服务器的网络计算基础结构的预测容量计划可提供一致的用户体验而不管服务规模的改变，诸如当服务增长时。在一些服务场景中，服务使用可与服务器利用率相关。由此，当更多的用户提出不断增长的服务需求时，服务器基础结构可更努力地工作以支持不断增长的需求。此外，需求可能并非均匀地分布在服务器基础结构中；一些服务器类型可能比其他服务器类型更努力地工作。 

例如，在一个场景中，一交互式游戏服务的峰值并发使用负载可被预测为在即将到来的假日周末可能预计有一百万用户，其中估计20%的使用将针对多媒体下载活动，70%将针对玩游戏而10%将针对社交网络。在该场景中，这些活动中的每一个可招致游戏服务的不同的事务成本。事务成本可以在原子级与服务器处理器利用率相关，尽管比如服务器存储器利用率、服务器盘速度以及服务器轮询速率之类的其他事务成本也可以适用。例如，与社交网络活动相比，多媒体下载活动可以具有较大的事务成本，并可以使用更多服务器处理器时间。尽管这些示例性事务成本可根据活动而变化，但在各种活动之间可以具有一致的关系。例如，历史数据可以提供多媒体下载活动和社交网络活动之间的经验关系，使得前者中的增量式活动增长通常转换为后一活动中的相关变化。由此，提供了一种用于基于在服务上所观察到的诊断数据对于计划数量的服务用户计算服务器阵列容量的估计系统。 

图1示出了用于计算服务器阵列容量的估计系统100的实施例。估计系统100包括服务器阵列102、收集器计算设备108、估计器计算设备122、显示器130和数据库112。在一个实施例中，如将在下文中更详细描述的，系统可以实现在在线游戏服务的服务器阵列中。 

服务器阵列102包括多个服务器104。服务器104可根据服务器类型105被安排在服务器阵列102中。例如，在线游戏服务可包括一个或多个用于提供用户化身的化身服务器、一个或多个用于提供在线游戏的游戏服务器、一个或多个用于提供在线零售物品的市场服务器，和/或一个或多个用于提供在线电影的电影服务器。仅举数例，其他示例性服务器类型包括但不限于，在场服务器、游戏应用服务器、web服务服务器、连接服务器、安全网关服务器、统计数据服务器、高速缓存服务器，以及诊断服务器。 

每一服务器104包括诊断程序106，用于收集和/或存储关于服务器使用的各种诊断数据。例如，在一些实施例中，诊断程序106可以收集当前并发用户的计数的数据。在一些实施例中，诊断数据可由包括在诊断程序106中的一个或多个工作计数器模块和/或资源监视模块来检测。 

此外，在一些实施例中，诊断程序106可以测量服务器效率。例如，诊断程序106可以为每一服务器测量规格化的事务效率或处理器效率。 

此外，在一些实施例中，诊断程序106可为每一服务器104收集当前事务速率数据，诸如每单位时间所请求的事务数量的计数和/或每单位时间所提供的事务数量的计数。 

如图1所示，从每一服务器104收集的诊断数据被报告给收集计算设备108。收集计算设备108包括用于收集各种诊断数据并将其存储在数据库112中的收集器程序110。在一些实施例中，收集计算设备108也可以将诊断数据报告给数据库112，诊断数据例如为服务器阵列102内正被使用的每一服务器类型105的服务器104的当前数量以及分配至每一服务器类型105的服务器104的当前数量。例如，诊断数据可包括当前专用于化身服务器的10个服务器的计数。另外地或另选地，在一些实施例中，可为每一服务器类型105计算平均当前处理器最大负载数据，并将其包括在存储于数据库112中的诊断数据中。 

在图1所示的示例中，数据库112为每一服务器类型105，在每服务器的 基础上以每单位时间当前事务的计数的形式，比如每服务器当前每秒事务数（TPS）114、当前处理器利用率116、当前并发用户的数量的计数118，以及使用的服务器的当前数量的计数120，来存储当前事务速录数据。由此，在一个场景中，数据库112的检查可以指示，对于化身服务器类型，每一服务器处理每服务器100TPS；每一化身服务器具有30%的处理器利用率；两百万并发用户当前正在使用该服务；以及有10个化身服务器。数据库112也可对于一个或多个其他服务器类型包含类似数据。 

图形用户界面132被呈现在显示器130上。图形用户界面132接收用户输入134和显示输出142。用户输入134被配置为接收容量计划所基于的一个或多个参数。用户输入134可包括并发用户的计划数量138和/或目标服务器效率136。 

在一些实施例中，用户输入134可包括对应于处理器利用率阈值的处理器阈值输入135。这可以避免服务器缩放“曲棍”行为，该行为指示出处理器利用率和事务请求之间不可预测的关系。例如，尽管运行在处理器阈值输入135以下的服务器可以展示事务速率和用户数量之间的可预测的关系（如线性关系），但是对于许多服务器，在处理器阈值输入135以上的操作可能导致事务速率和用户数量间不可预测的关系，这可能对服务器性能和服务器容量计划产生不利影响。 

在一些实施例中，处理器阈值输入135可根据服务器类型来指定。例如，用户可以指定第一服务器类型的处理器可具有为60%的第一处理器阈值输入，而第二服务器类型可具有为90%的第二处理器阈值输入。另外地或另选地，在一些实施例中，对于第一类型服务器的第一处理器阈值输入的用户指定可使对应于不同类型服务器的不同处理器阈值可通过程序方式来被提供至容量管理模块128。例如，可以知道第一处理器阈值具有与第二服务器类型的处理器阈值的可预测的关系。由此，一个处理器阈值的用户指定可使另一处理器阈值根据该可预测的关系而通过编程方式来被指定。 

在一些实施例中，用户输入134可包括关于容量计划将基于在用户指定的时间/天/日期范围140内（例如，最近30天）或用户指定的日期范围（例如，从3/1/2010到5/1/2010）所收集的诊断数据的一个或多个指定。此外，在一些 实施例中，用户可以指定诊断数据将根据包括在时间/天/日期范围140中的周中的某一天和/或一天里的某一个时间键来进行过滤（例如，使用在周末或某一天晚上所收集的诊断数据，排除在周末的7PM到10PM期间所收集的诊断数据，选择在定义的假期期间所收集的诊断数据，等等）。 

估计器计算设备122包括存储在部分存储器126中的并在处理器124上执行的容量管理模块128。估计器计算设备122从图形用户界面132接收用户输入134，以及从数据库112接收诊断数据，并产生容量计划信息以用于在图形用户界面132上显示。 

响应于接收到用户输入134，容量管理模块128基于当前服务器效率154和已使用的服务器的当前数量120来为每一服务器类型105计算服务器的当前参考数量。在一些实施例中，服务器的当前参考数量可以表示能够服务用户需求的服务器104的理论最小数量。 

在一些实施例中，容量管理模块128可以基于当前处理器利用率116和处理器输入阈值135来估计当前服务器效率154。例如，可以通过将当前处理器利用率116除以处理器阈值输入135来估计当前服务器效率。由此，在10个化身服务器中的每一个的当前处理器利用率为30%而处理器阈值输入为60%的一个场景中，每一化身服务器将具有的当前化身服务器效率为50%。 

在一些实施例中，容量管理模块128可以基于当前服务器效率154和每服务器基础上的当前事务速率数据来估计每服务器当前服务器事务速率阈值。例如，在一些实施例中可以通过将每服务器当前TPS114除以当前服务器效率154来估计每服务器当前服务器事务速率阈值。由此，继续上面所描述的化身服务器场景，如果每一化身服务器处理100TPS并且当前化身服务器效率为50%，那么每化身服务器当前事务速率阈值为每化身服务器200TPS。 

每服务器当前服务器事务速率阈值然后可以被用于计算服务器的当前参考数量。例如，在一个场景中，可以通过将已使用的服务器的当前数量120和每服务器当前TPS114的乘积除以每服务器当前服务器事务速率阈值来计算服务器的当前参考数量。由此，在化身服务器场景中，基于当前使用的10个化身服务器、每化身服务器当前100TPS以及每化身服务器当前事务速率阈值为200TPS，化身服务器的当前参考数量将为5。 

容量管理模块128还基于用户的计划数量138和当前并发用户的数量118之比来计算增长倍数。例如，在一些实施例中，可以通过将并发用户的计划数量138除以当前并发用户8的数量118来计算增长倍数。由此，继续化身服务器场景，如果当前计数为两百万的并发用户计划将增长到四百万并发用户，那么增长倍数将为2。 

容量管理模块128进一步通过将服务器的当前参考数量与增长倍数相乘来产生对于计划数量的并发用户138将部署在服务器阵列102中的服务器的计划数量146。服务器的计划数量146然后经由图形用户界面132被显示在显示器130上。例如，对于以上所描述的化身场景，为满足60%处理器阈值的计划需求所需要的计划数量的化身服务器将为10个化身服务器。由此，用户可以决定不购买另外的化身服务器，因为10个化身服务器已被建立。 

在一些实施例中，容量管理模块128可以基于当前服务器效率154和服务器的计划数量144来估计计划服务器效率。例如，对于以上所描述的场景计划化身服务器效率将为100%。此外，在一些实施例中，容量管理模块128可以经由图形用户界面132显示警告152，警告当前服务器效率154和/或计划服务器效率是在目标服务器效率136以内的或是超出目标服务器效率136一预定义的控制界限137。 

在一些实施例中，容量管理模块128可以基于包括在用户输入134中的处理器阈值输入135、并发用户的计划数量138和增长被修改的处理器估计来计算对于服务器阵列102中每一不同服务器类型105可服务的并发用户的最大数量144。该增长被修改的处理器估计可以基于每一服务器类型的平均当前处理器最大负载数据和增长倍数来产生。并发用户的最大数量144然后可经由图形用户界面132被显示在显示器130上。 

图2中示出了图形用户界面132的示例性实施例。在本示例中，用户已在时间/天/日期范围140指定当在计划将要部署的服务器数量时，3/1/2010和5/1/2010之间的所有天数的诊断数据都将被使用。此外，在目标服务器效率136和并发用户的计划数量138输入处，用户已指定服务器阵列102将运行在60%效率等级并在计划服务器数量所针对的时间服务290万并发用户。 

图形用户界面132还呈现包括服务器的计划数量136、计划处理器负载148 和计划TPS/服务器150的输出142。在一些实施例中，输出142也可以包括并发用户的最大数量144和/或警告152。 

示例性输出142呈现在图2的表1A和1B中，并分别在附图3和4中详细示出。在一些实施例中，输出142可以根据预定优先级来呈现。例如，图3示出了多个优先级标识符301，用于向用户标识一个或多个服务器类型105的服务器104的相对优先级。在图3所示的示例中，根据本示例中有状态和无状态服务器的相对优先级，第一优先级标识符301A（标记为有状态的）优先于第二优先级标识符301B（标记为无状态的）。但是，可以理解，在一些实施例中，可以不同地配置优先级区分或可根本不提供优先级区分。此外，在一些实施例中，相对优先级区分可以是用户可配置的或可以通过程序方式来配置。 

例如，对于每一服务器类型105，图3示出了以下输出：当前服务器效率154（标记为效率）、对分配给每一服务器类型105的服务器104的当前数量的已分配服务器计数302（标记为已分配的服务器）、对所使用的服务器104的当前数量的已使用服务器计数120（标记为已使用的服务器）、在当前服务器以其最满容量被使用的情况下将服务当前负载的服务器的计算出的当前参考数量304（标记为所需的当前服务器）、用于服务计划数量的并发用户138的计划服务器负载的服务器的计划数量146（标记为所需的增长被修改的服务器），以及每服务器当前TPS114（标记为当前TPS/服务器）。如以上所描述的，服务器效率154、已分配的服务器计数302和已使用的服务器计数由诊断程序106确定。 

服务器的当前参考数量304由容量管理模块128来计算，并表示如果组中的每一服务器都以其最满容量被使用那么将用于服务每服务器当前TPS负载的服务器的估计数量。例如，以下等式可以被用于计算服务器的当前参考数量。 

服务器的当前参考数量=“每服务器当前TPS”/“TPS服务器阈值”*“已使用的服务器” 

每服务器当前TPS114通常由配置在每一服务器上的计数器来测量，该计数器测量每秒或每其他单位时间接收到的请求、每秒接收到的批处理请求等。根据以下等式，服务器的计划数量146可以通过首先按等式来计算每秒增长被修改的事务，然后将结果乘以增长倍数来计算。 

每秒增长被修改的事务=“当前TPS/服务器”*“增长倍数” 

服务器的计划数量=“当前TPS/服务器”/“TPS/服务器阈值”*“已使用的服务器” 

现在转向图4，对于表内各行中每一服务器类型105，表1B示出了每服务器计划事务速率148（标记为增长被修改的TPS/服务器）、每服务器当前事务速率阈值402（标记为TPS/服务器阈值）、平均当前处理器最大负载404（标记为当前平均最大CPU）、计划处理器负载148（标记为增长被修改的CPU）、处理器阈值输入135（标记为CPU阈值）、以及并发用户的最大数量144（标记为最大可支持CU）。 

每服务器计划事务速率148可以如以上所描述的对每秒增长被修改的事务来计算。每服器事务速率阈值402可以根据以下公式来计算。 

每服务器事务速率阈值=（“CPU阈值”/“平均最大CPU+1STDEV”）*“当前TPS/服务器” 

其中CPU阈值是对相关服务器类型标识的度量，而当前TPS/服务器是由为服务器类型105的每个服务器部署的计数器测量的每服务器每秒平均当前事务。 

如这里和本发明的其他地方所使用的，平均最大+1标准差（1STDEV）表示某一度量的最大值的平均与同一度量的样本的标准差相加。由此，如以上所描述的，平均最大CPU使用+一个标准差表示在已观察的时间段中的平均最大CPU使用+一个标准差。例如，如果五个服务器的最大CPU使用为50%、55%、50%、50%和75%，那些服务器的平均最大CPU使用将为56%而那些服务器的最大CPU使用的标准差将大约为10.8%，使得平均最大CPU使用+一个标准差将大约为66.8%。该方法可以提供比替换方法更好的利用率度量，替换方法例如为将利用率设定为那些服务器的绝对最大CPU使用的定义比例（在一些示例中例如为95%）。例如，对于以上所描述的五个服务器，绝对最大为75%，因而绝对最大的95%为（在本示例中，75%的95%大约为）71.2%。由此，可以理解，可能是离群值的值75%，按照平均最大+一个标准差的方法比按照绝对最大的定义比例的方法对利用率度量造成的偏斜更小。但是，可以理解，平均最大+一个标准差的方法仅是一个示例性方法，而且其他适当的示例（包括绝 对最大的定义比例的方法）可以用于本实施例的范围内。 

平均当前处理器最大负载404（标记为当前平均最大CPU）可以根据以下等式来计算： 

当前平均最大CPU=“处理器、%处理器时间、总数”的最大值的平均+1STDEV， 

其计算了所测量的处理器使用、处理器时间的最大值的平均，并加在相关测量的一个标准差的所选平均上。 

计划处理器负载148（标记为增长被修改的CPU）可以计算如下： 

增长被修改的CPU=“当前平均最大CPU”*“增长倍数”， 

其中当前平均最大CPU和增长倍数如以上所描述的来计算。 

处理器阈值输入135（标记为CPU阈值）通常为由用户输入至图形用户界面132的处理器阈值输入域中的值，如图2所示，其指示了所需的最大处理器效率，用户希望服务器阵列中特定服务器类型的服务器运行在该最大处理器效率上。可以理解，处理器阈值输入135对于每一服务器类型105可以不同，例如如表1B的第一行和第二行中不同的处理器阈值输入值所示。 

并发用户的最大数量144可以由容量管理模块128根据以下等式来计算。该值表示在每一服务器以其最满容量来被使用的情况下计划数量的服务器能够支持的用户的最大数量。 

最大可支持并发用户=“在该时间段内的最大并发用户”/“所需的当前服务器”*“已使用的服务器”。 

图5示出了用于为不同服务器类型的服务器阵列计算服务器阵列容量的一种方法500的实施例。例如，在一个场景中，服务器阵列中的服务器类型可以包括化身服务器、游戏服务器、市场服务器或电影服务器中的两种或更多。尽管方法500在以下参考以上所描述的硬件和软件来描述，但可以理解的是，方法500可以使用任何适当的硬件和软件来实现。 

方法500包括，在502，在执行于估计器计算设备上的容量管理模块处，经由图形用户界面接收用户输入，该用户输入包括用户的计划数量。 

在一些实施例中，在502处接收用户输入可包括，在504，经由图形用户界面接收日期范围输入、周中的某一天输入、一天里的某一个时间输入、并发 用户的计划数量输入、预定义控制界限输入、目标服务器效率输入和/或处理器阈值输入。 

在506，方法500包括从服务器阵列中的不同服务器类型的多个服务器接收诊断数据。对于每一服务器类型，诊断数据可以包括已使用的服务器的当前数量、当前并发用户的计数和当前处理器利用率数据。例如，在一个场景中，诊断数据可以由执行于服务器阵列中每一服务器上的工作计数器模块和/或资源监视模块来检测，并存储在数据库中。 

在一些实施例中，在506处接收诊断数据可以包括，在508，针对日期范围输入、周中的天输入和/或一天中的时间输入过滤诊断数据。 

在510，方法500包括，响应于用户输入以及对于每一服务器类型，基于当前服务器效率和已使用的服务器的当前数量来计算服务器的当前参考数量。 

在一些实施例中，在510处计算服务器的当前参考数量可以包括，在512，基于当前服务器效率和当前事务速率数据估计当前服务器事务速率阈值。例如，在一个场景中，当前事务速率数据可以包括每单位时间所请求的事务数量的计数和/或每单位时间所服务的事务数量的计数。 

在514，方法500包括，响应于用户输入以及对于每一服务器类型，基于用户的计划数量和当前并发用户的计数之比计算增长倍数。 

在516，方法500包括，响应于用户输入以及对于每一服务器类型，通过将服务器的当前参考数量与增长倍数相乘产生将为计划数量的用户部署在服务器阵列中的服务器的计划数量。 

在一些实施例中，方法500可以包括，在518，基于包括于用户输入中的处理器阈值输入、用户的计划数量和增长被修改的处理器估计来计算对于服务器阵列中每一不同服务器类型能够被服务的并发用户的最大数量。例如，在一个场景中，增长被修改的处理器估计可以基于每一服务器类型的平均当前处理器最大负载数据并基于增长倍数来产生，其中平均当前处理器最大负载数据包括在诊断数据中。 

继续，在520，方法500包括在图形用户界面上显示服务器的计划数量。在一些实施例中，方法500可以包括，在522，在图形用户界面上显示并发用户的最大数量。 

以上所描述的系统和方法可以被实现来高效地管理服务器阵列的容量计划，从而满足服务器负载期望，同时潜在地避免了服务器资源的过部署或部署不足。 

可以理解，此处所描述的计算设备和服务器可以是被配置成执行此处所描述的程序的合适的计算设备。例如，计算设备可以是大型计算机、个人计算机、膝上型计算机、便携式数据助理（PDA）、启用计算机的无线电话、联网计算设备，或其他合适的计算设备，并可以经由诸如因特网等计算机网络彼此连接。这些计算设备通常包括处理器和相关联的易失性和非易失性存储器，以及诸如硬盘驱动器等大容量存储设备。这些计算设备被配置为使用部分易失性存储器和处理器来执行存储在非易失性存储器中的程序，以实现此处所描述的功能。例如，计算设备可以配置有比如键盘、鼠标和触摸屏之类的用户输入设备，并进一步可以配备有显示器。 

此外，如此处所使用的，术语“程序”和“模块”表示可以由此处描述的一个或多个计算设备执行或利用的软件或固件组件，并且意味着包括下述一项或多项：可执行文件、数据文件、库、驱动程序、脚本、数据库记录等。可以理解，可提供具有存储在其上的程序指令的计算机可读介质，当由计算设备执行时，所述指令使得计算设备执行上述方法，并且使得上述系统工作。计算机可读介质可以包括存储器设备，例如随机存取存储器（RAM）、只读存储器（ROM）、硬盘、紧致盘（CD）、数字视频盘（DVD）等。此处所描述的程序和模块中的一些或全部可以是软件模块或硬件组件，例如存储器设备。 

可以理解，如此处所使用的“服务”可以是在多个用户会话之间可执行的应用程序，而且对于其他操作系统组件和应用来说是可用的。服务可以响应于客户端的请求而运行在服务器上。 

应该理解，此处所述的配置和/或方法在本质上示例性的，且这些具体实施例或示例不是局限性的，因为多个变体是可能。此处所述的具体例程或方法可表示任何数量的处理策略中的一个或多个。由此，所示出的各个动作可以按所示顺序执行、按其他顺序执行、并行地执行、或者在某些情况下省略。同样，可以改变上述过程的次序。 

本发明的主题包括各种过程、系统和配置的所有新颖和非显而易见的组合 和子组合、和此处所公开的其它特征、功能、动作、和/或特性、以及其任何和全部等效物。 

Claims (11)

1.一种用于计算服务器阵列容量的估计系统，包括：

数据库，用于存储由执行在服务器阵列的每一服务器上的工作计数器模块和资源监视模块所检测的诊断数据；以及

估计器计算设备，包括图形用户界面和容量管理模块，所述容量管理模块被配置成：

从服务器阵列中的不同服务器类型的多个服务器接收诊断数据，对于每一服务器类型，所述诊断数据包括已使用的服务器的当前数量和当前并发用户的计数；

经由所述图形用户界面接收用户输入，所述用户输入包括用户的计划数量；以及

响应于所述用户输入以及对于每一服务器类型：

基于当前服务器效率和所述已使用的服务器的当前数量来计算服务器的当前参考数量，

基于所述用户的计划数量和所述当前并发用户的计数的比率来计算增长倍数，

通过将所述服务器的当前参考数量与所述增长倍数相乘，产生对于所述计划数量的用户将被部署在所述服务器阵列中的服务器的计划数量，以及

在所述图形用户界面上显示所述服务器的计划数量。

2.如权利要求1所述的系统，其特征在于，所述容量管理模块还被配置成基于所述当前服务器效率和包括在所述诊断数据中的当前事务速率数据来估计当前服务器事务速率阈值。

3.如权利要求2所述的系统，其特征在于，所述当前事务速率数据包括每单位时间所请求的事务数量的计数和/或每单位时间所服务的事务数量的计数。

4.如权利要求1所述的系统，其特征在于，所述诊断数据还包括当前处理器利用率数据，所述诊断数据由执行在所述服务器阵列中的每一服务器上的工作计数器模块和资源监视模块来检测并被存储在数据库中，所述用户输入还包括处理器阈值输入，所述容量管理模块还被配置成基于所述当前处理器利用率数据和处理器阈值输入来估计所述当前服务器效率。

5.如权利要求1所述的系统，其特征在于，所述服务器阵列中的服务器类型包括以下中的两种或多种：提供用户化身的化身服务器、提供在线游戏的游戏服务器、提供在线零售物品的市场服务器、提供在线电影的电影服务器、在场服务器、游戏应用服务器、web服务服务器、连接服务器、安全网关服务器、统计数据服务器、高速缓存服务器，以及诊断服务器。

6.如权利要求1所述的系统，其特征在于，所述容量管理模块进一步配置成经由所述图形用户界面接收日期范围输入、周中的天输入和/或一天中的时间输入，所述接收所述诊断数据包括针对所述日期范围输入、周中的天输入和/或一天中的时间输入过滤所述诊断数据。

7.一种用于计算服务器阵列的容量的方法，包括，在估计器计算设备中的容量管理模块处：

从服务器阵列中的不同服务器类型的多个服务器接收诊断数据，对于每一服务器类型，所述诊断数据包括已使用的服务器的当前数量和当前并发用户的计数；

经由图形用户界面接收用户输入，所述用户输入包括用户的计划数量；以及

响应于所述用户输入以及对于每一服务器类型：

基于当前服务器效率和所述已使用的服务器的当前数量来计算服务器的当前参考数量，

基于所述用户的计划数量和所述当前并发用户的计数的比率来计算增长倍数，

通过将所述服务器的当前参考数量与所述增长倍数相乘，产生对于所述计划数量的用户将被部署在所述服务器阵列中的服务器的计划数量，以及

在所述图形用户界面上显示所述服务器的计划数量。

8.如权利要求7所述的方法，其特征在于，还包括基于所述当前服务器效率和包括在所述诊断数据中的当前事务速率数据来估计当前服务器事务速率阈值。

9.如权利要求8所述的方法，其特征在于，所述当前事务速率数据包括每单位时间所请求的事务数量的计数和/或每单位时间所服务的事务数量的计数。

10.如权利要求7所述的方法，其特征在于，进一步包括经由所述图形用户界面接收日期范围输入、周中的某一天输入和/或一天中的某一时间输入，接收所述诊断数据包括针对所述日期范围输入、周中的天输入和/或一天中的时间输入过滤所述诊断数据。

11.如权利要求7所述的方法，其特征在于，所述诊断数据还包括当前处理器利用率数据，所述诊断数据由执行在所述服务器阵列中的每一服务器上的工作计数器模块和资源监视模块来检测并被存储在数据库中，所述用户输入还包括处理器阈值输入，所述方法还包括基于所述当前处理器利用率数据和处理器阈值输入来估计所述当前服务器效率。

Images