如今，大规模商业应用的发展必须处理许多问题。这些问题中有并行 性管理、事务管理、持久性、安全性、表示、业务逻辑。所有这些问题必 须在应用、硬件/软件拓朴和工作负荷的框架内解决。此框架内的每个软件 组件可能具有一些必须正确设置以便系统正确工作的配置参数。不正确的 配置会导致应用发生故障或性能降低，这两者对组织都是代价高昂的。
诸如Sun Microsystem公司开发的JavaTM 2平台、企业版(J2EETM) 的框架被设计为通过支持问题的分离来简化对系统的配置过程。应用开发 人员可以主要集中于实现应用的业务逻辑方面；该应用被部署于其上的应 用服务器处理并行性、事务以及持久性管理的大部分复杂性。
在此框架内，部署者，即配置应用服务器以正确和有效地管理并行性、 事务和持久性的个人，起着核心作用。企业系统非常复杂，负责配置这种 系统的部署者必须处理以下事情：1)应用本身与数据之间的交互会影响应 用服务器的配置，而部署者通常不具有足够的文档以处理此问题；2)该应 用与之交互的硬件和软件系统会严重影响其部署；3)该应用的工作负荷会 影响应用服务器的配置；4)最佳实践指南和基于规则的简档是试探法，其 不可能覆盖应用、硬件/软件拓朴和工作负荷的全部空间，并且它们本身可 能已基于错误的前提；以及5)基于配置的问题通常难以跟踪并且跟踪比 较昂贵，因为经常的情况是，当应用发生故障时假设是应用本身有缺陷， 并消耗资源来查找被认为是程序错误的故障原因。
单纯的配置空间大小和复杂性就使其非常难以管理。当如通常的情况 那样，设置配置的部署者不是设计该系统的同一人，并且不是该系统的用 户时，这种情况会更复杂。通常，部署者是在配置遗留系统。由于没有可 随意使用的适当的工具，部署者必须使用经验法则、直觉以及试错的混合 来配置应用服务器。对于较小的系统，控制理论提供了适当的方法以通过 合适的软件模型来确定配置值，但是对于实际见到的大的系统拓朴例如企 业系统，难以得出该系统的合适的模型。即使可开发出模型，该模型也极 不可能扩展到其他应用部署，因此需要一种配置大系统的方法。
参照图1，其示出根据现有技术用于应用服务器部署的传统拓朴的框 图。Web服务器103和105将请求从因特网101指引到应用服务器120和 121。应用服务器120和121连接到后端数据库150，企业数据持久存储在 该数据库内。
参照图2，其示出根据现有技术的基于J2EE的应用服务器的结构的框 图。用于此系统的应用服务器120通常用Java编写，因此整个系统在一个 或多个Java虚拟机(JVM)260中执行。如上所述，J2EE支持各问题的 分离；因此应用服务器120分为表示层、业务逻辑层、以及数据层。Web 容器230对应于表示层。它管理与Web服务器103的交互。通过Web服 务器103将浏览器请求路由到Web容器230，在该Web容器230处或者 返回静态HTML页，或者启动Java服务器页(JSP)或小服务程序的执 行。该JSP或小服务程序可继而与业务逻辑层交互，并最终合成返回给用 户的HTML。Web容器230通过控制一次可执行多少个线程来确定小服务 程序的并行性。
Enterprise JavaBeans(EJB)容器235对应于业务逻辑层。EJB容器 235管理在应用服务器120上部署的Enterprise Java Bean的创建和执行。 此外，它控制EJB的事务处理行为、它们的并行性以及它们的缓存。它还 控制EJB与数据源240的交互，该数据源对应于数据层。数据源240是数 据库的抽象。IT部门在连接池中管理与数据库150的连接以降低创建新连 接所涉及的花费。当EJB不再需要与数据库连接时，不是关闭该连接，而 是将该连接返回该池以便以后再次使用。此外，数据源240保持语句缓存， 该语句缓存用于减小处理经常执行的结构化查询语言(SQL)请求的成本。
附图说明
图1示出根据现有技术的传统的应用服务器配置的拓朴。
图2示出根据现有技术的基于J2EE的应用服务器的结构的表示。
图3是示出根据本发明的方法的流程图。
图4是示出根据本发明的用于实验的硬件的图。
图5是示出25个随机配置空间探索运行中的每一个的吞吐量的条形 图。
图6示出将吞吐量表示为最大数据源连接池大小和EJB容器线程池大 小之间的差值的函数的图。
图7是示出25个配置空间探索运行中的每一个的平均响应时间的条形 图。
图8是计算机程序产品的简化框图，在该程序产品上可有利地使用本 发明的实施例。

简单地说，根据被要求保护的发明，一种为至少一个软件系统设置配 置参数的方法包括以下步骤：a)接收对用于将被最优化的至少一个软件系 统的一组配置参数的标识；b)从预定范围内为每个感兴趣的配置参数选择 一随机值；c)将每个配置参数设置为对应的所选择的随机值；d)使用所 选择的值运行应用；e)在该应用运行时，收集与该软件系统有关的性能信 息；f)将步骤b)到e)重复选定的次数；以及g)分析收集到的性能信息 以确定最优的配置参数。该方法可由运行程序指令以执行上述方法步骤的 可编程计算机系统执行，或由专用装置例如ASIC(专用集成电路)执行。
本文描述一种解决为一软件系统例如应用服务器或一组互连软件系统 例如图2所示的包含应用服务器、JVM、数据库和Web服务器的系统确 定正确配置的问题的低成本方法。本发明可用于各种各样的软件系统，这 是因为该方法会自主探索应用的配置空间，并然后分析探索结果以确定最 优配置。本方法在用于确定企业系统的配置时是尤其有益的，对企业系统 目前没有合适的方法。从值的一合理范围内随机选择涉及给定系统的系统 配置参数，然后在设置为所选择的参数的系统上运行一工作负荷。每个测 试运行的结果被记录下来以用于随后的分析。
为了消除应用本身的问题，应用首先应以给定的配置运行多次以确定 相对于该配置该应用的行为表现是确定性的。这意味着应用结果与配置直 接相关，而不会受外界因素例如应用中的程序错误或网络问题影响。该应 用应以同样的配置运行足够的次数以向了解该系统的人确保其无程序错 误，以及考虑和消除在试验自身之外的会影响结果的因素。假设15次是此 初始步骤的合适的运行次数。应用的行为表现必须相当一致，即对于给定 的配置性能没有表现出大的摆动。预期系统性能中有微小的变化，并且只 要它们落在可接受范围内就容忍它们。该范围可以是由具有该系统的知识 的某人确定的最小到最大标准偏差/平均值。当应用满足此要求时，在不同 运行之间性能的变化可被归因于配置值中的变化的影响。
参照图3，其示出根据本发明的一个实施例的确定应用服务器的最优 配置设置的过程的流程图。此过程在步骤301开始，在该步骤为此系统选 择一组被认为将影响此给定系统的性能的配置参数。选择的参数依赖于许 多因素，例如系统本身；在该系统上运行的应用；应用与之交互的硬件和 软件系统；网络特性；网络中的机器的数量；网络的拓朴；以及应用的工 作负荷。对于企业系统，一部署者可以处理超过50个待设置参数。为了示 出此方法的好处，下面的示例示出了在J2EE框架内部署应用时配置应用 服务器的过程中所涉及的一些问题。
假设要解决的问题是图2中所示的应用服务器的最优配置。存在许多 会影响这种系统的性能的参数，但是为此示例的目的，选择了表1中所示 的以下9个参数作为最重要的：
                            表1   参数   描述   Web容器线程池最   小值   Web容器中的线程的最小数量。代表最小   并行量。   Web容器线程池最   大值   Web容器中的线程的最大数量。代表最大   并行量。   线程是可增长的   指示Web容器线程池最大数是硬界限还是   软界限，即如必要的话线程池的大小是否可   扩展。   EJB容器线程池大小   EJB容器中的线程的最大数量。   数据源连接池最小值   代表连接池中的连接的最小数量   数据源连接池最大值   代表连接池中的连接的最大数量   语句缓存   代表被缓存的已执行的SQL语句的数量   JVM最小堆大小   分配给应用服务器(以及在该应用服务器上   部署的应用)在其中执行的JVM的最小存   储空间量，   JVM最大堆大小   分配给应用服务器在其中执行的JVM的最   大存储空间量。
下一个步骤303涉及为每个参数选择一值范围。所选择的范围应代表 用于每个给定参数的由使用、文档、基于规则的简档和/或最佳实践指南确 定的值的合理范围。每当可能时，应扩展该范围以包括在连续区的两端的 极端值。应执行一致性检验以确保最小值小于最大值，并且所选择的值与 涉及的硬件和软件一致。假设为表1中的9个参数选择了下面的范围：
                表2  参数   描述  Web容器线程池最小值  Web容器线程池最大值  线程是可增长的  EJB容器线程池大小  数据源连接池最小值  数据源连接池最大值  语句缓存  JVM最小堆大小  JVM最大堆大小   10...35   35...100   true false   5...50   5...25   15...40   50...500   64...256   256...768
下一步305是从每个配置参数的范围内随机选择一个值。该随机选择 的值可由系统自身选择，并优选地使用一随机数生成器过程。重要的是， 该选择是一盲目选择，即在数字选择中没有干涉。应指出，随机值选择与 试错选择是不同的。对于随机选择，不象对于试错试验那样，没有预想的 给定值将如何影响结果的期望。对于试错选择，用户在选择一个值时暗示 对结果的预想的期望，并在结果显现时证明该期望是否是正确的。出于以 下两个原因，随机值选择对于此方法是重要的：1)它允许使用很少的或者 不使用用户交互来进行自动的、自主的试验；以及2)它消除了败坏试验 并且会妨碍最优配置的选择的有害的推测。后一个原因是由于系统文档和 最佳实践指南尽管有用但不总是正确的。这是因为，目前的系统尤其是企 业系统涉及如此多的交互(在应用和持久数据之间，在应用和硬件/软件系 统之间，在应用和数据库之间等)，以至于任何可用的文档无法定义一个 将所有可能的交互考虑在内的配置。部署者必须根据任何可用的文档和使 用数据来初始设置其系统配置。然后，他们根据对系统性能的经验观测来 精细地调节其系统配置，而不会认识到初始设置是有缺陷的。下面将说明 一突出显示此情况的试验。
接着，在步骤307中，用所述随机选择的一组配置参数来配置应用。 然后，在步骤309中，该应用以所述随机选择的参数值运行。在应用结束 之后，在步骤311中，对于该应用运行，记录下基准性能值例如吞吐量和 响应时间。应指出，吞吐量和响应时间是在此特定示例内记录的基准，但 是根据将被检查的系统以及期望目标也可记录其他值。以作为对吞吐量的 测量的每秒百万指令数(MIPS)测量的系统的执行速度也是用于测量整个 系统性能的另一个重要的基准。
假设在此示例中，每个测试将运行25次。在本发明的精神和范围内可 使用任何数量的合理的测试运行。该数量总是灵活的，并且可被部署者随 时改变以获得更好的测试数据。已知多种确定是否已执行在统计上有意义 的运行数量的方法。
在步骤313中，如果应用没有以当前的参数值运行所决定的次数，则 决定再次运行该应用。然后，过程返回到步骤305，来选择另一组配置参 数。应注意，每次测试运行包括一组新的随机选择的参数值。应理解，在 一次探索中一些参数值被多次选择，而一范围内一些参数值根本没有被选 择。以参数“线程可增长”为例。此参数仅有两个可能值：“True”或“False”。 很明显，在25次运行测试情况下这两个值将被多次选择。相反，可用在从 50到500的范围内的一个值设置“语句缓存”。假设该值增加10，则很明 显，25次运行不能覆盖45个可能的选择中的每一个。但是，随机选择将 覆盖此范围内的足够多的值以得到有意义的结果，这就够了。如果测试判 定不是这种情况，则可增加运行的数量。
应指出，存在许多可针对该应用运行的不同类型的工作负荷。将运行 的工作负荷的类型包括：1)强调总吞吐量对最大系统限制(思考时间对无 思考时间)；2)随时间改变负荷以注意响应时间/吞吐量等级；以及3)不 同应用功能的不同部分(混合工作负荷)。
在工作负荷运行25次之后，在步骤315中，分析记录的结果。对结果 的分析将指示测试是否产生有意义的数据。此分析步骤自身可以是自动的。 可使用统计技术例如多重回归来从运行结果中推断出有用的信息。如果测 试未产生有意义的数据，则可增大运行的数量，或者可在此处停止测试。 此方法并不保证每个测试有最优的结果。为此示例的目的，假设25次测试 运行已产生一些有意义的结果，并且已统计地分析了测试运行的结果，得 出平均响应时间和吞吐量与两个最重要的配置参数，EJB容器线程池大小 和数据源连接池最大值，相关。假设在此示例中，部署者根据使用和回归 测试得知这两个参数对吞吐量和平均响应时间的基准值的变化的贡献是最 大的。根据此信息，如图5和6将示出的，下一步的分析将集中于与这两 个参数的值有关的测试结果。
尽管此过程可完全自动进行并且从开始进行到结束而只有很少或没有 用户交互，但是在本发明的另一实施例中，如下所述修改该测试将具有更 大的好处：自动运行最初的一组测试，并然后停止试验，分析结果，并然 后根据发现的结果缩小对剩余的测试的关注范围。最初的运行会突出显示 某些需要更仔细观察的参数。以这种方式，可更详尽地测试被初始测试挑 选出的作为系统性能(正面的或负面的)的重要贡献者的参数，而不是平 等地测试所有参数。该方法的这种动态版本可通过将测试的关注范围迅速 限制到显得会导致性能的更重要变化的那些值，可更快地确定最优配置。 部署者必须相对于进行中间分析并改变测试的过程中所涉及的额外资源 (人力和/或数据处理)来衡量此动态版本的好处。
参照图4，其示出根据本发明的一个实施例的用于测试的硬件配置。 在此示例中，Web服务器(HIS 1.3.19)和应用服务器(WebSphere 4.03) 在同一机器上运行。数据库(DB2 7.2 fixpack 5)406优选地在单独的机器 上运行。应用服务器404和数据库406在此示例中是相同的机器。工作负 荷驱动器402被表现为一桌面计算机系统，但是它可以是任何合适的信息 处理机器。
为了进一步说明此方法的好处，下面考察一案例研究，其中探索了应 用服务器404的配置空间。此探索将作为“黑箱”测试来进行。此示例将 全部集中于配置空间的探索结果，因此假设某些条件，如下所示：
    应用：                制造软件应用
    将配置的系统：        应用服务器
    硬件：                如图4所示的硬件配置
    软件：                图2所示的系统
    被测试的参数：        见表1
    被测试的值的范围：    见表2
    运行时间：            大约15分钟
    测试者：              系统部署者
    选择值的方法：        随机数生成
还假设已用给定配置测试应用服务器以确定在应用本身或者该应用在 其中运行的系统中没有固有的问题。假设用给定配置运行该应用15次在测 量的吞吐量中产生很小的变化。测量的标准偏差/均值是1.1％，这是令人 满意的。接着，用选自表2中所示的范围的变化的配置参数组来运行应用 25次。其结果如图5所示。
图5示出代表25次运行的条形图。针对25次随机配置空间探索运行 中的每一次所测量的吞吐量(每分钟的事务)沿纵轴示出，其数量是从0 到1400。配置空间探索运行在横轴上示出，其编号是从1到25。图5的条 形图清楚地示出应用服务器的配置对性能有很大影响。最大吞吐量(测量 为超过1200)是最小吞吐量(测量为90)的14倍。
通过检查变量对和吞吐量之间的关系来分析数据揭示出，当EJB容器 线程池大小被设置为高于数据源连接池最大值时，该系统的性能较差。多 重回归分析进一步示出其他参数对吞吐量的影响极小，因此更仔细地观察 最大数据源连接池大小和EJB容器线程池大小之间的相关性是有利的。图 6是将吞吐量示出为最大数据源连接池大小和EJB容器线程池大小的差的 函数的图。参照此图，很明显当数据源连接池最大值大于EJB容器线程池 大小(差值为正值)时，系统的吞吐量落在可接受的范围内。在相反情况 下，系统响应较差。对系统日志的检查揭示出存在大量对吞吐量造成负面 影响的事务回退。此行为的原因是该应用访问数据库150的方式。使用得 自此方法以及系统日志检查的关于EJB容器线程池大小与数据源连接池最 大值之间的关系的信息，可推断出此应用示出应用/数据库交互如何影响应 用服务器配置。在某些情况下，应用的一组件需要多于一个与数据库150 的连接。在负荷之下，会出现这样的情况，其中在EJB容器池中执行的每 个线程已获取一个连接并等待得到另一个连接。如果连接比线程少，则不 能前进。最后，线程等待连接超时，并回退它们的事务。在接收到回退的 通知时，应用试图重新开始该事务，从而再次导致同样的情况。不能前进， 因此对吞吐量的影响严重。
进一步的试验揭示出增加数据源连接池大小以至于其大于EJB容器线 程池大小可解决此问题。如前文所述，这是一种遵循最佳实践指南将导致 相反结论的情况。这是因为调节应用服务器时所接受的观念是在远离客户 机时限制资源。换句话说，使Web容器线程多于EJB容器线程，以及EJB 容器线程多于数据源连接。在此特定应用中，此规则是不合适的，因为线 程所需的连接数可大于线程数。当出现这种情况时，可有两种解决方法一 增加数据连接的数量，或修改应用从而每个线程至多使用一个连接。
在另一个案例研究中，条件类似于前一个例子的条件，除了操作环境 是一证券公司。图7是示出25个配置空间探索运行中的每一个的平均响应 时间的条形图。沿横轴示出每个应用运行，其编号为1到25。沿纵轴示出 平均响应时间。在此情况下最大和最小平均响应时间之间的差仅为百分之 14。通过使用统计方法，通过将9个参数中的每一个与平均响应时间相关 联，来得出突出显示值之间的关系的强度的、这些值之间的相关性。为了 发现相关系数，取每个配置参数，并记录25个值(针对25次测试运行中 的每一次)。将每个配置参数的每个值与用被设置为这些值的参数组得到 的平均响应时间配对。得到这样的相关系数，其表示一参数值与平均响应 时间之间的关系的强度，并可为正值和负值。最强的相关性用更高的数(正 值或者负值)表示。表3示出9个参数值中的每一个与平均响应时间之间 的相关性。
                表3   参数   相关性   Web容器线程池最小值   Web容器线程池最大值   EJB容器线程池大小   数据源连接池最大值   数据源连接池最小值   语句缓存   JVM最小堆大小   JVM最大堆大小   -0.10   .68   .13   .20   .31   -.56   -.22   -.08
从表3可见，最高的相关系数的值与Web容器线程池最大值(.68) 和语句缓冲(-.56)相关。该数的值越高，则该参数值和记录的结果之间的 相关性就越大。该数的符号指示该参数值和平均响应时间之间的关系(正 的或负的)。Web容器线程池最大值与平均响应时间之间的正相关性表示， 增加该Web容器线程的数量将增大响应延时，从而Web容器线程池最大 值的参数值应减小以便提高响应时间。相反，语句缓存和平均响应时间之 间的负相关性表示此参数值应该提高。在此示例中，说明有理由集中于对 两个参数，Web容器线程池最大值和语句缓冲，进行进一步测试。
图8是包含可配置成根据本发明的一实施例操作的逻辑的可编程计算 机的简化框图。该逻辑可体现为用于该可编程计算机的软件或该计算机内 的专用集成电路(ASIC)。根据本发明的一实施例，计算机可读介质例如 CDROM 801可包含用于根据本发明操作该可编程计算机800的程序指令。 该可编程计算机800的处理装置包括：随机存取存储器802、只读存储器 804、处理器806以及输入/输出控制器808。它们通过CPU总线809连接 在一起。另外，还存在输入/输出总线829、输出/输出接口810、磁盘驱动 控制器812、大容量存储设备818、大容量存储接口814以及可拆装的 GDROM驱动器816。已示出和说明的是可编程计算机装置的高度简化的 描述。本技术领域内的技术人员将理解，在计算机装置的任何实际应用中 需要其他低层的元件和连接。
因此，尽管已说明了目前被认为是优选实施例的实施例，但是本技术 领域内的技术人员将理解，在本发明的精神内可进行其他修改。