Tuxedo 超时控制（转贴）

源于才文章确实详细，暂且转载于此，谢原发帖主人。

Tuxedo 超时控制（转贴）
原帖发于DEV2DEV，现转贴在此。

                                           

                                                  TUXEDO超时控制全功略

摘要：
　　本《功略》集中了TUXEDO应用中，可能涉及到的所有时间参数，并分别对其进行详细描述，不但对其出处、取值等基本属性进行查证，而且，通过分析其内在的控制机制，给出设置建议，以期能够达到透彻理解、方便查阅、准确使用的目的。

1 前言
　　金融、电信等众多行业的综合营业系统中，广泛使用了TUXEDO交易中间件，用来处理大量并发的联机事务处理（OLTP）业务。典型的OLTP业务，每笔业务的信息量较小，而且，具有一定的实时性，对时间的要求非常严格。

　　TUXEDO，联系着DATABASE和客户端软件，凭借其多层次的超时控制机制，达到客户端快速响应，服务器端稳定可靠的效果。

　　TUXEDO的多层次的超时控制机制中，涉及到的时间参数不少于10个，再加上与之紧密联系的DATABASE中的几个超时参数，确实比较复杂。遗憾的是，目前还没有的专门的文档对它们进行详细说明，而是分散在不同的专题中分别说明，而且，不同的专题中，解释的详细程度也不一样，在查阅过程中，多有不便。

　　本文试图将这些参数集中起来，对每一个都加以详细说明，并试图解释每个参数存在的原因。大部分参数时间长短的设置，除个别外，基本没有固定的模式，只要了解它们的具体含义，并结合具体应用系统的实际要求，相信大家都能够作出合理的配置。

2 全功略解读
2.1 SCANUNIT
2.1.1 参数出处
　　UBBCONFIG配置文件 -> RESOURCES -> SCANUNIT 。

2.1.2 时间单位
　　秒,且必须为5的倍数。

2.1.3 取值范围
　　大于0小于等于60中5的倍数，即｛5，10，15，20，25，30，35，40，45，50，55，60｝。

2.1.4 默认取值
　　10 。

2.1.5 用途解释 ⑴
　　这个参数大家都会用，比较好理解，TUXEDO中，BBL是用来对Bulletin Board进行管理和监控的系统进程，它基于时间片的轮询方式，时间片的大小就是SCANUNIT的值，SCANUNIT是Tuxedo对系统进行管理的最基本时间单位。每隔SCANUNIT，BBL对Bulletin Board进行一次检查，看看有没有超时的事务或阻塞的服务请求。后面讲到的很多时间参数都是以SCANUNIT为单位。

2.1.6 超时后果
　　仅仅是个轮询时间单位而已，到时间就轮询，如此而已。

2.1.7 设置考虑
　　作为一个涉及到整个TUXDO系统的基本单位时间，如果业务需要，对时间参数控制比较严格，设置为5也不算小。如果系统业务对时间要求不严格，那就大点儿，60也没什么不可以；毕竟频繁轮询是要耗费更多系统资源的，而任何对资源的不必要的消耗都是浪费。

2.2 SANITYSCAN
2.2.1 参数出处
　　UBBCONFIG配置文件 -> RESOURCES -> SANITYSCAN 。

2.2.2 时间单位
　　SCANUNIT 。

2.2.3 取值范围
　　1 ～32767 。

2.2.4 默认取值
　　大约120/SCANUNIT。

2.2.5 用途解释 ⑵
　　进行系统健全性检查，主要包括Server进程状态和Bulletin Board数据结构，检查Server进程是否存活，如果已经不存在，会清理Bulletin Board中相应的数据项及IPC资源，并根据参数配置决定是否重新启动，如果设了RESTART=Y，所占的Message Queue不会被清除，Queue中的Request得到保留，仍会被处理。如果是MP模式，BBL还会给DBBL发状态消息。

2.2.6 超时后果
　　仅仅是个系统健康检查的间隔时间而已，到时间就检查，如此而已。

2.2.7 设置考虑
　　作为一个涉及到整个TUXDO系统健康检查的间隔时间，如果系统处在一个稳定的运行环境中，网络、数据库、应用都很稳定，那这个参数可以大一些；如果运行环境不稳定，系统繁忙，而且Server进程经常因异常（如超时）而死掉，那就设置小一些。设置的原则和SCANUNIT一样：不要随意浪费系统资源。

2.3 BBLQUERY
2.3.1 参数出处
　　UBBCONFIG配置文件 -> RESOURCES -> BBLQUERY。

2.3.2 时间单位
　　SCANUNIT

2.3.3 取值范围 ⑶
　　BBLQUERY必须大于等于SANITYSCAN，tmloadcf 时会强制检查，如果设的值小于SANITYSCAN，tmloadcf会自动调整为SANITYSCAN。

2.3.4 默认取值
　　大约300/SCANUNIT。

2.3.5 用途解释 ⑷
　　BBL检查，在MP模式下，BBL会每隔一段时间都发送了" I am ok "心跳信息给DBBL，这个间隔就是BBLQUERY。

2.3.6 超时后果 ⑸
　　如果DBBL在规定时间间隔内没有收到某个BBL的信息，DBBL它会主动发送Request给那个BBL，判断其是否正常。（如果等了DBBLWAIT后仍然没有回复，DBBL会认为那台机器有问题，然后，将其隔离。）

2.3.7 设置考虑
　　此设置仅仅在MP模式下才起作用。

　　在MP模式下，如果TUXEDO系统需要对不稳定的运行环境可能发生的故障作出快速的反应，那么BBLQUERY要设置小一些，让系统快速的自我检查。考虑网络传输时间、系统反应速度等因素，网络速度越慢，系统负载越重，取值越大；反之亦然。

　　如果系统运行环境很稳定，利用其默认值即可，甚至可以更大数值。

2.4 DBBLWAIT
2.4.1 参数出处
　　UBBCONFIG配置文件 -> RESOURCES -> DBBLWAIT。

2.4.2 时间单位
　　SCANUNIT。

2.4.3 取值范围
　　大于0。

2.4.4 默认取值
　　1和20/SCANUNIT中的较大者 。

2.4.5 用途解释 ⑹
　　如果DBBL在规定时间间隔BBLQUERY内没有收到某个BBL的"I AM OK"信息，它会发Request给那个BBL，其等待回复的时间就是DBBLWAIT。

2.4.6 超时后果 ⑺
　　DBBL等了DBBLWAIT后仍然没有回复，DBBL会认为相关BBL的机器有问题，然后，将其隔离（partation）。

2.4.7 设置考虑
　　此设置仅仅在MP模式下才起作用。

　　在MP模式下，考虑网络传输时间、系统反应速度等因素，网络速率越大，系统负载越轻，此数值越小；反之亦然。

2.5 BLOCKTIME
2.5.1 参数出处
　　UBBCONFIG配置文件 -> RESOURCES -> BLOCKTIME。

2.5.2 时间单位
　　SCANUNIT。

2.5.3 取值范围
　　大于0。

2.5.4 默认取值
　　大约60/SCANUNIT。

2.5.5 用途解释
　　Client端阻塞请求（Blocking call）服务的超时值，BBL发现有超时的Request时，会给相应的Client端发超时信息。

　　此参数仅仅在"阻塞请求"的情况下起作用，因此，理解它，关键要理解什么是阻塞请求（Blocking call）？习惯上，我们将"阻塞请求"理解为"同步请求"，将"异步请求"理解为"非阻塞请求"，是源于将"<发送请求－得到结果>"这一过程看成为一个整体。如果是整体的同步操作，就认为是"阻塞请求"；如果是分开异步的操作，就认为是"非阻塞请求"。

　　其实，异步操作中，同样存在"阻塞请求"，tuxedo中，tpacall和tpgetrply