估算 Application Server 实例上的负载 (Sun Java System Application Server 9.1 部署规划指南)

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

估算 Application Server 实例上的负载

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

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

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

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

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

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

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

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

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

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

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

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

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

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

T_response = n/r - T_think

其中

如果以下条件成立：

平均延迟时间 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)

对于以下值：

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

r = 2800 / (1+3) = 700

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