EMS调优
本节内容将讨论TIBCO EMS服务器的多种调优选项。
1.1.1. 影响性能的因素
对于TIBCO EMS服务器的性能，有如下五个主要的影响因素：
l 基础架构和服务器配置
l 操作系统性能
n 网络IO，磁盘IO
n 其他的系统中断和系统调用
l 客户端应用的设计与实现
l 其他的网络通信量
l 其他进程的“窃取”周期
1.1.2. EMS与多CPU主机
EMS的守护进程是多线程的，因此，在多CPU的主机上运行时，能够获得更好的性能。需要注意的是，EMS的守护进程在很大程度上受IO的限制，并不一定是计算密集型的。因此，守护进程将有可能使用了大量的系统模式下的CPU时间，并有可能产生一个高层次的上下文切换。由此TIBCO EMS服务器在收到系统限制的情况下，多CPU并不一定能提供多少帮助。多数系统使用CPU0来处理所有的中断和系统调用，分布式系统中断可能会导致较低的缓存命中率和较低的性能。
多CPU系统上的分区有可能会对性能的提升有帮助，这取决于处理器的关联性设置和中断的处理。
在多CPU系统上，多线程的访问也需要注意，“Spin Locks”的使用会降低性能，更好的多线程核心能够帮助进行线程之间的同步。
1.1.3. EMS与网络调优
对于高IO的需求，服务器启动后，在耗尽CPU和内存之前，可能会受到操作系统的限制，因此，多CPU的服务器可能只会对TIBCO EMS有少量的性能提升。为了解决IO的问题，需要进行水平扩展，使用多服务器作为EMS基础架构的一部分。
从网络的角度，对一些可调整的参数进行改变，将有助于性能的提升，比如为TCP协议增加发送与接收的Windows缓存。
将消息限制在1300字节能够保证没有分段和重组(SAR，Segmentation andReassembly)。当出现消息堆积的时候，检查网络，保证SAR没有发生在MAC级别。在一些情况下，对消息的大小没有控制。
由此，在进行EMS调优时可以使用如下方法：
l 实现EMS服务器的水平扩充和负载均衡，将EMS的守护进程运行在不同的服务器之上，在守护进程之间使用路由进行消息的复制。
l 不要将多个EMS进程运行在同一台主机之上，除非是少量的消息传输
l 不要再EMS服务器上运行其他的进程，以减少网络中断，并对网络参数进行调优
l 采用立项的消息包大小，将消息控制在1300字节以下。
1.1.4. 消息性能与磁盘IO
磁盘IO是性能限制的一个因素，磁盘的机械速度相对处理的速度要慢很多。EMS消息在进行磁盘持久化时，有如下机制：
l 缓冲区写入，在系统崩溃时，可能会有小的缓冲区丢失，但是却能获得更好的性能。
l 异步写入(失败保护方式)：只有在写调用返回后才进行消息的处理，但是这样会有更多的系统和应用资源的耗费
写磁盘时会需要内存作为缓存。对缓存内存的恢复是系统调用的一部分，并且在内存有限的情况下，这种调用的速度并不是很快。从缓存中读数据很快；同步的删除和更新比异步(缓存)要慢很多。
通过提升磁盘IO的性能，能够大大的提高EMS消息处理的性能，物理磁盘性能的提升可以通过如下方式实现：
l 固态驱动器，本地电池备份缓存并带有“lazy write”功能的SAN和NAS驱动器，距离小于18KM的光纤
l 本地SCSI快于SAN快于NAS(带有多端口SCSI RAID的高可用性(HA)硬件要快于SAN或者NAS)
l 使用更大的内存，避免缓存与磁盘数据的交换
l 在生产环境中，限制不必要的追踪和日志(在某些情况下，可以通过打开或关闭规则来进行追踪和日志记录)
1.1.5. EMS性能与磁盘IO
可通过如下方式对EMS进行设置，提高磁盘的性能：
l 对持久化消息进行磁盘预分配
l 在可能的情况下，禁用文件截取和CRC校验
l 使用消息交换，而不适用操作系统交换，该配置与最大消息内存设置相关，需要对max_msg_memory参数进行设置，并启用msg_swapping。这种交换相比操作系统交换，提供了更高的性能
l 使用消息压缩，更少的在磁盘上存储文件，但是压缩会产生一些延迟
l 当使用持久化消息时，大的消息也会影响到性能，因为需要更多的时间将它写到磁盘当中。消息压缩在这时也能够提供帮助，并能进行流量的控制
1.1.6. 客户端
客户端处理是终极目标，合适的客户端应用的部署与设计能够提升EMS服务器的吞吐量和效率。为了提升客户端的性能，需要做如下的设置：
l 服务器设置
n 使用EMS路由关联广域网中的服务器
n 使用目的地桥接
l 目的地设置
n 使用非独占队列实现客户端的负载均衡
n 尽可能少的使用持久化订阅
n 启用消息的预获取选项，尤其是对体积小的消息
n 启用低级别的JMS可靠性模式
l 安全设置
n 只在没有VPN的情况下使用SSL
n 如果可能禁用认证
对于客户端的开发由如下建议：
l 使用多会话
l 消费并丢弃消息
l 不要在回调中花费太多的时间，在多CPU环境中，对回调使用多线程处理
l 评估不需要的JMS消息头字段。在默认情况下，时间戳作为JMS消息头的一部分被创建和发送。从性能的角度来说，它可以被禁用。除非有需要，建议禁用时间戳。
l 使用Time to Live属相，设置尽可能小的数值，将从$sys.undelivered中检索消息作为异常处理的一部分。建议为消息设置一个短的TTL(time to live)。他们会被自动移动到$sys.undelivered，用户可以有一个异常处理流程从这个队列中处理消息。
对于JAVA客户端建议如下：
l 不要使用默认的JVM设置
l 在服务器模式中，垃圾收集是最大的瓶颈之一