关于性能结果

本节介绍对拉伸群集执行的不同性能测试的结果。

用于测试的系统是跨法兰克福和阿姆斯特丹 Oracle Cloud Infrastructure (OCI) 区域配置的 Oracle Fusion Middleware (FMW) 拉伸集群。

WebLogic 域由分布在不同位置的 5 个节点组成,用于对各种拓扑进行性能比较:与数据库在同一可用性域中运行的服务器、位于同一区域但位于不同可用性域中的服务器以及位于不同区域的服务器。

这些压力测试是使用 SOA Fusion Order Demo (FOD) 作为示例 SOA 应用程序执行的。已修改 FOD 演示,以便在订单完成时将 Java Message Service (JMS) 消息插入统一分布式目标 (UDD) 目标。此示例对数据库非常密集,使用多个 SOA 适配器,例如文件适配器和 JMS 适配器。它还涉及不同的 SOA 组件,例如调解器、业务流程执行语言 (BPEL)、规则引擎和多个 WebLogic 功能。

下图显示了用于测试的 FMW 拉伸群集环境:



fmw-stretched-performance-env-oracle.zip

此环境中的网络之间的实际延迟值包括:

主机之间 平均等待时间(RTT,毫秒)
在同一可用性域中 0.3
在同一区域中,但在其他可用性域中 0.6
在不同的地区(法兰克福和阿姆斯特丹) 6.5

检查压力测试

使用各种配置和工作负载进行了多次压力测试。

一些经过测试的配置包括:

  • 向上突出显示两个节点的集群,从而在服务器之间以及在其中一个服务器之间对数据库应用不同的延迟。
  • 压力测试各个服务器,每个服务器对数据库的延迟不同。
  • 在两个服务器上运行测试,这些服务器与数据库(仅限本地)和两个服务器位于数据库(仅限远程)的远程位置。
  • 使群集在每个区域中具有两个活动节点。

对于每个配置,测试了不同的工作负荷。所有工作负载请求首先发送到前端,在前端(通过全局负载平衡,然后是本地负载平衡器,再是 Web 服务器)在 Oracle WebLogic Server 实例之间分配。工作量类别(低、中、高)取决于每个设置中的活动节点数,并受数据库的并发限制约束。例如,如果有四个节点正在运行,则 80 个并发虚拟用户将被视为 WebLogic 服务器的低工作负荷,但如果只有一个节点处于活动状态,则将视为高工作负荷。但是,从数据库的角度来看,工作量保持不变。为了简单起见,使用的工作量如下:

  • 低工作负载(每个 WebLogic 服务器 20 个并发虚拟用户,系统中最多有 40 个并发虚拟用户)
  • 中等工作量(每个 WebLogic 服务器 40-60 个并发虚拟用户,系统中最多有 120 个并发虚拟用户)
  • 高负载(每个 WebLogic 服务器 80 个并发虚拟用户,系统中最多 160 个并发虚拟用户)

根据压力测试结果,这些是结论:

  • 整体集群性能

    对于具有 2 个服务器的集群,其整体集群性能(按 WebLogic 吞吐量、每秒事务处理数(TX/秒))为:

    • 当两台服务器位于同一可用性域 (Availability Domain,AD)(作为参考)时:100%
    • 当每个服务器位于不同的 AD 中时:约 100%
    • 当一台服务器位于不同的区域(6.5ms 往返时间 (RTT))时:90-95%
    • 两台服务器所在的区域与数据库 (6.5ms RTT) 不同时:85-95%
  • 每台服务器的性能

    每台服务器的性能(按 WebLogic 吞吐量,TX/秒):

    • 对于与数据库位于同一 AD 中的服务器(作为引用):100%
    • 对于另一个 AD 中的服务器:98-99%
    • 对于其他区域中的服务器:85-90%
  • 活动数据源连接数

    活动数据源连接数随数据库延迟增加而增加。尽管这取决于工作负荷,但区域 2 中的服务器最多显示 2x 个活动连接,而不是与数据库关联的服务器。请考虑这一点,以正确调整 WebLogic 数据源和数据库会话的大小。

  • JTA 事务处理

    JTA 事务在数据库延迟较高的服务器中长时间保持活动状态。长时间保持活动的事务处理更有可能受到故障的影响。因此,在这些系统中,事务日志使用 JDBC 持久性存储变得尤为重要。对于服务器故障,应进行服务迁移,并且将自动进行恢复。

  • 跨区域延迟

    要实现 6.5ms RTT 的跨区域延迟,并实施本文档为 FMW 拉伸群集提供的最佳做法:

    • 使用拉伸集群时性能会降低 (~10%)。
    • 对于在每个区域中有一台服务器的集群和同时在远程区域中两台服务器的集群,性能也会降低。这是因为群集内通信也受到延迟的影响。
  • 跨 AD 延迟

    跨 AD 延迟 (0.6ms) 对 SOA FOD 系统的整体性能没有显著影响。

注意:

考虑到上述所有因素,并且由于在许多测试中观察到的性能损失,Oracle 不支持 Oracle Fusion Middleware 延伸的集群在站点之间超过 10 毫秒的延迟 (RTT)。系统可以毫无问题地运行,但交易时间将大幅增加。超过 10 毫秒 (RTT) 的延迟也会导致 Oracle Coherence 集群中用于部署和 JT、Web 服务或应用程序超时的问题。这使得本手册中提供的解决方案主要适用于延迟较低的站点或区域。

在给具有 2 个节点的群集施加压力时,以下图表显示群集的整体性能,具体取决于服务器所在的位置。引用 (100%) 是两个服务器在与数据库相同的 AD 中运行时。



在强调具有 2 个节点的群集时,下图显示了与数据库搭配的服务器的性能相比(它位于其他 AD 或远程区域中)未与数据库搭配的服务器的性能:



在强调具有 2 个节点的集群时,这些图表显示每个服务器的活动数据源连接数(平均)。一台服务器始终与数据库 (site1) 托管,另一台服务器的延迟值与数据库 (site2) 不同:



在强调具有不同数据库延迟的单个服务器时,与与数据库共存的服务器相比,在中到高负载下,会观察到以下性能结果。引用 (100%) 是服务器与数据库位于同一 AD 中的时间。



当对具有不同延迟的单个服务器施加压力时,这是中到高压下的活动数据源连接:



强调单个服务器对数据库的延迟不同时,下图显示了不同延迟的平均 JTA 活动时间:



将集群的性能与数据库所在区域(仅本地)中的两台服务器进行比较时,与将两台服务器位于数据库所在区域(仅远程)不同的集群进行比较时,将观察到以下性能结果。引用 (100%) 是仅本地群集。



下图显示了具有两个服务器的集群的平均 JTA TX 活动时间,这两个服务器与数据库在同一区域中运行(仅本地),并且一个集群在与数据库不同的区域中运行两个服务器(仅远程)。



复查开始时间

在成员与数据库共存的集群中,在 Oracle WebLogic Server 上花费大量时间来开始创建连接池。

根据数据源中的初始容量设置,预计会出现不同的延迟。默认情况下,大多数 Oracle Fusion Middleware (FMW) 数据源的连接池的初始容量为零。但是,为了在正常运行时操作期间缩短系统的响应时间,可能会增加初始池容量。但是,在拉伸集群中,那些远程驻留在数据库中的服务器在启动时会随着初始池容量增加而显示延迟增加。

在正常运行期间优化响应时间和最小化开始时间以确定理想的初始容量设置之间,需要做出平衡的决策。由于初始容量是在数据源(连接池)级别配置的,因此这些设置会影响集群内所有服务器的启动时间(数据库本地服务器和远程服务器)。

下图显示了所有数据源(共 11 个数据源)中不同初始大小值的 WebLogic 服务器启动时间(随着数据库延迟的增长):



查看 JMS 服务迁移时间

使用 JDBC 持久性存储时,可以跨拉伸集群中的区域进行自动服务迁移,因为可以从每个区域访问 Java Message Service (JMS) 和事务处理日志 (TLOG) 数据。

但是,由于数据库延迟,从区域 1 到区域 2 的服务迁移操作所用的时间可能会增加。这种增加是由于在其他服务器中恢复消息所花费的时间,因为这些消息是从其他区域数据库中的持久性存储中读取的。

如果持久性存储有大量待处理消息,则增量会更高。对于大小为 2.7 KB 的 JMS 消息,下图显示了当其中一个持久性存储具有大量待处理消息(大约 8000 条)并且服务从与数据库搭配的服务器迁移到另一台服务器时,JMS 服务的迁移时间,以了解目标服务器与数据库之间的不同延迟:



下图显示了针对目标服务器和数据库之间不同延迟的服务迁移时间增量 (%),其中包含大量暂挂消息(大约 8000 条)。引用 (100%) 是服务迁移到与数据库位于同一可用性域 (Availability Domain,AD) 中的服务器时。



下图显示了同一案例的迁移时间,但对于目标服务器和数据库之间的不同延迟,暂挂消息数量较少(大约 50 条)。



下图显示了 JMS 服务迁移时间增量 (%),对于目标服务器与数据库之间的不同延迟,暂挂消息数量较少(大约 50 个)。引用 (100%) 是服务迁移到与数据库位于同一 AD 中的服务器时。



查看 SOA 组合部署时间

当专注于 SOA 时,部署和加载组合所花费的时间在延迟较高的服务器中会更高。

部署组合(部署其第一个版本或更新到较新版本)时,该组合可能比区域 2 中的服务器更早部署到区域 1 中的服务器,尽管在集群的所有成员中都可用之前不会正式激活该组合。

下图显示了在服务器启动期间在服务器中加载组合所花费的时间增加,与在位于与数据库相同的可用性域 (AD) 中的服务器中加载组合所花费的时间相比,数据库的延迟有所增加。组合大小为 365 KB。



下图显示了使用 Oracle WebLogic Scripting Tool (WLST) 命令部署组合所花费的时间增加,用于处理与执行部署到数据库的服务器不同的延迟。



检查站点之间的流量

本文档中提供的建议旨在尽可能地限制每个站点内的流量,以实现最常见的操作。

但是,这种隔离是非确定性的(例如,存在故障转移场景的空间,可以在两个站点上执行 Java Message Service (JMS) 调用)。也就是说,对于典型应用,大部分流量都发生在 Oracle WebLogic Server 实例与数据库之间。这将是 Oracle Fusion Middleware (FMW) 拉伸集群拓扑的性能的关键。此图显示了区域 2 中的 WebLogic 服务器与区域 1 中的不同地址之间的流量百分比(在压力测试期间)。请注意,超过 90% 的流量发生在服务器和位于区域 1 中的数据库之间。

要捕获站点之间每个 IP 的流量,可以使用 iftop 工具。例如:

sudo iftop -i ens3 -F <remote_site_CIDR> -n -t -s 900

下图显示了在压力测试期间区域 2 中的 WebLogic 服务器与区域 1 中的不同地址之间的流量百分比。