Sun Java System Application Server 9.1 部署规划指南

设定性能目标

简单地说，高性能是指最大限度地增加吞吐量并缩短响应时间。除了这些基本目标外，还可以通过确定以下内容来设定特定目标：

要部署哪些类型的应用程序和服务以及客户机如何访问它们？
哪些应用程序和服务需要具有较高的可用性？
应用程序是具有会话状态还是无状态？
系统必须支持的请求数量或吞吐量是多少？
系统必须支持多少个并发用户？
可接受的用户请求的平均响应时间是多少？
请求之间的平均延迟时间是多少？

可以使用远程浏览器仿真器 (Remote Browser Emulator, RBE) 工具或 Web 站点性能和基准软件（用于模拟预期的应用程序活动）来计算其中的某些度量。通常，RBE 和基准产品将生成并发的 HTTP 请求，然后报告每分钟处理给定请求数的响应时间。然后，您可以使用这些数据来计算服务器的活动。

本章介绍的计算结果并不是一成不变的。在微调 Application Server 和应用程序的性能时，请将这些结果作为工作的参考点。

本节包括以下主题：

估算吞吐量

从广义而言，吞吐量测量的是 Application Server 完成的工作量。对于 Application Server，可以将吞吐量定义为每个服务器实例每分钟处理的请求数。高可用性应用程序还会对 HADB 的吞吐量有要求，因为它们会定期保存会话状态数据。对于 HADB，可以将其吞吐量定义为每分钟存储的会话数据量，它是每分钟的 HADB 请求数与每个请求的平均会话大小的乘积。

如下一节所述，Application Server 吞吐量是多种因素的作用结果，其中包括用户请求的特性和大小、用户数以及 Application Server 实例和后端数据库的性能。可以使用模拟的工作负载作为基准来估算单个计算机上的吞吐量。

高可用性应用程序会产生额外的开销，因为它们会定期将数据保存到 HADB 中。开销量取决于数据量、数据的更改频率和数据的保存频率。前两种因素取决于所使用的应用程序；其中后一种还受服务器设置的影响。

可以将 HADB 吞吐量定义为每分钟的 HADB 请求数与每个请求的平均数据量的乘积。较大的 HADB 吞吐量意味着，需要更多的 HADB 节点以及更大的存储大小。

估算 Application Server 实例上的负载

应考虑以下因素来估算 Application Server 实例上的负载：

最大并发用户数

用户通过客户机（如 Web 浏览器或 Java 程序）与应用程序进行交互。根据用户的操作，客户机会定期向 Application Server 发送请求。只要用户会话既未到期也没有终止，系统就认为用户处于活动状态。在估算并发用户数时，应将所有活动用户包括在内。

下图对每分钟处理的请求数（吞吐量）与用户数之间的典型关系进行了图形说明。最初，随着用户数的增加，吞吐量也会随之增加。不过，随着并发请求数的增加，服务器性能开始趋于饱和，并且吞吐量开始下降。

请确定一个临界点，当超过此限制后，您再添加并发用户时，每分钟可处理的请求数将会下降。该点表示此时已达到最佳的性能，之后吞吐量将开始下降。一般来说，应尽可能地使系统在最佳吞吐量下运行。您可能需要增加处理能力以处理额外的负载并提高吞吐量。

延迟时间

用户并不是连续地提交请求。当用户提交请求后，服务器将接收并处理该请求，然后返回结果，此时，用户需要等待一段时间，然后再提交新请求。两个请求的间隔时间称为延迟时间。

延迟时间取决于用户类型。例如，用于 Web 服务的计算机间交互的延迟时间通常比用户交互的延迟时间短。您可能需要综合考虑计算机和用户交互的情况来估算延迟时间。

确定平均延迟时间是至关重要的。可以使用此时段来计算每分钟需要完成的请求数以及系统可支持的并发用户数。

平均响应时间

响应时间是指 Application Server 为用户返回请求结果所花的时间。响应时间受很多因素的影响，例如，网络带宽、用户数、提交的请求数和类型以及平均延迟时间。

在本节中，响应时间是指平均响应时间。每种类型的请求都具有其自己的最小响应时间。不过，在评估系统性能时，请根据所有请求的平均响应时间进行分析。

响应时间越快，每分钟处理的请求就会越多。不过，随着系统上的用户数的增加，即使每分钟的请求数有所下降，响应时间也会开始增加，如下图所示：

抱歉：此版本的手册未提供相关图形。

与此图形类似的系统性能图形表明，达到某个临界点后，每分钟的请求数与响应时间将成反比。每分钟的请求数下降得越快，响应时间（由虚线箭头表示）就会增加得越多。

在该图中，峰值负载点为每分钟的请求数开始下降的点。在该点之前，响应时间的计算并不一定准确，因为在其公式计算中不使用峰值数字。在该点之后（由于每分钟的请求数与响应时间成反比关系），管理员可以使用每分钟的最大用户数和请求数更准确地计算响应时间。

请使用以下公式来确定 T_response 的值，即峰值负载时的响应时间（以秒为单位）：

T_response = n/r - T_think

其中

n 是并发用户数
r 是服务器每秒收到的请求数
T_think 是平均延迟时间（以秒为单位）

要获得准确的响应时间结果，应始终在等式中使用延迟时间。

示例 2–1 计算响应时间

如果以下条件成立：

系统在达到峰值负载时可支持的最大并发用户数 n 为 5,000 个。
系统在达到峰值负载时可处理的最大请求数 r 为每秒 1,000 个。

平均延迟时间 T_think 为每个请求 3 秒。

因此，响应时间的计算公式为：

T_response = n/r - T_think = (5000/ 1000) - 3 秒= 5 - 3 秒

因此，响应时间为 2 秒。

在计算出系统的响应时间后（尤其是峰值负载时的响应时间），请将其与应用程序可接受的响应时间进行比较。响应时间以及吞吐量是两个影响 Application Server 性能的主要因素。

每分钟的请求数

如果知道任意给定时间的并发用户数、用户请求的响应时间以及平均用户延迟时间，则可以计算出每分钟的请求数。通常，是从估算系统上的并发用户数开始的。

例如，在运行 Web 站点性能软件后，管理员可推断出在联机银行的 Web 站点上提交请求的平均并发用户数为 3,000 个。此数字取决于已注册成为联机银行会员的用户数、其银行交易行为以及他们选择提交请求的日期或星期的时间等。

因此，如果知道了这些信息，则可以使用本节中介绍的每分钟的请求数公式，计算出系统每分钟可为此用户群处理的请求数。由于峰值负载时的每分钟请求数与响应时间成反比，因此，您可以决定选择每分钟较少的请求数来换取较快的响应时间，或者选择较慢的响应时间来换取每分钟较多的请求数。

微调系统性能首先要对不同的每分钟请求数和响应时间阈值进行试验以选出最佳的值。此后，将确定需要调整的系统区域。

计算上一节的等式中的 r 可得出：

r = n/(T_response + T_think)

示例 2–2 计算每秒的请求数

对于以下值：

n = 2,800 个并发用户
T_response = 1（每个请求的平均响应时间为 1 秒）
T_think = 3（平均延迟时间为 3 秒）

每秒请求数的计算结果为：

r = 2800 / (1+3) = 700

因此，每秒的请求数为 700 个，每分钟的请求数为 42000 个。

估算 HADB 上的负载

要计算 HADB 上的负载，请考虑以下因素：

有关配置会话持久性的说明，请参见《Sun Java System Application Server 9.1 高可用性管理指南》中的第 9 章 “配置高可用性会话持久性和故障转移”。

HTTP 会话持久性频率

HADB 每分钟收到的请求数取决于 持久性频率。持久性频率决定了 Application Server 将 HTTP 会话数据保存到 HADB 中的频率。

持久性频率选项为：

web-method（默认）：服务器将会话数据与每个 HTTP 响应存储在一起。此选项可确保存储的会话信息是最新的，但会产生较高的 HADB 通信量。
time-based：按指定的时间间隔存储会话。此选项可减少 HADB 通信量，但无法确保会话信息是最新的。

下表简要说明了持久性频率选项的优缺点。

表 2–1 持久性频率选项的比较


持久性频率选项	优点	缺点
web-method	确保提供最新的会话信息。	可能会增加响应时间并降低吞吐量。
time-based	响应时间较短，并且可能会提高吞吐量。	不能完全确保在应用服务器实例出现故障后提供最新的会话信息。

HTTP 会话大小和范围

每个请求的会话大小取决于会话中存储的会话信息量。

提示 –

要提高整体性能，应尽可能减少会话中的信息量。

可通过 持久性范围设置微调每个请求的会话大小。请从以下 HTTP 会话持久性范围选项中进行选择：

session：每次服务器将会话信息保存到 HADB 时，将序列化并保存整个会话对象。
modified-session：服务器仅会保存已修改的会话。它通过截获对该 Bean 的 setAttribute() 方法的调用来检测修改。此选项将不检测对内部对象的直接修改，因此，在这种情况下，必须对 SFSB 进行编码才能显式调用 setAttribute()。
modified-attribute：服务器仅保存自上次会话存储以来修改（插入、更新或删除）的属性。它与 modified-session 的缺点相同，但如果正确应用，可以显著降低 HADB 写入吞吐量要求。

要使用此选项，应用程序必须：

在每次修改会话状态时调用 setAttribute() 或 removeAttribute()。
确保各属性之间没有交叉引用。
在多个属性之间分布会话状态，或者至少在只读属性和可修改属性之间分布会话状态。

下表简要说明了持久性范围选项的优缺点。

表 2–2 持久性范围选项的比较


持久性范围选项	优点	缺点
modified-session	为没有修改会话状态的请求提供改进的响应时间。	在执行 Web 方法（通常为 `doGet()` 或 `doPost()`）期间，应用程序必须调用一种会话方法：如果更改了属性，则调用 `setAttribute()`。如果删除了属性，则调用 `removeAttribute()`。
session	对应用程序没有限制。	与 `modified-session` 和 `modified-attribute` 选项相比，可能具有更差的吞吐量和响应时间。
modified-attribute	如果为请求修改的会话状态百分比较低，则请求具有更佳的吞吐量和响应时间。	当为给定请求修改的会话状态百分比接近 60% 时，吞吐量将会下降，响应时间将会延长。在这种情况下，其性能比使用其他选项的性能要低，因为将属性分隔为各个记录会产生一些开销。

有状态会话 Bean 检查点

对于 SFSB 会话持久性，HADB 上的负载取决于以下内容：

为检查点启用的 SFSB 数。
为检查点选择的 SFSB 方法以及使用这些方法的频率。
会话对象的大小。
哪些方法是事务性的。

通常在完成任何涉及 SFSB 的事务之后（即使该事务回滚）执行检查点操作。

为了获得最佳性能，请为检查点指定较少的一组方法。所检查的数据大小以及检查频率决定了在给定客户机交互的响应时间方面产生的额外开销。