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  在服务器模式中，垃圾收集是最大的瓶颈之一