CN102576311A - 用于通过优化性能模型提高软件执行时间的方法和系统 - Google Patents

Abstract

提供了一种表示应用在不同的系统资源条件下的行为的性能或可靠性模型。此模型可为一个或多个稀疏矩阵的形式，其提供了用于不同条件组合的可靠性或性能值。此模型被分发给应用的用户，并在应用执行期间参考由操作系统或其他监测软件提供的系统资源信息咨询该模型，以提供在当前操作条件下应用的预期性能的指示。此指示例如在该指示落入预定的满意操作界限以外的情况下可以通知给用户。系统也可尝试重新协商分配的系统资源以提高性能。

Description

用于通过优化性能模型提高软件执行时间的方法和系统

技术领域

本发明涉及一种用于根据软件片段可用的资源来管理该软件片段的行为的方法和系统。

背景技术

根据设计阶段认可的功能测试(FVT)案例的结果来预测在客户生产环境中的应用的确切行为是极其具有挑战性的，即使其合并在软件开发实验室中普遍使用的附加测试(容量规划、系统测试)中。最可能的是这种测试案例从功能的观点鉴别有意义的测试，但是其是在与生产阶段的确切客户执行环境不可能匹配的操作条件下执行的。大量应用解决此问题的广泛使用的方法是所谓的“容量规划”或“性能负载”测试，其中应用的一些特定(例如准确的硬件资源需求)和有关的(例如可靠性)方面在不同的场景中测试。在这些场景中，操作环境与“理想”测试案例不同，因为在客户端生产期间对于软件应用可用的计算资源量不可预知：在真实条件下，应用经常部署在大群集数据中心中，且其调度与其他并发应用一起发生，这样可用资源中可发生相当大的改变。这些是应用可用的计算资源相比于理想的单机系统或模拟测试可能改变的一部分原因。期望“容量规划”比当前可能的提供更精确的预测：当前最好的实践是容量规划阶段的结果是应用在最坏条件下正确操作所需的硬件需求的定义。换句话说，“性能负载”或“容量规划”工具经常提供正确运行所需的操作资源的测量，即从功能的观点在“最坏情况”下。

US5655074描述了一种用于大型软件系统的系统工程的软件工具。该处理开始于步骤：针对每个可唯一识别的软件组件，收集关于软件系统的大量特征的观测数据(包括历史的和计划的系统调节)。还收集的是关于每个软件组件的缺陷或问题的历史数据。缺陷数据统计地映射至软件的测量特征，以建立风险指数。风险指数可用作建立预测软件性能的软件特征的预测工具，或者备选的，风险指数可用于为组件排序，以确定哪些组件在努力节省资源的情况下需要较少测试。

发明内容

如所讨论的，致力于识别最小系统需求的现有技术的测试技术是静态的方式。本发明的目的在于当应用在客户端环境中执行时，动态地提供关于应用的预期性能的信息。

根据本发明，提供了一种如所附独立权利要求1的优化软件执行的方法，如所附权利要求12的设备、如所附权利要求13的计算机程序、如所附权利要求14的性能模型以及如所附权利要求15的计算机可读介质。进一步优选的实施例在从属权利要求中定义。

通过查阅附图和详细描述，本发明的优点对于技术人员将变得清晰。其用意在于任何附加的优点也包含于此。

附图说明

本发明的实施例现将通过参照附图的示例的方式描述，在附图中相似的标记表示相似的元件，其中：

图1示出了本发明的第一实施例的步骤；

图2示出了形式为多维空间200的性能模型的示例；

图3示出了形式为多维空间300的性能模型的另一示例；

图4示出了本发明的第二实施例的步骤；

图5示出了本发明的第三实施例的步骤；以及

图6示出了适于实施某些实施例的计算机环境。

具体实施方式

提议结合性能模型将应用构建(设计、实施和组装)以及部署到操作环境中。该性能模型可以利用具有附加测量的应用测试过程来实现，其中附加测量专注于以关于该应用的特定范围优选为不可知的方式使得执行环境可用的资源，从而使其可应用于最大可能数量的应用。

图1示出了本发明的第一实施例的步骤。如图所示，该过程开始于步骤100，继续进行至步骤110，在该步骤110提供了例如以下将进一步详细描述的性能模型。在步骤120，执行与性能模型相关的应用，在步骤130，从例如操作系统或其他监测软件或硬件接收用于定义该模型的系统资源测量。在步骤140，该测量用于从性能模型中提取对应于所述测量的性能值。在步骤150，确定该应用是否已结束，在这种情况下该过程在步骤160结束、或者该过程返回至步骤130，使得只要该应用可运行，过程就继续根据监测的系统资源的可用性来监测软件的性能水平。相应地，提供了一种在执行软件的系统中优化所述软件的执行的方法，包括以下步骤：提供代表不同系统条件下所述软件的性能的性能模型，其中系统条件以一个或多个预定系统资源来描述，接收给定时刻的每个预定系统资源的测量，以及从所述性能模型中提取对应于所述测量的性能值。在本说明书中使用的短语“性能”可以反映软件应用的任意期望行为。根据优选实施例，讨论中的性能标准为软件的可靠性。

举例来说，例如作为操作环境的WebSphere应用服务器、Tomcat、JBoss等的应用服务器，和作为应用的J2EE应用，资源(cpu、存储器、磁盘空间、虚拟存储器等)将被识别并在形式上定义，因为资源也可与硬件资源在逻辑上且非直接地相关，例如由应用服务器使得对于J2EE应用可用的那些资源以及可以以编程方式使得可用的那些资源。

一组固定的可用计算资源(例如1GB RAM、100GB磁盘空间、400套接字等)可以视为NR维空间中的应用操作点，其中NR是指与性能测量有关的选定计算资源(在托管(hosting)环境中定义的计算资源的子集或全集)的数量。“性能模型”根据应用的每个功能测试案例来计算，使得其将允许每个应用操作点提供应用性能的数字形式测量(与相同软件的其他版本或相同软件的其他部署可比较)：这是如何获得的将在实施部分详细解释。

表达性能模型信息的人为结果可以是一个或多个矩阵，经常为稀疏矩阵，其中每个轴将与用于性能计算的一个计算资源相关联，并且每个单元将表示在正常化以后例如死机、服务质量的失误、异常、超时等“问题”发生的概率。每个这种“问题”优选地在形式上定义为条件，例如依照日志文件中文字的匹配、CIM信息模型上的布尔表达式等。

根据某些实施例，性能模型可包括一组NM个不同矩阵，每个矩阵与特定定义的问题相关或根据附加标准甚至不同，例如涉及相同“问题”定义但针对不同平台。

根据某些实施例，性能模型通过对软件测试而进行填充。此软件的测试可包括在配置了系统资源的每个预期组合的系统中重复执行该软件，以及汇编与在该配置下发生的行为有关的统计数据。可如此测试的系统资源的一个示例为系统存储器，系统或应用死机的发生可以用作用于统计数据基础的正式测量，其例如使用监听windows事件日志的日志监测软件来确定。可以在多种存储器条件中测试单个测试案例以将关于计算资源利用率的、软件程序的存储器消耗量“个性”或非功能性“方面”简档进行分类，在此示例中，计算资源是存储器，但是相同的方法可应用至套接字、cpu单元等。可预料的是，当可用存储器下降至某水平以下时测试案例将易于失败，这在真实环境下可能发生，因为其他应用正在消耗存储器。

有利的是，通过允许经由程序接口来配置其计算资源的操作/执行环境，可以执行重复的测试。一个示例可以为虚拟机，其可以利用不同的资源参数顺序地重启。在这种环境中，根据要测试的参数重新定义存储器、处理器的数量或可用套接字的数量非常简单。从多个测试执行得到的全部结果可以用于估计失败的平均概率，例如依照坏执行的测试案例的数量比上全部测试案例的数量，和/或其发生率的方差。

如果测试条件由多维空间中的点来标识，其中每个坐标轴为一个计算资源。最后，对于每个测试条件，可以估计具有平均参数值和方差参数值的概率密度分布(pdf)并可与每个点相关。当测试案例重复的数量超过阈值(阈值本身可以使用显著性测试分析来计算)时，例如1000，可假设正态(高斯)pdf。估计的平均中值和方差可在运行时应用，以用于动态估计在根据可用计算资源的当前操作条件下，相同应用发生应用失败的概率。

图2示出了形式为多维空间200的性能模型的示例。具体如所示，X轴210和Y轴220对应于可用CPU和可用存储器，原点在左下方。同时z轴230表示错误的可能性。错误的可能性优选为正态化，从而在标准条件下给出错误的可能性，其中错误的可能性可表示错误在预定周期、循环次数、迭代次数等内发生的百分比机会。如图2中所示，定义了由对应于值的密集矩阵的一系列点241构成的表面240，使得对于一组定义的规律间隔的X和Y轴值的每个组合，存在一个错误的可能性值。X轴值和Y轴值之间的间隔可以选择以对应于来自操作系统或其他系统监测软件应用的测量的粒度，使得检测软件的输出可以直接被映射到错误的可能性值。X轴值和Y轴值之间的间隔可以选择成比来自操作系统或其他系统监测软件应用的测量的粒度小得多，以使对于来自监测软件的任意输出来说，都将有一个与测量值只有非常短距离的x-y组合，其可以直接地用于提供错误的可能性值的接近近似值。此方法的优点在于其不取决于特定的操作系统或监测软件，使得该模型可以用于很广的不同环境范围。X轴值和Y轴值之间的间隔可以选择在任意便利值，例如使得任意两个临近点之间的z轴值的变化不超过预定余量。当来自操作系统或其他系统监测软件应用的测量落入一些x-y值组合之间时，可以对附近的点进行插值以估计用于所测量值的值。根据某些实施例，不是将表面存储为一组点，而是整个表面的形状可以被插值以能够推导出描述该整个表面的函数，从该函数可以根据需要推导出对于任意x-y组合的错误的可能性值。此方法的优点在于其可以需要更少的存储空间。

图3示出了形式为多维空间300的性能模型的另一示例。X轴210、Y轴220和z轴230与参照图2描述的对应。如图3所示，其定义了表面340，其由对应于值的稀疏矩阵的一系列点341组成，使得对于选定的X和Y轴值的组合具有错误的可能性值。一般地，与图2的方法相比，根据图2的实施例的性能模型将包含用于相似信息量的更少的数据，或者用于等量数据的更多的信息。每个点之间的距离可以选择成比来自操作系统或其他系统监测软件应用的测量的粒度小得多，以使对于来自监测软件的任意输出来说，都将有一个与测量值只有非常短距离的x-y组合，其可以直接地用于提供错误的可能性值的接近近似值。此方法的优点在于其不取决于特定的操作系统或监测软件，使得该模型可以用于很广的不同环境范围。X轴值和Y轴值之间的距离可以选择在任意便利值，例如使得任意两个临近点之间的z轴值的变化不超过预定余量。当来自操作系统或其他系统监测软件应用的测量落入一些x-y值组合之间时，可以对附近的点进行插值以估计用于所测量值的值。根据某些实施例，不是将表面存储为一组点，而是整个表面的形状可以被插值以能够推导出描述该整个表面的函数，从该函数可以根据需要推导出对于任意x-y组合的错误的可能性值。

虽然图2和图3示出了表示用于两个系统条件变量的组合的错误可能性率的三维表面，但将意识到的是以上讨论的所有方面可扩展至任意数量的系统条件变量，即具有多于三维的空间。因此，该模型可包含多组不同的性能值，每组与所述测量的一些或全部有关。预定系统资源可包括可用系统cpu容量、可用系统存储器、可用系统磁盘或可用网络套接字中的至少一个。

如上参照图2和图3所述，可提供确定性能模型是否包括精确对应于所述测量的性能值的步骤，并且在性能模型不包括精确对应于所述测量的性能值的情况下，从所述性能模型中提取出分别对应于一个或多个最接近可用测量值的一个或多个邻近性能值。或者，可以提供进一步地步骤以根据所述邻近性能值对性能值进行插值。

一个重要的优点在于“性能模型”可以是针对应用的超出其常规功能方面的行为方面的正式且科学的(因此在应用和系统间可比较)文件。此改变打开了本公开的大量可能应用领域。

可意识到的是，根据本发明的性能模型可促进相似产品能力的比较。为了使其可行，不同的产品理论上应当使用共享的用于测量性能的性能语句(statement)的定义以及组成空间的轴的资源定义。这应当至少在相同产品的不同版本之间是可能的，甚至不同品牌之间也是可能的。

图4示出了本发明的第二实施例的步骤。图4的过程与图3的相同，但是详细阐述了提供性能模型的步骤110的某些示例性子步骤。更具体地，图4示出了一种创建这种性能模型的可能的方法。如所示，在子步骤110中定义的过程开始于步骤411，由此测试系统的资源被配置用于测试执行的目的。如上讨论的，其可以以多种方式实现，取决于测试系统本身的性质，例如通过适当地配置虚拟机、应用服务器等。接下来，该过程进行至步骤413，在该步骤期间监测应用并且记录任何错误。一旦该应用已经运行至结束、或者通过预定的测试序列、或者经过预定时间周期，过程进行至步骤415，在该步骤处考虑应用是否已经在汇编性能模型所需的每个不同测试系统配置下执行过。如果没有，则该过程返回至步骤411，在该步骤测试系统被设置为下一个所需的配置，以使该过程在每个所需的配置中依次循环。如果该应用已经在汇编性能模型所需的每个不同测试系统配置下执行过，则该过程进行至步骤416，在该步骤处由步骤415的每个迭代所记录的错误连同针对每个相应错误的系统配置一起被大批处理，以如上所讨论的来汇编性能模型。一旦性能模型被及时汇编，则其可与应用的拷贝一起、或者以其他方式分发给应用的用户，于是过程如上所述的在步骤120重新开始。

优选地，按如下产生性能模型计算：借助于迭代式改变由应用服务器使得可用于每个应用的资源并通过简单地计数在该点通过的成功测试(其为通过一些质量标准的执行测试)来追踪该点的“性能”，从而(利用开发组中广泛可用的测试自动化技术)自动执行大数量的测试。

作为应用服务器的替换方式，相同的过程可以应用于每个托管环境中，在该托管环境中，专用于应用的资源可以以编程方式设置或控制。

此过程将推导在不同操作条件下该应用的行为图。

根据图4的步骤的进一步改进，或者以其他方式，可以实现以下步骤来定义性能模型：

1)识别覆盖应用功能的测试案例列表

2)识别要考虑的逻辑资源列表，例如：cpu单元、存储器、磁盘、套接字等

3)识别质量定义列表：“问题”被定义为不满意的质量测量(在系统或应用日志中、来自内部/外部监测的性能结果中、性能指令等中遇到某些关键字)。至少此定义可与利用商用平台中的商用监测软件可监测的内容相匹配(细节可在列举软件包和平台时提供)。

4)识别并编纂逻辑资源如何被绑定至物理和操作系统资源(在最简化的情况中可以为一对一)，这是为了更好地与监测软件交互操作，最好的是基于一组从商用资源监测包直接可用的测量、以其原本的形式计算性能测量。应用可以公开几个用于一种预测“失败/问题”的矩阵(例如用于不同平台、或用于所支持的不同监测软件)。

5)将每个资源视为多维空间r(1...NR)的轴。每个单元从0开始。

6)在多维的每个轴上以某粒度水平选择一些采样点，并将采样空间以整数值失败_空间[i1][i2]...[iNR]的NR维稀疏矩阵表示。

7)将由此得到的测试点汇编成列表，其中每个点来源于步骤1)中的单个测试案例，并通过用于每个给定单个测试场景的应用输入参数的蒙特卡罗变体来获得。

8)对在步骤6)选择的所有的采样点执行步骤7)所汇编的每个由此得到的测试点，每次根据由采样点和收集的结果(失败或没有失败)所识别的资源矢量来改变可用于应用的资源(资源上下文矢量)：每个失败/问题结果使对应的矩阵单元(从0开始)中的值增加。在第1)点为每个测试案例重复该过程。

9)估计由此得到的失败模型参数，其用于“失败空间”的每个点，根据如下过程估计失败的概率：递增地对在每个测试案例在失败空间[i1][i2]...[iN]的单元中的某个资源条件(资源上下文)中运行时发生的失败/临界条件/漏洞的数量求和(从0开始)，该失败空间表示测试案例执行的资源上下文。

优选地，由此得到的性能模型在分发之前填充，该性能模型与软件一起分发，例如通过封装在与其所提到的应用一起部署的文档中。或者该模型可通过单独的通道发送，例如通过网络等下载。

然后，性能模型在执行时间时使用，例如与资源监测或资源预测(借助于历史数据)软件一起使用。

执行环境加载该应用，并获取其可靠性模型，执行环境的一组计算资源被指定为将由选定的资源预测/监测软件所预测/监测。

然后，这组被预测/监测的资源用于将对应于资源空间中的点的值的矢量进行组合，其可以用作资源上下文矢量。通过读取模型中的值或者从模型中最接近的可用点进行插值，资源管理器访问可靠性模型并取回对资源上下文矢量所识别的点可用的可靠性值。

图5示出了本发明的第三实施例的步骤。图5的处理与图3的相同，但是其详细地阐述了步骤140和150之间的某些进一步的步骤。更具体地，图5示出了一种使用在步骤140从性能模型提取出的性能值的方式。如所示，在步骤140之后不是直接进行至步骤150，而是该过程进行至步骤541，在该步骤，确定在步骤140提取出的性能值是否降低至预定阈值以下。根据本实施例，此预定阈值表示可接受的性能水平。此阈值可以为与该应用、特定用户账户、特定机器、该应用执行的一天中的时间等特别关联的值。也可定义应用的层级，这样用于特定应用的阈值由其在该层级中的位置所定义，这样更重要或紧急的应用可以考虑为更不容忍错误，因此为这些应用设置更低的阈值。如果发现性能水平在阈值之上，则表示根据性能模型，该应用在当前操作条件下表现应当令人满意，则该过程如上所述地进行至步骤150。另一方面，如果发现性能水平低于或等于该阈值，则表示根据性能模型，该应用在当前操作条件下表现不令人满意，例如死机的可能性大于某个值，则过程进行至步骤542。在步骤542，该过程执行步骤以减轻与应用预期的不良性能关联的问题。举例来说，例如通过弹出窗口、邮件等，系统可以自动向应用的用户、系统管理员或其他个体报警预期的不良性能。系统也可以通过寻找以获得另外的资源，例如通过重新定义操作环境本身、或关闭不太重要的应用或过程，从而自动采取步骤来重新调整情形。相应地，提供了当所述性能值下降至预定阈值以下时向用户报警的步骤，或者在所述性能值下降至预定阈值以下时，尝试自动地协商用于所述软件的来自所述系统的增长的资源分配。

作为以上的进一步发展，可以想象系统可能正在执行多个与根据本发明的性能模型相关联的应用。在此情况下，系统可以尝试以优化整体性能的方式将系统资源分配至不同的应用。

2)然后，这组被预测/监测的资源用于将对应于资源空间中的点的值的矢量进行组合，其可用作上下文资源矢量：

3)给定预测的上下文资源矢量和性能模型，针对该给定的上下文可以获得失败/问题的概率。

4)在此阶段，管理员可固定一阈值，使得如果该系统超过该值，则资源管理员可发起一些动作以阻止那些可能的问题，包括：

a)通知管理员

b)例如通过与供应系统交互，再分配/提高可用于应用的资源(移动至不同的群集节点)

c)自动提高系统记日志的频率，和/或多样性(如果信息类型被记录)。

根据另一实施例，提供了一种性能或可靠性模型，其表示应用在不同系统资源条件下的行为。此模型可采用一个或多个稀疏矩阵的形式，其提供了针对不同条件组合的可靠性或性能值。此模型被分发给应用的用户，并在应用执行期间参照由操作系统或其他监测软件提供的系统资源信息，咨询该模型以提供在当前操作条件下对应用的预期性能的指示。例如在该指示落入满意操作的预定界限之外时，该指示可以通知给用户。该系统也可尝试重新协商所分配的系统资源以提高性能。

可注意到的是，在某些真实世界中，在不同的操作条件下的应用性能可能变化。根据某些实施例，测试不同的测试情景可以设计为测试软件性能的不同方面。这种情景可重新产生一般的系统事件，例如“向系统注册新用户”。同样地，性能模型也可被构造为使其包括分别与软件性能的不同方面有关、或与不同的使用情景对应的多个子部分。有利地，这些方面和/或使用情景可对应于在测试阶段中使用的诸方面/测试情景。这些方面可以表示为独立的性能空间。当由此构造性能模型时，通过例如可描述情景或者情景的子部分的“标签”，可以期望将性能模型的不同方面与不同的情景相关联。因此描述情景或情景的子部分的一种方式可以依照与其关联的工作负荷，因为不同的工作负荷水平将导致独立的性能“空间”。如下表中所示，性能模型包含对应于系统事件“向系统注册新用户”的性能空间，以及对应于1-20个用户连接至系统的情况的性能子空间、以及对应于21至100个用户连接至系统的另一种情况的性能子空间，这是基于该系统在这两种负载情景下将具有不同的行为。

根据使用如上所述的多空间性能模型的某些实施例，提供了一个输入特征元件，其监听应用的输入通道以提供当前输入条件的特征，并从此分类中选择表示此性能行为的最合适的多维空间。

根据优选实施例，每个测试案例在利用一些例如蒙特卡洛的技术自动测试之前被扩展，从而提供足够的样本以计算选定案例的统计分布。特别是，在配置了每个期望的系统资源组合的系统中测试软件的步骤，优选地包括以随机或伪随机的方式定义期望的系统资源组合。更优选地，由期望的测试条件组合构成的期望的系统资源组合借助于例如系统资源参数之类的测试参数的蒙特卡洛变体而定义。

进一步地，测试案例步骤的诸方面本身可以借助于种子案例的随机、伪随机、或蒙特卡洛变体来定义。例如，一般的测试案例可以包括提供作为某个应用的输入而给出的输入参数，应用例如是′创建新用户′过程，其要求例如姓和名之类的参数。

系统资源可以在16个条件的不同容许排列之间变化，例如改变3个可用存储器点(10MB 100MB 1000MB)和3个可用的CPU单元操作点(10％50％90％)。

但是可以意识到的是，在一些情况下，以参数的特定组合的单个测试可能不能提供软件行为的可靠表示。例如，软件的行为、或者更具体地取决于某些资源的可用性的方式，其可能取决于测试案例本身的细节。例如，在如上提出的′创建新用户′的过程中，可能是这样的情况：系统可能根据在测试案例中使用的名字，在系统资源上进行不同划分。

因此，基于一些重复的相同的恒定测试案例上测量的软件行为来得出结论是不可靠的。对应地提出引入一些或全部测试案例的细节的改变，从而确保在软件资源与使用的数据的细节无相关性时，每个测试案例恰当地测试了选定的方面。

在本示例的情况下，不是针对′创建新用户′过程使用固定的用户名，而是可以为每个新的测试案例迭代产生随机或伪随机产生的用户名，使得通过收集在大量迭代上的软件性能测量，可以排除任意与特定测试数据关联的异常点。

因此在本示例中，′创建新用户′过程可执行例如1000次，每次使用不同的用户创建参数，例如从名字词典中(随机)取名，从姓氏词典中(随机)取姓。在此基础上，如果确定在选定系统资源设置下，1000次测试迭代中发生900次失败，则可确定最终的失败概率为0.9。

然后，此过程可如上所述的针对每个另外的参数组重复。再次，蒙特卡洛技术可以用于产生测试案例数据变体。

具体地，如果测试案例T1...TN定义为覆盖所有的应用功能，对于给定测试案例T1，取决于技术上下文，T1可能需要1000这个量级的数据变体，应当记住如果可能的变体数量被系统本身所约束，则没有必要寻求超出系统可以实现的变体。因此，可以改变T1输入参数以获得T1_1...T1_1000模拟测试案例，然后为T2_1...T2_1000，直至TN _1...TN_1000。

如果资源空间的采样识别了16个资源条件，例如仅考虑存储器和磁盘资源，则在其对应的轴中有4个采样点。

然后，每个测试情况变体T1_1...T1_1000T2_1...T2_1000TN_1...TN_1000针对每个Tx_y在4个不同的资源语境T1_1_1...T1_1_4中运行，等等。所有的执行填充失败空间。蒙特卡洛变体和资源采样点的数量根据统计显著性考虑来选择。

因此，根据本实施例，针对给定的系统资源组合执行多次软件。优选地，对于所述软件在给定的系统资源组合下的每次执行，定义了用于所述执行所需的输入数据的不同值。优选地，这些不同值可以随机方式定义。优选地，这些不同值可以伪随机方式定义。优选地，这些不同值可借助于蒙特卡洛变体来定义。这种蒙特卡洛变体本身可以从标准或随机选定的种子值开始。

本发明可采用全部硬件实施例、全部软件实施例或包含硬件和软件元件的实施例的形式。在优选实施例中，本发明以软件实现，其包括但不限于固件、常驻软件、微代码等。

进一步地，本发明可以采用计算机程序产品的形式，其可从提供程序代码的计算机可用或计算机可读介质访问，该程序代码由计算机或任何其他指令执行系统使用或与其有关。对于此说明书的目的，计算机可用或计算机可读介质可以为任意能够包含、存储、传送、传播或传输该程序的装置，以用于由指令执行系统、装置或设备使用或与其有关。

图6示出了适于执行某些实施例的计算机环境。如图6所示，计算机系统600包括处理器610、主存储器620、大容量存储接口630、显示接口640以及网络接口650。特别地，计算机系统600可至少部分地为虚拟机。系统600的多个组件组成系统资源，其可如上所述的在测试阶段改变为不同的组合。这些系统组件通过使用具有特定的传输容量的系统总线601相互连接，此传输容量构成了如上所述的可以在不同组合中改变的系统资源的示例。大容量存储接口630用于将大容量存储设备(硬盘驱动655，其构成了如上所述的可以在不同组合中改变的系统资源的示例)连接至计算机系统600。可移动存储接口驱动662的一个特定类型为软驱，其可以将数据存储至软盘695或从其读取数据，但是可以设想其他类型的计算机可读存储介质，例如可读和可选的可写的CD ROM驱动。同样地提供了用户输入接口644，其从例如鼠标665和键盘664的接口设备接收用户交互。还另外提供了打印机接口646，其可以向打印机666发送和可选的从其接收信号。

主存储器620构成了如上所述的可以在不同组合中改变的系统资源的示例，根据优选的实施例，其包含数据622和操作系统624。

计算机系统600使用众所周知的虚拟寻址机制，其允许计算机系统600的程序运行为仿佛其只访问单独的大容量存储实体，而不是访问多个小容量存储实体，例如主存储器620和HDD 655，其构成了如上所述的可以在不同组合中改变的系统资源的示例。因此，尽管数据622、操作系统624示出为驻留在主存储器620内，但本领域技术人员将理解的是这些项目不必同时所有完全地包含在主存储器620中。还应当注意的是，这里使用的名词“存储器”一般是指计算机系统600的整体虚拟存储器。

数据622表示用作输入至计算机系统200的任意程序或从其输出的任意数据，具体地可包括测试下的应用。操作系统424为业内已知的诸如OS/400的多任务操作系统；但是，本领域技术人员将意识到本发明的精神和范围不限于任意一种操作系统。

处理器610可以由一个或多个微处理器和/或集成电路组成。处理器的容量构成了可以如上所述的在不同组合中变化的系统资源的示例。处理器610执行存储在主存储器620中的程序指令。主存储器620存储处理器610可能访问的程序和数据。当计算机系统600启动时，处理器610首先执行组成操作系统624的程序指令。操作系统624是管理计算机系统600的资源的复杂程序。这些资源的一部分是处理器610、主存储器或系统存储器620、大容量存储接口630、显示接口640、网络接口650和系统总线601。

尽管计算机系统600示出为只包含单个处理器和单个系统总线，但是本领域技术人员将理解的是本发明可以使用具有多个处理器和/或多个总线的计算机系统来实践。另外，在优选实施例中使用的接口的每一个均包括独立的、完整编程的微处理器，其用于从处理器610卸载计算密集型处理。但是，本领域技术人员将理解的是本发明同样可应用于简单地使用I/O适配器以执行类似功能的计算机系统。

显示接口640用于将一个或多个显示器660直接连接至计算机系统600。这些显示器660可为非智能(即哑)终端或完全可编程工作站，其用于允许系统管理员和用户与计算机系统600通信。但是，应注意的是尽管显示接口640提供为支持与一个或多个显示器660的通信，但是计算机系统600不是必须需要显示器665，因为所有需要与用户和其他处理的交互可通过网络接口650发生。

网络接口650构成了如上所述的可以在不同组合中改变的系统资源的示例，其用于将其他计算机系统和/或工作站(例如图6中的675)通过网络连接至计算机系统600。不管计算机系统600如何连接至其他计算机系统和/或工作站，本发明可同样应用，与网络连接670是否使用当今的模拟和/或数字技术或是通过一些未来的联网机制无关。另外，许多不同的网络协议可以用于实施网络。这些协议为专门的计算机程序，其允许计算机通过网络670通信。TCP/IP(传输控制协议/因特网协议)是适合的网络协议的一个示例，例如通过以太网。如所示，网络670将系统600连接至两个另外的设备671和672，其可以为与以上所述类似的计算机系统，或是例如打印机、路由器等其他的网络可用设备。在本示例中，网络设备672为本地服务器，其通过调制解调器681连接至公共网680，例如环球信息网。通过此公共网680，可以建立与远程设备或系统685的连接。

在这点，重要的是注意到尽管本发明已经并将继续在完整功能计算机系统的上下文中描述，但本领域技术人员将理解的是本发明能够以多种形式作为程序产品分发，本发明的应用与用于实际执行该分发的信号承载介质的特定类型无关。适合的信号承载介质包括：可记录类型的介质，例如软盘和CD ROM(例如图6的695)，和传输型介质，例如数字和模拟通信链路。

该介质可以为电、磁、光、电磁、红外或者半导体系统(或装置或设备)或者传播介质。计算机可读介质的示例包括半导体或固态存储器、磁带、可移动计算机磁盘、随机访问存储器(RAM)、只读存储器(ROM)、硬磁盘和光盘。光盘的当前示例包括压缩盘-只读存储器(CD-ROM)、压缩盘-读/写(CD-R/W)和DVD。

适于存储和/或执行程序编码的数据处理系统将包括至少一个处理器，其通过系统总线直接或间接耦合至存储器元件。存储器元件可包括在程序代码的实际执行期间使用的本地存储器、大容量存储器和高速缓冲存储器，其提供至少一部分程序编码的临时存储，以降低在执行过程中代码必需从大容量存储器中读取的次数。

输入/输出或I/O设备(包括但不限于键盘、显示器、指点设备等)可直接地或通过中间的I/O控制器耦合至系统。

网络适配器也可耦合至系统，以使得数据处理系统能够通过中间的专用网络或公共网络耦合至其他的数据处理系统或远程打印机或存储设备。调制解调器、电缆调制解调器和以太网卡只是当前网络适配器的可用类型的一部分。

Claims (17)

1.一种在执行软件的系统中优化所述软件的执行的方法，所述方法包括步骤：

提供性能模型，所述性能模型表示所述软件在不同的选定系统条件下的性能，所述系统条件以一个或多个预定系统资源来描述；

接收给定时刻的每个所述预定系统资源的测量；以及

从所述性能模型中提取出对应于所述测量的性能值。

2.根据前述任一权利要求所述的方法，包括进一步的步骤：通过测试所述软件来填充所述性能模型。

3.根据权利要求2所述的方法，其中所述测试所述软件包括：在配置了选定系统资源的每个组合的系统中反复执行所述软件，以及汇编与在所述配置下应用的行为有关的统计数据。

4.根据权利要求3所述的方法，其中所述软件针对系统资源的给定组合多次执行。

5.根据权利要求4所述的方法，其中对于所述软件在系统资源的给定组合下的每次执行，对所述执行所需的输入数据的不同值以随机或伪随机的方式或借助于其蒙特卡洛变体来定义。

6.根据权利要求3所述的方法，其中配置了系统资源的每个期望组合的所述系统是虚拟机。

7.根据权利要求2所述的方法，其中所述模型在分发前被填充，并且所述性能模型与所述软件一起分发。

8.根据前述任一权利要求所述的方法，包括进一步的步骤：确定所述性能模型是否包括精确对应于所述测量的性能值，并且在所述性能模型不包括精确对应于所述测量的性能值的情况下，从所述性能模型中提取出分别对应于一个或多个最接近的可用测量值的一个或多个邻近的性能值。

9.根据权利要求8所述的方法，包括进一步的步骤：根据所述邻近的性能值对性能值进行插值。

10.根据前述任一权利要求所述的方法，包括进一步的步骤：当所述性能值下降至预定阈值以下时，向用户报警。

11.根据前述任一权利要求所述的方法，包括进一步的步骤：当所述性能值下降至预定阈值以下时，尝试自动协商用于所述软件的来自所述系统的增大的资源分配。

12.根据前述任一权利要求所述的方法，其中所述性能模型包括多维矩阵。

13.根据前述任一权利要求所述的方法，其中所述模型包含多组不同的性能值，每组与所述测量的一部分或全部有关。

11、根据前述任一权利要求所述的方法，其中所述预定系统资源包括可用系统cpu容量、可用系统存储器、可用系统磁盘或可用网络套接字中的至少一个。

14.一种装置，其包括适于执行根据权利要求1至13中任一权利要求所述的方法的每个步骤的装置。

15.一种计算机程序，其包括当所述计算机程序在计算机上执行时用于执行根据权利要求1至13中任一权利要求所述的方法的每个步骤的指令。

16.一种当所述计算机程序在计算机上执行时根据权利要求1至13中任一权利要求的性能模型。

17.一种计算机可读介质，其上编码有根据权利要求15的计算机程序或根据权利要求16的性能模型。

Images