1. 背景

1.1. 话题来源

最近很多从事移动互联网和物联网开发的同学给我发邮件或者微博私信我，咨询推送服务相关的问题。问题五花八门，在帮助大家答疑解惑的过程中，我也对问题进行了总结，大概可以归纳为如下几类：

1. Netty是否可以做推送服务器？
2. 如果使用Netty开发推送服务，一个服务器最多可以支撑多少个客户端？
3. 使用Netty开发推送服务遇到的各种技术问题。

由于咨询者众多，关注点也比较集中，我希望通过本文的案例分析和对推送服务设计要点的总结，帮助大家在实际工作中少走弯路。

1.2. 推送服务

移动互联网时代，推送(Push)服务成为App应用不可或缺的重要组成部分，推送服务可以提升用户的活跃度和留存率。我们的手机每天接收到各种各样的广告和提示消息等大多数都是通过推送服务实现的。

随着物联网的发展，大多数的智能家居都支持移动推送服务，未来所有接入物联网的智能设备都将是推送服务的客户端，这就意味着推送服务未来会面临海量的设备和终端接入。

1.3. 推送服务的特点

移动推送服务的主要特点如下：

1. 使用的网络主要是运营商的无线移动网络，网络质量不稳定，例如在地铁上信号就很差，容易发生网络闪断；
2. 海量的客户端接入，而且通常使用长连接，无论是客户端还是服务端，资源消耗都非常大；
3. 由于谷歌的推送框架无法在国内使用，Android的长连接是由每个应用各自维护的，这就意味着每台安卓设备上会存在多个长连接。即便没有消息需要推送，长连接本身的心跳消息量也是非常巨大的，这就会导致流量和耗电量的增加；
4. 不稳定：消息丢失、重复推送、延迟送达、过期推送时有发生；
5. 垃圾消息满天飞，缺乏统一的服务治理能力。

为了解决上述弊端，一些企业也给出了自己的解决方案，例如京东云推出的推送服务，可以实现多应用单服务单连接模式，使用AlarmManager定时心跳节省电量和流量。

2. 智能家居领域的一个真实案例

2.1. 问题描述

智能家居MQTT消息服务中间件，保持10万用户在线长连接，2万用户并发做消息请求。程序运行一段时间之后，发现内存泄露，怀疑是Netty的Bug。其它相关信息如下：

1. MQTT消息服务中间件服务器内存16G，8个核心CPU；
2. Netty中boss线程池大小为1，worker线程池大小为6，其余线程分配给业务使用。该分配方式后来调整为worker线程池大小为11，问题依旧；
3. Netty版本为4.0.8.Final。

2.2. 问题定位

首先需要dump内存堆栈，对疑似内存泄露的对象和引用关系进行分析，如下所示：

我们发现Netty的ScheduledFutureTask增加了9076%，达到110W个左右的实例，通过对业务代码的分析发现用户使用IdleStateHandler用于在链路空闲时进行业务逻辑处理，但是空闲时间设置的比较大，为15分钟。

Netty 的IdleStateHandler会根据用户的使用场景，启动三类定时任务，分别是：ReaderIdleTimeoutTask、 WriterIdleTimeoutTask和AllIdleTimeoutTask，它们都会被加入到NioEventLoop的Task队列中被调度 和执行。

由 于超时时间过长，10W个长链接链路会创建10W个ScheduledFutureTask对象，每个对象还保存有业务的成员变量，非常消耗内存。用户的 持久代设置的比较大，一些定时任务被老化到持久代中，没有被JVM垃圾回收掉，内存一直在增长，用户误认为存在内存泄露。

事实上，我们进一步分析发现，用户的超时时间设置的非常不合理，15分钟的超时达不到设计目标，重新设计之后将超时时间设置为45秒，内存可以正常回收，问题解决。

2.3. 问题总结

如果是100个长连接，即便是长周期的定时任务，也不存在内存泄露问题，在新生代通过minor GC就可以实现内存回收。正是因为十万级的长连接，导致小问题被放大，引出了后续的各种问题。

事实上，如果用户确实有长周期运行的定时任务，该如何处理？对于海量长连接的推送服务，代码处理稍有不慎，就满盘皆输，下面我们针对Netty的架构特点，介绍下如何使用Netty实现百万级客户端的推送服务。

3. Netty海量推送服务设计要点

作为高性能的NIO框架，利用Netty开发高效的推送服务技术上是可行的，但是由于推送服务自身的复杂性，想要开发出稳定、高性能的推送服务并非易事，需要在设计阶段针对推送服务的特点进行合理设计。

3.1. 最大句柄数修改

百万长连接接入，首先需要优化的就是Linux内核参数，其中Linux最大文件句柄数是最重要的调优参数之一，默认单进程打开的最大句柄数是1024，通过ulimit -a可以查看相关参数，示例如下：

[root@lilinfeng ~]# ulimit -a core file size          (blocks, -c) 0 data seg size           (kbytes, -d) unlimited scheduling priority             (-e) 0 file size               (blocks, -f) unlimited pending signals                 (-i) 256324 max locked memory       (kbytes, -l) 64 max memory size         (kbytes, -m) unlimited open files                      (-n) 1024  ......后续输出省略

当单个推送服务接收到的链接超过上限后，就会报“too many open files”，所有新的客户端接入将失败。

通过vi /etc/security/limits.conf 添加如下配置参数：修改之后保存，注销当前用户，重新登录，通过ulimit -a 查看修改的状态是否生效。

*  soft        nofile        1000000 *  hard        nofile        1000000

需要指出的是，尽管我们可以将单个进程打开的最大句柄数修改的非常大，但是当句柄数达到一定数量级之后，处理效率将出现明显下降，因此，需要根据服务器的硬件配置和处理能力进行合理设置。如果单个服务器性能不行也可以通过集群的方式实现。

3.2. 当心CLOSE_WAIT

从事移动推送服务开发的同学可能都有体会，移动无线网络可靠性非常差，经常存在客户端重置连接，网络闪断等。

在百万长连接的推送系统中，服务端需要能够正确处理这些网络异常，设计要点如下：

1. 客户端的重连间隔需要合理设置，防止连接过于频繁导致的连接失败（例如端口还没有被释放）；
2. 客户端重复登陆拒绝机制；
3. 服务端正确处理I/O异常和解码异常等，防止句柄泄露。

最 后特别需要注意的一点就是close_wait 过多问题，由于网络不稳定经常会导致客户端断连，如果服务端没有能够及时关闭socket，就会导致处于close_wait状态的链路过多。 close_wait状态的链路并不释放句柄和内存等资源，如果积压过多可能会导致系统句柄耗尽，发生“Too many open files”异常，新的客户端无法接入，涉及创建或者打开句柄的操作都将失败。

下面对close_wait状态进行下简单介绍，被动关闭TCP连接状态迁移图如下所示：

图3-1 被动关闭TCP连接状态迁移图

close_wait 是被动关闭连接是形成的，根据TCP状态机，服务器端收到客户端发送的FIN，TCP协议栈会自动发送ACK，链接进入close_wait状态。但如果 服务器端不执行socket的close()操作，状态就不能由close_wait迁移到last_ack，则系统中会存在很多close_wait状 态的连接。通常来说，一个close_wait会维持至少2个小时的时间（系统默认超时时间的是7200秒，也就是2小时）。如果服务端程序因某个原因导 致系统造成一堆close_wait消耗资源，那么通常是等不到释放那一刻，系统就已崩溃。

导致close_wait过多的可能原因如下：

1. 程序处理Bug，导致接收到对方的fin之后没有及时关闭socket，这可能是Netty的Bug，也可能是业务层Bug，需要具体问题具体分析；
2. 关闭socket不及时：例如I/O线程被意外阻塞，或者I/O线程执行的用户自定义Task比例过高，导致I/O操作处理不及时，链路不能被及时释放。

下面我们结合Netty的原理，对潜在的故障点进行分析。

设 计要点1：不要在Netty的I/O线程上处理业务（心跳发送和检测除外）。Why? 对于Java进程，线程不能无限增长，这就意味着Netty的Reactor线程数必须收敛。Netty的默认值是CPU核数 * 2，通常情况下，I/O密集型应用建议线程数尽量设置大些，但这主要是针对传统同步I/O而言，对于非阻塞I/O，线程数并不建议设置太大，尽管没有最优 值，但是I/O线程数经验值是[CPU核数 + 1，CPU核数*2 ]之间。

假 如单个服务器支撑100万个长连接，服务器内核数为32，则单个I/O线程处理的链接数L = 100/(32 * 2) = 15625。 假如每5S有一次消息交互（新消息推送、心跳消息和其它管理消息），则平均CAPS = 15625 / 5 = 3125条/秒。这个数值相比于Netty的处理性能而言压力并不大，但是在实际业务处理中，经常会有一些额外的复杂逻辑处理，例如性能统计、记录接口日 志等，这些业务操作性能开销也比较大，如果在I/O线程上直接做业务逻辑处理，可能会阻塞I/O线程，影响对其它链路的读写操作，这就会导致被动关闭的链 路不能及时关闭，造成close_wait堆积。

设计要点2：在I/O线程上执行自定义Task要当心。Netty的I/O处理线程NioEventLoop支持两种自定义Task的执行：

1. 普通的Runnable: 通过调用NioEventLoop的execute(Runnable task)方法执行；
2. 定时任务ScheduledFutureTask:通过调用NioEventLoop的schedule(Runnable command, long delay, TimeUnit unit)系列接口执行。

为什么NioEventLoop要支持用户自定义Runnable和ScheduledFutureTask的执行，并不是本文要讨论的重点，后续会有专题文章进行介绍。本文重点对它们的影响进行分析。

在 NioEventLoop中执行Runnable和ScheduledFutureTask，意味着允许用户在NioEventLoop中执行非I/O操 作类的业务逻辑，这些业务逻辑通常用消息报文的处理和协议管理相关。它们的执行会抢占NioEventLoop I/O读写的CPU时间，如果用户自定义Task过多，或者单个Task执行周期过长，会导致I/O读写操作被阻塞，这样也间接导致close_wait 堆积。

所 以，如果用户在代码中使用到了Runnable和ScheduledFutureTask，请合理设置ioRatio的比例，通过 NioEventLoop的setIoRatio(int ioRatio)方法可以设置该值，默认值为50，即I/O操作和用户自定义任务的执行时间比为1：1。

我的建议是当服务端处理海量客户端长连接的时候，不要在NioEventLoop中执行自定义Task，或者非心跳类的定时任务。

设 计要点3：IdleStateHandler使用要当心。很多用户会使用IdleStateHandler做心跳发送和检测，这种用法值得提倡。相比于自 己启定时任务发送心跳，这种方式更高效。但是在实际开发中需要注意的是，在心跳的业务逻辑处理中，无论是正常还是异常场景，处理时延要可控，防止时延不可 控导致的NioEventLoop被意外阻塞。例如，心跳超时或者发生I/O异常时，业务调用Email发送接口告警，由于Email服务端处理超时，导 致邮件发送客户端被阻塞，级联引起IdleStateHandler的AllIdleTimeoutTask任务被阻塞，最终NioEventLoop多 路复用器上其它的链路读写被阻塞。

对于ReadTimeoutHandler和WriteTimeoutHandler，约束同样存在。

3.3. 合理的心跳周期

百万级的推送服务，意味着会存在百万个长连接，每个长连接都需要靠和App之间的心跳来维持链路。合理设置心跳周期是非常重要的工作，推送服务的心跳周期设置需要考虑移动无线网络的特点。

当 一台智能手机连上移动网络时，其实并没有真正连接上Internet，运营商分配给手机的IP其实是运营商的内网IP，手机终端要连接上Internet 还必须通过运营商的网关进行IP地址的转换，这个网关简称为NAT(NetWork Address Translation)，简单来说就是手机终端连接Internet 其实就是移动内网IP，端口，外网IP之间相互映射。

GGSN(GateWay GPRS Support Note)模块就实现了NAT功能，由于大部分的移动无线网络运营商为了减少网关NAT映射表的负荷，如果一个链路有一段时间没有通信时就会删除其对应 表，造成链路中断，正是这种刻意缩短空闲连接的释放超时，原本是想节省信道资源的作用，没想到让互联网的应用不得以远高于正常频率发送心跳来维护推送的长 连接。以中移动的2.5G网络为例，大约5分钟左右的基带空闲，连接就会被释放。

由 于移动无线网络的特点，推送服务的心跳周期并不能设置的太长，否则长连接会被释放，造成频繁的客户端重连，但是也不能设置太短，否则在当前缺乏统一心跳框 架的机制下很容易导致信令风暴（例如微信心跳信令风暴问题）。具体的心跳周期并没有统一的标准，180S也许是个不错的选择，微信为300S。

在Netty中，可以通过在ChannelPipeline中增加IdleStateHandler的方式实现心跳检测，在构造函数中指定链路空闲时间，然后实现空闲回调接口，实现心跳的发送和检测，代码如下：

public void initChannel({@link Channel} channel) {  channel.pipeline().addLast("idleStateHandler", new {@link   IdleStateHandler}(0, 0, 180));  channel.pipeline().addLast("myHandler", new MyHandler()); } 拦截链路空闲事件并处理心跳：  public class MyHandler extends {@link ChannelHandlerAdapter} {      {@code @Override}       public void userEventTriggered({@link ChannelHandlerContext} ctx, {@link Object} evt) throws {@link Exception} {           if (evt instanceof {@link IdleStateEvent}} {               //心跳处理           }       }   }

3.4. 合理设置接收和发送缓冲区容量

对于长链接，每个链路都需要维护自己的消息接收和发送缓冲区，JDK原生的NIO类库使用的是java.nio.ByteBuffer,它实际是一个长度固定的Byte数组，我们都知道数组无法动态扩容，ByteBuffer也有这个限制，相关代码如下：

public abstract class ByteBuffer     extends Buffer     implements Comparable {     final byte[] hb; // Non-null only for heap buffers     final int offset;     boolean isReadOnly;

容 量无法动态扩展会给用户带来一些麻烦，例如由于无法预测每条消息报文的长度，可能需要预分配一个比较大的ByteBuffer，这通常也没有问题。但是在 海量推送服务系统中，这会给服务端带来沉重的内存负担。假设单条推送消息最大上限为10K，消息平均大小为5K，为了满足10K消息的处 理，ByteBuffer的容量被设置为10K，这样每条链路实际上多消耗了5K内存，如果长链接链路数为100万，每个链路都独立持有 ByteBuffer接收缓冲区，则额外损耗的总内存 Total(M) = 1000000 * 5K = 4882M。内存消耗过大，不仅仅增加了硬件成本，而且大内存容易导致长时间的Full GC，对系统稳定性会造成比较大的冲击。

实际上，最灵活的处理方式就是能够动态调整内存，即接收缓冲区可以根据以往接收的消息进行计算，动态调整内存，利用CPU资源来换内存资源，具体的策略如下：

1. ByteBuffer支持容量的扩展和收缩，可以按需灵活调整，以节约内存；
2. 接收消息的时候，可以按照指定的算法对之前接收的消息大小进行分析，并预测未来的消息大小，按照预测值灵活调整缓冲区容量，以做到最小的资源损耗满足程序正常功能。

幸运的是，Netty提供的ByteBuf支持容量动态调整，对于接收缓冲区的内存分配器，Netty提供了两种：

1. FixedRecvByteBufAllocator：固定长度的接收缓冲区分配器，由它分配的ByteBuf长度都是固定大小的，并不会根据实际数据报 的大小动态收缩。但是，如果容量不足，支持动态扩展。动态扩展是Netty ByteBuf的一项基本功能，与ByteBuf分配器的实现没有关系；
2. AdaptiveRecvByteBufAllocator：容量动态调整的接收缓冲区分配器，它会根据之前Channel接收到的数据报大小进行计算， 如果连续填充满接收缓冲区的可写空间，则动态扩展容量。如果连续2次接收到的数据报都小于指定值，则收缩当前的容量，以节约内存。

相对于FixedRecvByteBufAllocator，使用AdaptiveRecvByteBufAllocator更为合理，可以在创建客户端或者服务端的时候指定RecvByteBufAllocator，代码如下：

 Bootstrap b = new Bootstrap();             b.group(group)              .channel(NioSocketChannel.class)              .option(ChannelOption.TCP_NODELAY, true)              .option(ChannelOption.RCVBUF_ALLOCATOR, AdaptiveRecvByteBufAllocator.DEFAULT)

如果默认没有设置，则使用AdaptiveRecvByteBufAllocator。

另外值得注意的是，无论是接收缓冲区还是发送缓冲区，缓冲区的大小建议设置为消息的平均大小，不要设置成最大消息的上限，这会导致额外的内存浪费。通过如下方式可以设置接收缓冲区的初始大小：

/** 	 * Creates a new predictor with the specified parameters. 	 *  	 * @param minimum 	 *            the inclusive lower bound of the expected buffer size 	 * @param initial 	 *            the initial buffer size when no feed back was received 	 * @param maximum 	 *            the inclusive upper bound of the expected buffer size 	 */ 	public AdaptiveRecvByteBufAllocator(int minimum, int initial, int maximum) 

对于消息发送，通常需要用户自己构造ByteBuf并编码，例如通过如下工具类创建消息发送缓冲区：

图3-2 构造指定容量的缓冲区

3.5. 内存池

推送服务器承载了海量的长链接，每个长链接实际就是一个会话。如果每个会话都持有心跳数据、接收缓冲区、指令集等数据结构，而且这些实例随着消息的处理朝生夕灭，这就会给服务器带来沉重的GC压力，同时消耗大量的内存。

最 有效的解决策略就是使用内存池，每个NioEventLoop线程处理N个链路，在线程内部，链路的处理时串行的。假如A链路首先被处理，它会创建接收缓 冲区等对象，待解码完成之后，构造的POJO对象被封装成Task后投递到后台的线程池中执行，然后接收缓冲区会被释放，每条消息的接收和处理都会重复接 收缓冲区的创建和释放。如果使用内存池，则当A链路接收到新的数据报之后，从NioEventLoop的内存池中申请空闲的ByteBuf，解码完成之 后，调用release将ByteBuf释放到内存池中，供后续B链路继续使用。

使用内存池优化之后，单个NioEventLoop的ByteBuf申请和GC次数从原来的N = 1000000/64 = 15625 次减少为最少0次（假设每次申请都有可用的内存）。

下面我们以推特使用Netty4的PooledByteBufAllocator进行GC优化作为案例，对内存池的效果进行评估，结果如下：

垃圾生成速度是原来的1/5，而垃圾清理速度快了5倍。使用新的内存池机制，几乎可以把网络带宽压满。

Netty4 之前的版本问题如下：每当收到新信息或者用户发送信息到远程端，Netty 3均会创建一个新的堆缓冲区。这意味着，对应每一个新的缓冲区，都会有一个new byte[capacity]。这些缓冲区会导致GC压力，并消耗内存带宽。为了安全起见，新的字节数组分配时会用零填充，这会消耗内存带宽。然而，用零 填充的数组很可能会再次用实际的数据填充，这又会消耗同样的内存带宽。如果Java虚拟机（JVM）提供了创建新字节数组而又无需用零填充的方式，那么我 们本来就可以将内存带宽消耗减少50%，但是目前没有那样一种方式。

在Netty 4中实现了一个新的ByteBuf内存池，它是一个纯Java版本的 jemalloc （Facebook也在用）。现在，Netty不会再因为用零填充缓冲区而浪费内存带宽了。不过，由于它不依赖于GC，开发人员需要小心内存泄漏。如果忘记在处理程序中释放缓冲区，那么内存使用率会无限地增长。

Netty默认不使用内存池，需要在创建客户端或者服务端的时候进行指定，代码如下：

Bootstrap b = new Bootstrap();             b.group(group)              .channel(NioSocketChannel.class)              .option(ChannelOption.TCP_NODELAY, true)              .option(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT)

使用内存池之后，内存的申请和释放必须成对出现，即retain()和release()要成对出现，否则会导致内存泄露。

值得注意的是，如果使用内存池，完成ByteBuf的解码工作之后必须显式的调用ReferenceCountUtil.release(msg)对接收缓冲区ByteBuf进行内存释放，否则它会被认为仍然在使用中，这样会导致内存泄露。

3.6. 当心“日志隐形杀手”

通常情况下，大家都知道不能在Netty的I/O线程上做执行时间不可控的操作，例如访问数据库、发送Email等。但是有个常用但是非常危险的操作却容易被忽略，那便是记录日志。

通 常，在生产环境中，需要实时打印接口日志，其它日志处于ERROR级别，当推送服务发生I/O异常之后，会记录异常日志。如果当前磁盘的WIO比较高，可 能会发生写日志文件操作被同步阻塞，阻塞时间无法预测。这就会导致Netty的NioEventLoop线程被阻塞，Socket链路无法被及时关闭、其 它的链路也无法进行读写操作等。

以最常用的log4j为例，尽管它支持异步写日志（AsyncAppender），但是当日志队列满之后，它会同步阻塞业务线程，直到日志队列有空闲位置可用，相关代码如下：

 synchronized (this.buffer) {       while (true) {         int previousSize = this.buffer.size();         if (previousSize < this.bufferSize) {           this.buffer.add(event);           if (previousSize != 0) break;           this.buffer.notifyAll(); break;         }         boolean discard = true;         if ((this.blocking) && (!Thread.interrupted()) && (Thread.currentThread() != this.dispatcher)) //判断是业务线程         {           try           {             this.buffer.wait();//阻塞业务线程             discard = false;           }           catch (InterruptedException e)           {             Thread.currentThread().interrupt();           }          }

类似这类BUG具有极强的隐蔽性，往往WIO高的时间持续非常短，或者是偶现的，在测试环境中很难模拟此类故障，问题定位难度非常大。这就要求读者在平时写代码的时候一定要当心，注意那些隐性地雷。

3.7. TCP参数优化

常用的TCP参数，例如TCP层面的接收和发送缓冲区大小设置，在Netty中分别对应ChannelOption的SO_SNDBUF和SO_RCVBUF，需要根据推送消息的大小，合理设置，对于海量长连接，通常32K是个不错的选择。

另外一个比较常用的优化手段就是软中断，如图所示：如果所有的软中断都运行在CPU0相应网卡的硬件中断上，那么始终都是cpu0在处理软中断，而此时其它CPU资源就被浪费了，因为无法并行的执行多个软中断。

图3-3 中断信息

大 于等于2.6.35版本的Linux kernel内核，开启RPS，网络通信性能提升20%之上。RPS的基本原理：根据数据包的源地址，目的地址以及目的和源端口，计算出一个hash值， 然后根据这个hash值来选择软中断运行的cpu。从上层来看，也就是说将每个连接和cpu绑定，并通过这个hash值，来均衡软中断运行在多个cpu 上，从而提升通信性能。

3.8. JVM参数

最重要的参数调整有两个：

• -Xmx:JVM最大内存需要根据内存模型进行计算并得出相对合理的值；
• GC相关的参数: 例如新生代和老生代、永久代的比例，GC的策略，新生代各区的比例等，需要根据具体的场景进行设置和测试，并不断的优化，尽量将Full GC的频率降到最低。

4. 作者简介

李林锋，2007年毕业于东北大学，2008年进入华为公司从事高性能通信软件的设计和开发工作，有6年NIO设计和开发经验，精通Netty、Mina等NIO框架。Netty中国社区创始人，《Netty权威指南》作者。

Netty4

Netty是一个和MINA类似的Java NIO框架，目前的最新版本是4.0.13，这两个框架的主要作者好像都是同一个韩国人。

Channel

Channel是Netty最核心的接口，一个Channel就是一个联络Socket的通道，通过Channel，你可以对Socket进行各种操作。

ChannelHandler

用Netty编写网络程序的时候，你很少直接操纵Channel，而是通过ChannelHandler来间接操纵Channel。

Netty中的所有handler都实现自ChannelHandler接口。按照输出输出来分，分为ChannelInboundHandler、ChannelOutboundHandler两大类。

ChannelInboundHandler对从客户端发往服务器的报文进行处理，一般用来执行解码、读取客户端数据、进行业务处理等；

ChannelOutboundHandler对从服务器发往客户端的报文进行处理，一般用来进行编码、发送报文到客户端。

ChannelPipeline

ChannelPipeline实际上应该叫做ChannelHandlerPipeline，可以把ChannelPipeline看成是一个ChandlerHandler的链表，当需要对Channel进行某种处理的时候，Pipeline负责依次调用每一个Handler进行处理。每个Channel都有一个属于自己的Pipeline，调用Channel#pipeline()方法可以获得Channel的Pipeline，调用Pipeline#channel()方法可以获得Pipeline的Channel。

ChannelPipeline的方法有很多，其中一部分是用来管理ChannelHandler的，如下面这些：

ChannelPipeline addFirst(String name, ChannelHandler handler); ChannelPipeline addLast(String name, ChannelHandler handler); ChannelPipeline addBefore(String baseName, String name, ChannelHandler handler); ChannelPipeline addAfter(String baseName, String name, ChannelHandler handler); ChannelPipeline remove(ChannelHandler handler); ChannelHandler remove(String name); ChannelHandler removeFirst(); ChannelHandler removeLast(); ChannelPipeline replace(ChannelHandler oldHandler, String newName, ChannelHandler newHandler); ChannelHandler replace(String oldName, String newName, ChannelHandler newHandler); ChannelHandler first(); ChannelHandler last(); ChannelHandler get(String name);

ChannelHandlerContext

ChannelPipeline并不是直接管理ChannelHandler，而是通过ChannelHandlerContext来间接管理，这一点通过ChannelPipeline的默认实现DefaultChannelPipeline可以看出来。

调用ChannelHandlerContext#channel()方法可以得到和Context绑定的Channel，调用ChannelHandlerContext#handler()方法可以得到和Context绑定的Handler。

ChannelPipeline和ChannelHandlerContext默认实现

DefaultChannelHandlerContext和DefaultChannelPipeline是ChannelHandlerContext和ChannelPipeline的默认实现，下面是它们的部分代码：

final class DefaultChannelHandlerContext extends DefaultAttributeMap implements ChannelHandlerContext {      volatile DefaultChannelHandlerContext next;     volatile DefaultChannelHandlerContext prev;      private final boolean inbound;     private final boolean outbound;     private final AbstractChannel channel;     private final DefaultChannelPipeline pipeline;     private final String name;     private final ChannelHandler handler;     private boolean removed;      // ... }

final class DefaultChannelPipeline implements ChannelPipeline {     // ...      final DefaultChannelHandlerContext head;     final DefaultChannelHandlerContext tail;      // ... }

从上面的代码可以看出，在DefaultPipeline内部，DefaultChannelHandlerContext组成了一个双向链表：

再来看看DefaultChannelPipeline的构造函数：

    public DefaultChannelPipeline(AbstractChannel channel) {         if (channel == null) {             throw new NullPointerException("channel");         }         this.channel = channel;          TailHandler tailHandler = new TailHandler();         tail = new DefaultChannelHandlerContext(this, null, generateName(tailHandler), tailHandler);          HeadHandler headHandler = new HeadHandler(channel.unsafe());         head = new DefaultChannelHandlerContext(this, null, generateName(headHandler), headHandler);          head.next = tail;         tail.prev = head;     }

可以看到，DefaultChinnelPipeline内部使用了两个特殊的Handler来表示Handler链的头和尾：

ChannelHandler的种类

Netty中的所有handler都实现自ChannelHandler接口。按照输出输出来分，分为ChannelInboundHandler、ChannelOutboundHandler两大类。ChannelInboundHandler对从客户端发往服务器的报文进行处理，一般用来执行解码、读取客户端数据、进行业务处理等；ChannelOutboundHandler对从服务器发往客户端的报文进行处理，一般用来进行编码、发送报文到客户端。

从上面DefaultChannelHandlerContext代码可以知道，Handler实际上分为两种，Inbound和Outbound，这一点也可以从ChannelHandler接口的子接口得到证明：

public interface ChannelInboundHandler extends ChannelHandler {   // ... }  public interface ChannelOutboundHandler extends ChannelHandler {   // ... }

事件的传播

为了搞清楚事件如何在Pipeline里传播，让我们从Channel的抽象子类AbstractChannel开始，下面是AbstractChannel#write()方法的实现：

public abstract class AbstractChannel extends DefaultAttributeMap implements Channel {     // ...     @Override     public Channel write(Object msg) {         return pipeline.write(msg);     }     // ... }

AbstractChannel直接调用了Pipeline的write()方法：

final class DefaultChannelPipeline implements ChannelPipeline {     // ...     @Override     public ChannelFuture write(Object msg) {         return tail.write(msg);     }     // ... }

因为write是个outbound事件，所以DefaultChannelPipeline直接找到tail部分的context，调用其write()方法：

接着看DefaultChannelHandlerContext的write()方法：

final class DefaultChannelHandlerContext extends DefaultAttributeMap implements ChannelHandlerContext {     // ...     @Override     public ChannelFuture write(Object msg) {         return write(msg, newPromise());     }      @Override     public ChannelFuture write(final Object msg, final ChannelPromise promise) {         if (msg == null) {             throw new NullPointerException("msg");         }          validatePromise(promise, true);          write(msg, false, promise);          return promise;     }      private void write(Object msg, boolean flush, ChannelPromise promise) {         DefaultChannelHandlerContext next = findContextOutbound();         next.invokeWrite(msg, promise);         if (flush) {             next.invokeFlush();         }     }      private DefaultChannelHandlerContext findContextOutbound() {         DefaultChannelHandlerContext ctx = this;         do {             ctx = ctx.prev;         } while (!ctx.outbound);         return ctx;     }      private void invokeWrite(Object msg, ChannelPromise promise) {         try {             ((ChannelOutboundHandler) handler).write(this, msg, promise);         } catch (Throwable t) {             notifyOutboundHandlerException(t, promise);         }     }      // ... }

context的write()方法沿着context链往前找，直至找到一个outbound类型的context为止，然后调用其invokeWrite()方法：

invokeWrite()接着调用handler的write()方法：

最后看看ChannelOutboundHandlerAdapter的write()方法实现：

public class ChannelOutboundHandlerAdapter extends ChannelHandlerAdapter implements ChannelOutboundHandler {     // ...     @Override     public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {         ctx.write(msg, promise);     }     // ... }

默认的实现调用了context的write()方法而不做任何处理，这样write事件就沿着outbound链继续传播：

可见，Pipeline的事件传播，是靠Pipeline，Context和Handler共同协作完成的。

1、用于创建逻辑组合关系的类

• AND条件（AndTerm类）
• OR条件（OrTerm类）
• NOT条件（NotTerm类）
• Comparison条件（ComparisonTerm类）

2、用于创建具体搜索条件的类

• DATE条件（SentDateTerm、ReceivedDateTerm类）
• CONTENT条件（BodyTerm类）
• HEADER条件（FromStringTerm、RecipientStringTerm、SubjectTerm类等）

下面通过实现来说明以上类的用法及含义：

1、搜索发件人为“智联招聘“，而且邮件正文包含“Java工程师“的所有邮件

SearchTerm andTerm = new AndTerm( new FromStringTerm("智联招聘"), new BodyTerm("java工程师")); Message[] messages = folder.search(andTerm); 

2、搜索发件人为“智联招聘“或主题包含“最新职位信息“的所有邮件

SearchTerm orTerm = new OrTerm( new FromStringTerm("智联招聘"), new SubjectTerm("最新职位信息")); Message[] messages = folder.search(orTerm); 

3、搜索发件人不包含“智联招聘“所有的邮件

SearchTerm notTerm = new NotTerm(new FromStringTerm("智联招聘")); Message[] messages = folder.search(notTerm); 

4、搜索周一到今天收到的的所有邮件

Calendar calendar = Calendar.getInstance();  
calendar.set(Calendar.DAY_OF_WEEK, calendar.get(Calendar.DAY_OF_WEEK - (Calendar.DAY_OF_WEEK - 1)) - 1); 
Date mondayDate = calendar.getTime(); 
SearchTerm comparisonTermGe = new SentDateTerm(ComparisonTerm.GE, mondayDate); 
SearchTerm comparisonTermLe = new SentDateTerm(ComparisonTerm.LE, new Date()); 
SearchTerm comparisonAndTerm = new AndTerm(comparisonTermGe, comparisonTermLe); 
Message[] messages = folder.search(comparisonAndTerm); 

5、搜索大于或等100KB的所有邮件

int mailSize = 1024 * 100; SearchTerm intComparisonTerm = new SizeTerm(IntegerComparisonTerm.GE, mailSize); 
Message[] messages = folder.search(intComparisonTerm); 

ComparisonTerm类常用于日期和数字比较中，它使用六个常量EQ（＝）、GE（>=）、GT（>）、LE（<=）、LT（<）、NE（!=）来表示六种不同的比较操作。

下面是完整代码：

import java.io.BufferedReader;   
import java.io.InputStreamReader;   
import java.util.Calendar;   
import java.util.Date;   
import java.util.Properties;   

import javax.mail.Flags.Flag;   
import javax.mail.Folder;   
import javax.mail.Message;   
import javax.mail.Session;   
import javax.mail.Store;   
import javax.mail.URLName;   
import javax.mail.internet.MimeMessage;   
import javax.mail.internet.MimeUtility;   
import javax.mail.search.AndTerm;   
import javax.mail.search.BodyTerm;   
import javax.mail.search.ComparisonTerm;   
import javax.mail.search.FromStringTerm;   
import javax.mail.search.IntegerComparisonTerm;   
import javax.mail.search.NotTerm;   
import javax.mail.search.OrTerm;   
import javax.mail.search.SearchTerm;   
import javax.mail.search.SentDateTerm;   
import javax.mail.search.SizeTerm;   
import javax.mail.search.SubjectTerm;   

/** 
 * 搜索邮件 
 */   
public class SearchMailTest {   

    public static void main(String[] args) throws Exception {   
        Properties props = new Properties();   
        props.setProperty("mail.pop3.auth", "true");   
        Session session = Session.getInstance(props);   
        URLName url = new URLName("pop3", "pop3.163.com", 110, null, "xyang81@163.com", "yX546900873");   
        Store store = session.getStore(url);   
        store.connect();   
        // 得到收件箱   
        Folder folder = store.getFolder("INBOX");   
        // 以读写模式打开收件箱   
        folder.open(Folder.READ_WRITE);   

        Message[] messages = search(folder);   

        System.out.println("收件箱中共有:" + folder.getMessageCount() + "封邮件，搜索到" + messages.length + "封符合条件的邮件!");   

        // 解析邮件搜索到的邮件   
        POP3ReceiveMailTest.parseMessage(messages);    

        // 根据用户输入的条件搜索所有邮件,并提示用户是否删除   
        //searchDemo(folder);   

        folder.close(true);   
        store.close();   
    }   
             www.2cto.com  
    public static Message[] search(Folder folder) throws Exception {   
        // 搜索主题包含美食的邮件   
        String subject = "java培训";   
        SearchTerm subjectTerm = new SubjectTerm(subject);   

        // 搜索发件人包含支付宝的邮件   
        SearchTerm fromTerm = new FromStringTerm("支付宝");   

        // 搜索邮件内容包含"招聘"的邮件   
        SearchTerm bodyTerm = new BodyTerm("招聘");   

        // 搜索发件人不包含“智联招聘”的邮件   
        SearchTerm notTerm = new NotTerm(new FromStringTerm("智联招聘"));   

        // 搜索发件人为“智联招聘”，而且内容包含“Java工程师“的邮件   
        SearchTerm andTerm = new AndTerm(   
                new FromStringTerm("智联招聘"),   
                new BodyTerm("java工程师"));   

        // 搜索发件人为”智联招聘“或主题包含”最新职位信息“的邮件   
        SearchTerm orTerm = new OrTerm(   
                new FromStringTerm("智联招聘"),    
                new SubjectTerm("最新职位信息"));   

        // 搜索周一到今天收到的的所有邮件   
        Calendar calendar = Calendar.getInstance();   
        calendar.set(Calendar.DAY_OF_WEEK, calendar.get(Calendar.DAY_OF_WEEK - (Calendar.DAY_OF_WEEK - 1)) - 1);   
        Date mondayDate = calendar.getTime();   
        SearchTerm comparisonTermGe = new SentDateTerm(ComparisonTerm.GE, mondayDate);   
        SearchTerm comparisonTermLe = new SentDateTerm(ComparisonTerm.LE, new Date());   
        SearchTerm comparisonAndTerm = new AndTerm(comparisonTermGe, comparisonTermLe);   

        // 搜索大于或等100KB的所有邮件   
        int mailSize = 1024 * 100;   
        SearchTerm intComparisonTerm = new SizeTerm(IntegerComparisonTerm.GE, mailSize);   

        return folder.search(intComparisonTerm);   
    }   
 }   
实例：根据用户输入的收件人（email地址或姓名）和主题作为搜索条件，并提示用户是否删除搜索到的邮件？  
[java] view plaincopy  
/** 
     * 根据用户输入的收件人地址（包括email地址和姓名）和主题作为搜索条件，并提示用户是否删除搜索到的邮件 
     * @param from 收件人 
     * @param subject 主题 
     */   
    public static void searchDemo(Folder folder) throws Exception {   
        String notifyMsg = "收件箱中一共有" + folder.getMessageCount() + "封邮件。请选择操作：\n";   
        notifyMsg += "1、输入收件人\n" + "2、输入主题\n" + "3、开始搜索\n" + "4、退出";   
        System.out.println(notifyMsg);   
        String from = null;   
        String subject = null;   
        BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));   
        String oper = reader.readLine().trim();   
        while(!(from != null && subject != null)) {   
            if ("4".equals(oper)) {   
                System.exit(0);   
            } else {   
                if ("1".equals(oper)) {   
                    System.out.print("请输入收件人：");   
                    from = reader.readLine();   
                }  else if ("2".equals(oper)) {   
                    System.out.print("请输入主题：");   
                    subject = reader.readLine();   
                } else if ("3".equals(oper)) {   
                    if (from == null || subject == null) {   
                        System.out.println("未输入搜索条件，无法进行搜索！");   
                    } else {   
                        break;   
                    }   
                }   
            }   
            System.out.print("请选择操作：");   
            oper = reader.readLine().trim();   
        }   

        System.out.println("\n系统正在根据搜索条件查询所有邮件，请稍候\n");   

        // 根据输入的条件，创建SearchTerm实例对象   
        SearchTerm orTerm = new OrTerm(   
                new FromStringTerm(from),   
                new SubjectTerm(subject)   
                );   

        // 根据搜索条件得到搜索到的邮件列表   
        Message[] messages = folder.search(orTerm);   

        System.out.println("共搜索到" + messages.length + "封满足搜索条件的邮件！\n\n请选择操作：1、查看邮件\t 2、删除所有邮件");   

        String deleteQuestion = "是否要删除搜索到的邮件?(yes/no)";   

        String searchResultOper = reader.readLine();   

        if ("1".equals(searchResultOper)) {   
            for (Message message : messages) {   
                MimeMessage msg = (MimeMessage) message;   
                String sub = POP3ReceiveMailTest.getSubject(msg);   
                System.out.println("开始查看第" + msg.getMessageNumber() + "封邮件");   
                System.out.println("主题: " + sub);   
                System.out.println("发件人: " + POP3ReceiveMailTest.getFrom(msg));   
                System.out.println("收件人：" + POP3ReceiveMailTest.getReceiveAddress(msg, null));   
                System.out.println("发送时间：" + POP3ReceiveMailTest.getSentDate(msg, null));   
                System.out.println(deleteQuestion);   
                String answer = reader.readLine();   
                if ("yes".equals(answer)) {   
                    msg.setFlag(Flag.DELETED, true);   
                    System.out.println("邮件[" + sub + "]删除成功!");   
                } else if ("no".equals(answer)) {   
                    System.out.println("第" + msg.getMessageNumber() + "封邮件查看完成！");   
                } else if ("stop".equals(answer)) {   
                    System.exit(0);   
                }   
                System.out.println();   
            }   
        } else {   
            System.out.println(deleteQuestion);   
            String answer = reader.readLine();   
            if ("yes".equals(answer)) {   
                for (Message message : messages) {   
                    String sub = MimeUtility.decodeText(message.getSubject());   
                    message.setFlag(Flag.DELETED, true);   
                    System.out.println("邮件[" + sub + "]删除成功!");   
                }   
            }   
        }   
    }
}

首先我们要知道，我们在使用FTP上传、删除、修改文件的时候其实要经过两个过程。一个是命令连接，一个是数据传输。命令连接的过程是我们电脑->服务器，通常是我们电脑中一个随机的大于1024的端口->服务器的21端口。我们熟知的FTP的21端口就是建议命令连接时所必需的。对于这主动和被动这两种上传模式而言，命令连接的过程是完全相同的，其区别就在数据传输过程中。主动模式下，当需要传送数据时，客户端在命令连接上用PORT命令告诉服务器：&ldquo;我打开了XXXX端口（通常是一个随机的大于1024的端口），你过来连接我&rdquo;。于是服务器从20端口向客户端的这个端口发送连接请求，建立一条数据连接来传送数据，这就是服务器->客户电脑的过程。而在被动模式下，服务器在命令连接上用PASV命令告诉客户端：&ldquo;我打开了XXXX端口（通常是在FTP服务端设置的一个高位端口范围），你过来连接我&rdquo;。于是客户端向服务器的这个端口范围发送连接请求，建立一条数据连接来传送数据。

一句话，主动模式的FTP是指服务器主动连接客户端的数据端口，被动模式的FTP是指服务器被动地等待客户端连接自己的数据端口。故通过防火墙对高位端口的阻塞，会造成主动模式受限，被动模式比较先进。另外通过设置被动模式的端口范围，只开放一定的端口对外传输数据，也大大减少了服务器安全性暴露的风险。

那么，在哪里设置被动模式的端口范围呢。Windows环境下的IIS FTP的设置方法是：打开C:\WINDOWS\system32\inetsrv\MetaBase.xml，当然首先要停止IIS Admin Service服务。然后编辑这个文件里面<IIsFtpService>区块下的PassivePortRange，比如设置成PassivePortRange="50030-50039"，这就指定了10个端口来传输数据。而Linux环境下的ProFTP的设置方法是：打开proftp的配置文件，命令是vi /etc/proftpd.conf，然后在<Global>区块里面添加PassivePorts 50030 50039这样的一段文字，也和上面IIS中的端口设置是一样的功能。

最后在说下这两种模式的优缺点。主动模式对FTP服务器的管理有利，但对客户端的管理不利。因为FTP服务器企图与客户端的高位随机端口建立连接，而这个端口很有可能被客户端的防火墙阻塞掉。被动模式对FTP客户端的管理有利，但对服务器端的管理不利。因为客户端要与服务器端建立两个连接，其中一个连到一个高位随机端口，而这个端口很有可能被服务器端的防火墙阻塞掉。比较明智的方法是，同时做好服务器和客户电脑的安全设置，尽量不要开防火墙，就能比较顺利的通过FTP上传和管理我们的文件。

• 服务接口

• 接口实现

• 发布服务

In order to generate functional remote references, Java RMI servers must be able to supply a fully qualified hostname or IP address that is resolvable from all Java RMI clients (an example of a fully qualified hostname is foo.bar.com). If a Java RMI program provides a remote callback operation, then that program serves a Java RMI object and consequently, must be able to determine a resolvable hostname to use as its server hostname in the remote references it passes to Java RMI clients. VMs that make calls to applets that serve remote objects may throwUnknownHostExceptions because the applet has failed to provide a usable server hostname.

If your Java RMI application throws an UnknownHostException, you can look at the resulting stack trace to see if the hostname that the client is using to contact its remote server is incorrect or not fully qualified.【 If necessary, you can set the java.rmi.server.hostname property on the server to the correct IP address or hostname of the server machine and Java RMI will use this property's value to generate remote references to the server.】

与免费的下载版本不同，正式版的Oracle在购买后，用户会得到一个产品服务码，凭此Oracle服务码，可以得到Oracle的在线升级等服务，Oracle的服务分为好多级，不同级别提供相对应的在线或是现场服务。

现在Oracle有两种授权方式，按CPU(Process)数和按用户数(NamedUser Plus)。前一种方式一般用于用户数不确定或者用户数量很大的情况，典型的如互联网环境，而后一种则通常被用于用户数确定或者较少的情况。

按CPU：License数=CPU数*系数。系数来自Oracle的一个参数表，如IBM Power6的处理器为1，AMD和Intel的处理器为0.5，详细情况见下：

则根据公式可以算出，一个SUN UltraSparc T1的4*8核处理器需要4*8*0.25=8个CPU licenses

按用户数：Oracle数据库按照用户数授权，是指最终端的连接到Oracle数据库的用户数。按照用户数来买的时候只能用于一个系统，不允许在多台机器上安装。每一个访问Oracle数据库的用户，无论是自然人还是设备，都算作一个用户 (Named User)。如果是B/S架构，那么是指连接到中间件上的用户数。

Named User Plus: is defined as anindividual authorized by you to use the programs which are installed on a singleserver or multiple servers, regardless of whether the individual is activelyusing the programs at any given time. A non human operated device will becounted.

按用户数购买则对应相应的产品有对应的License的最低购买量限制，如下：

当然用户应该根据自己的实际用户数订购，且不少于相应版本所要求的最低用户数。

一般情况下，1CPU的费用约等于50user的费用，所以如果用户数>CPU数*系数*50，则按CPU订购反而更为经济。

更换服务器，OracleLicense要重新购买吗？

如果用户是按照用户数购买的Oracle，更改硬件不需要重新购买License；

如果是按照CPU个数买，有相应的换算方法，具体请咨询Oracle公司。

这里是Oracle 11g企业版的销售价格：

每个License还有有效期的分类（不论是User License还是CPU License），分别为：1年、2年、3年、4年、5年、永久。当然价格也是依次增加。

当前Oracle 11G的User License无限使用期的价格为人民币3千5左右，按50个User License无限使用期的购买量则价格为17.5万;每个CPU License无限使用期的价格为17万9千，按IBM小机的系数计算，则购买价格为17万9千，和50个User License的价格相近。

关于服务价格：一般地，购买Oracle的License都包含首年的服务费，以后的费用按每年原价的22%计算。

更多的产品价格可以访问http://shop.oracle.com查看。

这里我们再介绍一下如何查看服务器上物理CPU总数以及核数：

a.如果已安装了数据库实例，那么直接查看V$license视图即可:

SQL> select cpu_count_current,CPU_CORE_COUNT_CURRENT,CPU_SOCKET_COUNT_CURRENT from v$license;

CPU_COUNT_CURRENT CPU_CORE_COUNT_CURRENT CPU_SOCKET_COUNT_CURRENT
----------------- ---------------------- ------------------------
                2                      2                        1

b. 如果服务器上尚没有部署实例则不能使用v$license视图，那么可以通过OS 命令来获取必要的信息。

在x86 Linux服务器上：

列出当前使用的物理CPU的个数：

grep core\ id /proc/cpuinfo | grep -c \ 0$ | grep ^0$ >> /dev/null && grep -c processor /proc/cpuinfo || \
grep core\ id /proc/cpuinfo | grep -c \ 0$

列出单个物理CPU的核数

grep "cpu cores" /proc/cpuinfo |uniq

当然随着cpu计算能力的提高，cpu个数有可能并不需要太多。oracle的收费模式肯定会变化。

转载自：http://blog.chinaunix.net/uid-20682147-id-76384.html

性能测试是 Web 应用系统的一项重要质量保证措施。在现实中，很多 Web 性能测试项目由于性能测试需求定义不合理或不明确，导致性能测试项目不能达到预期目标或进度超期。本文针对 Web 应用系统的技术架构和系统使用特点，探讨如何有效实施性能测试过程，并重点介绍如何分析获得合理的性能测试需求，最终对 Web 应用系统性能进行科学、准确的评估。

1 引言

基于Web服务器的应用系统由于提供浏览器界面而无须安装，大大降低了系统部署和升级成本，得以普遍应用。目前，很多企业的核心业务系统均是Web应用，但当Web应用的数据量和访问用户量日益增加，系统不得不面临性能和可靠性方面的挑战。因此，无论是Web应用系统的开发商或最终用户，都要求在上线前对系统进行性能，科学评价系统的性能，从而降低系统上线后的性能风险。

在很多性能测试项目中，由于不能合理定义系统的性能测试需求，不能建立和真实环境相符的负载模型，不能科学分析性能测试结果，导致性能测试项目持续时间很长或不能真正评价系统性能并提出性能改进措施。

本文在总结许多Web应用系统性能测试实践经验和教训的基础上，从与性能测试工具无关的角度介绍Web应用系统性能测试的方法和实施过程，以及如何定义合理的性能测试需求。

1.1 术语定义

性能测试：通过模拟大量浏览器客户端同时访问Web服务器，获得系统的性能数据。

虚拟用户：模拟浏览器向Web服务器发送请求并接收响应的一个进程或线程。

响应时间：浏览器向Web服务器提交一个请求到收到响应之间的间隔时间。

思考时间：浏览器在收到响应后到提交下一个请求之间的间隔时间。

请求成功率：Web服务器正确处理的请求数量和接收到的请求数量的比。

吞吐量：单位时间内Web服务器成功处理的HTTP页面或HTTP请求数量。

在线用户：用户通过浏览器访问登录Web应用系统后，并不退出该应用系统。通常一个Web应用服务器的在线用户对应Web应用服务器的一个Session。

并发用户数：Web服务器在一段时间内为处理浏览器请求而建立的HTTP连接数或生成的处理线程数。当所有在线用户发送HTTP请求的思考时间为零时，Web服务器的并发用户数等于在线用户数。

1.2 Web应用系统技术架构

Web应用系统的前端为浏览器，后台为Web服务器（如Apache，Microsoft Internet Information Server），浏览器和Web服务器之间的交互基于HTTP协议。HTTP协议本身是无连接的，Web服务器通过Session机制来建立一个浏览器所发出的先后连接之间的关联。通过实验证明，当浏览器客户端在首次访问Web服务器后，如果该浏览器客户端不发送后续请求，服务器维持该浏览器客户端的Session变量所消耗的系统资源非常小。

2 Web应用系统性能测试过程

标准的Web应用系统性能测试过程包括确定性能测试需求，开发性能测试脚本，定义性能测试负载模型，执行性能测试和形成性能测试报告。本章将分别介绍上述过程，并通过举例说明如何完成每一环节。

2.1 确定性能测试需求

科学定义Web应用系统性能测试需求对一个成功的性能测试非常重要。通常，Web应用系统的性能测试需求有如下两种描述方法。

2.1.1 基于在线用户的性能测试需求

该需求描述方法主要基于Web应用系统的在线用户和响应时间来度量系统性能。当Web应用系统在上线后所支持的在线用户数以及操作习惯（包括操作和请求之间的延迟）很容易获得，如企业的内部应用系统， 通常采用基于在线用户的方式来描述性能测试需求。以提供网上购物的Web应用系统为例，基于在线用户的性能测试需求可描述为：10个在线用户按正常操作速度访问网上购物系统的下定单功能，下定单交易的成功率是100%，而且90%的下定单请求响应时间不大于8秒；当90%的请求响应时间不大于用户的最大容忍时间20秒时，系统能支持50个在线用户。

2.1.2 基于吞吐量的性能测试需求

该需求描述方法主要基于Web应用系统的吞吐量和响应时间来度量系统性能。当Web应用在上线后所支持的在线用户无法确定，如基于Internet的网上购物系统，可通过每天下定单的业务量直接计算其吞吐量，从而采取基于吞吐量的方式来描述性能测试需求。以网上购物系统为例，基于吞吐量的性能测试需求可描述为：网上购物系统在每分钟内需处理10笔下定单操作，交易成功率为100%，而且90%的请求响应时间不大于8秒。

2.2 开发性能测试脚本

在确定Web应用系统性能测试需求后，就要根据性能测试需求中确定的功能开发性能测试脚本。比如，针对前面定义的网上购物系统的性能测试需求，将开发下定单功能的性能测试脚本。

性能测试脚本是描述单个浏览器向Web服务器发送的HTTP请求序列。每个性能测试工具（如IBM Rational Performance Tester， LoadRunner）所提供的测试脚本语法是不同的。测试人员利用性能测试工具可从头手工编写测试脚本，也可以通过录制浏览器和Web服务器之间的网络通信数据而自动形成测试脚本。

任何性能测试工具都不能保证录制形成的性能测试脚本的正确性，测试人员应通过在单用户下运行性能测试脚本对其正确性进行验证。测试脚本不正确的一个重要原因就是脚本的数据关联不正确，也就是并没完全建立一个测试请求和前面的响应内容之间的关联。测试脚本HTTP请求和响应之间的数据关联是否正确的一个重要标准是单用户运行脚本，脚本能完成期望的功能。

在完成性能测试脚本的数据关联后，需要对脚本进行参数化，也就是把脚本中的某些请求数据替换成变量，变量的值来于一个独立的数据文件，从而保证在多虚拟用户运行脚本的情况下，每个虚拟用户所提交的数据是不同的。

此外，为了测试Web应用的可靠性，还需要对请求所收到的响应进行验证（比如验证响应的HTTP返回码或验证响应的内容），便于性能测试完成后统计请求成功率。

2.3 建立性能测试负载模型

性能测试负载模型定义了测试工具如何向Web应用系统提交请求，包括向Web应用系统发送请求的虚拟用户数，每个虚拟用户发送请求的速度和频率。针对前面介绍的网上购物系统的性能测试需求，在性能测试工具中定义的性能测试负载模型应包括如下信息：

虚拟用户数：性能测试不仅仅是执行一次，而且每次执行时虚拟用户数也不固定，因此在性能测试负载模型中定义的虚拟用户数将在测试执行时进行设置。

虚拟用户发送请求的思考时间和迭代次数：虚拟用户发送请求的思考时间长短是决定Web应用系统负载量的重要因素之一，而迭代次数将决定性能测试的执行持续时间。对基于在线用户的性能测试需求，将基于录制脚本时记录的思考时间，而且由于现实中不同用户访问系统的思考时间不同，可把思考时间设置为在一定范围内的随机值。对于基于吞吐量的性能测试需求，将把思考时间设置为零，此时Web应用系统的在线用户数量将等于并发用户数。同时，为了避免性能测试压力的随机性，将增加请求的迭代次数来增加测试执行持续时间，从而获得系统在稳定压力下的性能数据。

虚拟用户启动模式：在现实中，Web应用系统的用户不太可能同时做相同的操作，因此为了让Web应用系统所承担的压力随时间均匀分布，建议虚拟用户依次启动，同时也避免大量用户同时登录造成系统阻塞。以10个虚拟用户模拟下定单为例，可设置每个虚拟用户间隔30秒启动，这样10个虚拟用户可在5分钟后完成启动，并保证10个虚拟用户不会在同一时刻下定单，从而更符合实际情况。

2.4 执行性能测试

执行性能测试是指通过多次运行性能测试负载模型，获得系统的性能数据。在执行过程中，需利用测试工具、操作系统、系统软件（如Web Server或DB Server）提供的资源监控手段对资源进行监控和分析，帮助发现资源瓶颈，并在系统层面进行优化。同时，还需对应用进行性能分析，帮助定位应用代码中的性能问题，切实解决系统的性能问题。

2.5 形成性能测试报告

性能测试项目的最后阶段就是向相关人员提交性能测试报告，汇报性能测试结果。在向相关人员汇报性能测试结果时，并不是性能测试报告越丰富、性能数据越多越好。好的性能测试报告是能准确、简单地传递性能测试结论，而不需太多的技术细节。

针对基于在线用户数的性能测试需求，可通过下图总结性能测试结论。其中横轴是在线用户数，纵轴是响应时间，如40在线用户访问网上购物系统时，90%的下定单请求响应时间不超过10秒。

针对基于吞吐量的性能测试需求，可通过下图的曲线来描述性能测试结果。以网上购物系统为例，下图描述下定单的并发用户、下定单响应时间以及吞吐量（服务器每秒处理定单笔数）之间的关系，从而快速判断系统是否能满足性能测试需求。从下图中可看出，并发用户增加，请求的响应时间也增加。服务器的吞吐量是先随并发用户数增加而增加，当吞吐量到达一定峰值后，再增加并发用户数，吞吐量会减少。原因在于当并发用户数少时，向Web服务器提交的请求量不大，服务器处理能力还有富余，所以吞吐量逐步增大；但当并发用户数超过某一值时，由于向服务器提交的请求太多，造成服务器阻塞，反而导致吞吐量减少。

3 如何获取合理的性能测试需求

前一章介绍了Web应用系统的性能测试过程，确定性能测试需求是整个性能测试的起点和成功的重要因素。性能测试需求定义得过高，虽然确保系统上线后能满足性能需求，但可能会造成硬件资源的浪费；性能测试需求定义得过低，系统上线后可能会出现性能问题。如何通过分析系统上线后可能的用户访问行为，来获得合理的性能测试需求指标呢？

假设现有一个基于Web的办公自动化系统（简称OA系统），该系统提供公文收发和查询功能。在部署该系统前，将对该系统进行性能测试。下面将详细介绍如何分析该OA系统的使用情况，定义合理的性能测试需求。

3.1 如何获得OA系统的在线用户数量

在线用户数量是指在特定时间区间内，有多少用户访问Web应用系统（对应到Web服务器的Session数），根据系统可能访问用户数以及每个用户访问系统的时间长短来确定。

对于将要部署的OA系统，通过分析获得该系统有8000个注册用户，基本上所有的用户每天（8小时工作时间）都会访问OA系统，平均在线时间（从登录OA系统到退出OA系统之间的时间间隔，也可以是多次在线时间的合计）为12分钟，那么该OA系统的平均在线数（也就是Web应用Session变量数）为200个（8000 * 0.2 / 8），假设峰值在线用户数是平均在线用户数的3倍（该倍数可根据实际情况调整），则性能测试需求的在线用户数为600。

3.2 如何确定OA系统的性能测试用例

由于时间和资源限制，不可能对Web应用系统的所有功能进行性能测试，而是从业务的角度（如某一功能操作的用户多）和技术的角度（如某一功能虽然访问用户不多，但内部处理逻辑复杂或处理数据量大）来选择Web应用系统的特定功能作为性能测试用例。

以OA系统为例，由于所有用户都经常公文查询功能，因此确定的性能测试用例为公文查询。

3.3 如何确定OA系统的响应时间

响应时间的快慢直接影响了系统使用用户的满意度，采用平均响应时间来描述系统系统性能测试需求是不科学的，因为无法直接和客户的满意度挂钩。而且，在做性能测试，如果某一请求的响应时间过长或过短，将导致平均响应时间和实际情况偏离。

以OA系统为例，定义的响应时间需求为：90%（该百分比和要求的系统用户满意度相关）的查询请求响应时间不超过8秒（该时间可根据实际情况确定）。

3.4 如何确定OA系统的交易吞吐量

单位时间内Web应用系统需处理多少笔特定的交易可通过统计获得。以OA系统为例，假设每个用户每天（一天按8小时计算）平均会查询公文4次，那OA应用的Web服务器平均每分钟要能处理8000 * 4 / ( 60 * 8 ) = 66.67笔查询公文交易，考虑到峰值因素，要求每分钟能处理66.7 * 3=200笔查询公文交易。

3.5 OA系统性能测试需求描述

通过前面的分析，能明确定义合理的性能测试需求。OA系统性能测试需求定义如下：

基于在线用户数的性能测试需求：600个在线用户按正常操作速度访问OA系统的查询公文功能，所有查询请求的成功率是100%，而且90%的查询请求响应时间不大于8秒。

基于吞吐量的性能测试需求：OA系统在每分钟内需处理200笔查询公文操作，交易成功率为100%，而且90%的请求响应时间不大于8秒。

4 总结

Web应用性能测试项目成功的关键不在于性能测试工具，而在于有效的性能测试分析方法和实践。只有切实掌握性能测试需求分析方法，性能测试实践经验，才能保证一个Web应用性能测试的成功。

svn提交遇到恶心的问题，可能是因为上次cleanup中断后，进入死循环了。

错误如下：

解决方法：清空svn的队列

1.下载sqlite3.exe   

2.找到你项目的.svn文件，查看是否存在wc.db

3.将sqlite3.exe放到.svn的同级目录

4.启动cmd执行sqlite3 .svn/wc.db "select * from work_queue"

5.看到很多记录，下一步执行delete from work_queue

6.ok了，现在在到项目里面，执行cleanup，完全没问题了，图标状态也已经恢复了。

var eventUtility = {
	addEvent : function(el, type, fn) {
		if(typeof addEventListener !== "undefined") {
			el.addEventListener(type, fn, false);
		} else if(typeof attachEvent !== "undefined") {
			el.attachEvent("on" + type, fn);
		} else {
			el["on" + type] = fn;
		}
	},

	removeEvent : function(el, type, fn) {
		if(typeof removeEventListener !== "undefined") {
			el.removeEventListener(type, fn, false);
		} else if(typeof detachEvent !== "undefined") {
			el.detachEvent("on" + type, fn);
		} else {
			el["on" + type] = null;
		}
	},

	getTarget : function(event) {
		if(typeof event.target !== "undefined") {
			return event.target;
		} else {
			return event.srcElement;
		}
	},

	preventDefault : function(event) {
		if(typeof event.preventDefault !== "undefined") {
			event.preventDefault();
		} else {
			event.returnValue = false;
		}
	}
};

使用方法示例：

var eventHandler = function(evt) {
	var target = eventUtility.getTarget(evt),
		tagName = target.tagName;

	if(evt.type === "click") {
		if(tagName === "A" || tagName === "BUTTON") {
			alert("You clicked on an A element, and the innerHTML is " + target.innerHTML + "!");
			eventUtility.preventDefault(evt);
		}
	} else if(evt.type === "mouseover" && tagName === "A") {
		alert("mouseovered " + target.innerHTML);
	}
	
};

eventUtility.addEvent(document, "click", eventHandler);
eventUtility.addEvent(document, "mouseover", eventHandler);

eventUtility.removeEvent(document, "mouseover", eventHandler);

// 方法一：函数声明
function foo() {}

// 方法二：函数表达式
var foo = function () {};

另外还有一种自执行函数表达式，主要用于创建一个新的作用域，在此作用域内声明的变量不会和其它作用域内的变量冲突或混淆，大多是以匿名函数方式存在，且立即自动执行：

(function () {
    // var x = ...
})();

此种自执行函数表达式归类于以上两种方法的第二种，也算是函数表达式。

方法一和方法二都创建了一个函数，且命名为 foo，但是二者还是有区别的。JavaScript 解释器中存在一种变量声明被提升（hoisting）的机制，也就是说变量（函数）的声明会被提升到作用域的最前面，即使写代码的时候是写在最后面，也还是会被提升至最前面。

例如以下代码段：

alert(foo); // function foo() {}
alert(bar); // undefined
function foo() {}
var bar = function bar_fn() {};
alert(foo); // function foo() {}
alert(bar); // function bar_fn() {}

输出结果分别是function foo() {}、undefined、function foo() {}和function bar_fn() {}。

可以看到 foo 的声明是写在 alert 之后，仍然可以被正确调用，因为 JavaScript 解释器会将其提升到 alert 前面，而以函数表达式创建的函数 bar 则不享受此待遇。

那么bar 究竟有没有被提升呢，其实用 var 声明的变量都会被提升，只不过是被先赋值为 undefined 罢了，所以第二个 alert 弹出了 undefined。

所以，JavaScript 引擎执行以上代码的顺序可能是这样的：

1. 创建变量 foo 和 bar，并将它们都赋值为 undefined。
2. 创建函数 foo 的函数体，并将其赋值给变量 foo。
3. 执行前面的两个 alert。
4. 创建函数 bar_fn，并将其赋值给 bar。
5. 执行后面的两个 alert。

注：

严格地说，再 JavaScript 中创建函数的话，还有另外一种方法，称为“函数构造法”：

var foo = Function('alert("hi!");');
var foo = new Function('alert("hi!");'); // 等同于上面一行

此方法以一个字符串作为参数形成函数体。但是用这种方法，执行效率方面会打折扣，且似乎无法传递参数，所以少用为妙。

   2、项目沟通
      1.重要事项亲历亲为。
      2.每周的项目周报，除了知悉公司外，同步知悉客户。
      3.需求的分析及客户确认用原型图。需求的确认启动开发，必须是业务部、信息化部、公司三方达成一致。
      4.技术实现上会就会，不会就不会，和时间的多少没有线性关系。
      5.控制好工作节奏，多和领导沟通，自己的经历正是人家过去经历的重现。
      6.沟通项目存在的问题时尊重客观事实和软件开发规律，做不完的跟客户说明原因，该拒绝的果断。
      7.上线前的客户运作，除了项目层面的客户沟通，也请领导高层向客户高层沟通。
      8.强调需求变更会影响项目计划的执行，变更需要付出代价（优先策略：时间调整、功能调整、人力调整）。
      9.遵循‘做得少但质量好，忌讳做的多却质量差’的原则。
      10.项目风险且一时对得不到公司资源倾斜时，也可借助客户的力量（下下策）。
      11.客户的跟催，多耐心少急躁，多自省少借口，多客观少主观。
      12.交付时间的答复，不能当下给出的待评估后再给。

   3、项目流程：
      需求频繁且变更较多时，建议0.5周～1周一轮版本。每次汇报后产生的新需求、遗留需求、待开发的功能：
      1.整理《项目跟踪表》，含：新需求、遗留问题、关联影响（指导测试做关联模块的验证）
      2.测试人员将已明确的开发任务登记到BUG管理系统
      3.需求人员与开发、测试人员评审需求
      4.负责人牵头需求、开发、测试人员确定开发、测试、发布时间计划。
      5.与客户反馈交付时间点（对于小需求的交付时间可以直接答复、大需求要内部讨论再答复）。
      6.项目进度跟踪，以天为单位，测试人员更新《项目跟踪表》。
      7.需求验证介入
        1）开发提交代码后，需求人员、测试人员分别开展系统测试（业务角度，关注界面交互、主干流程、数据展现）、业务测试（系统角度，关注功能操作及边界、业务流程输入输出）。
        2）需求人员发现的问题，属于开发BUG登记到BUG管理系统、需求BUG与开发人员、甚至客户澄清，如不影响版本发布时间直接加入在研版本、如影响则提交变更请求，与客户沟通得到变更认可或与开发沟通得到变更认可。
      9.升级前，针对环境数据的准备，编写《升级注意事项（含数据清理、数据准备等）》给测试人员交代。
      10.升级后，需求人员在演示环境走业务测试（建议离正式演示前2天完成升级验证，提前1天环境冻结。）
      11.上线前，与客户沟通准备事项（含压力测试、工程部署、资料交付、培训计划、试运行计划等）

   4、客户汇报：
      1.小型汇报，前一天，系统冻结，不再做升级，只做业务验证、回归。
      2.大型汇报，前三天，系统冻结，不再做升级，只做业务验证、回归。
      3.汇报前，拿用户的笔记本做预演，防止操作系统、浏览器兼容问题。
      4.汇报思路：
        1）以一个业务主线，给客户讲故事,结合不同客户关注的角度出发，让平台能融入不同客户的日常工作。
        2）信息化前是什么样，信息化后是什么样（提高日常办公的效率、平台统计的数据提升客户的业绩等）
      5.项目初期注意界面UI友好，中期注意数据的规范及业务流程正确，后期注重统计数据的真实、准确。
      6.版本的技术问题、项目进度的问题、用户需求的问题、沟通协调的问题，实事求是汇报客户。
      7.汇报前与客户业务接口人沟通汇报内容、汇报方式，掌握领导听取汇报时关注的点。
      8.汇报前，关注业务部门的需求、信息化部门的建议、更要关注客户领导的关心点。

   5、业务关注：
      1.关注平台的数据输入、处理、输出数据的完整性、准确性、关联性。
      2.抓住平台的建设理念，所有业务模块围绕该理念开展需求分析、设计。
      3.降低线上复杂的业务操作流程（更多考虑结果数据的录入、留痕，流程多了很难同时在线协同办公）。
      4.技术实现的同时要考虑业务机制的配套。
      5.考虑现实性[在现有业务规章制度的环境下运行]、前瞻性[业务层面的发展方向]、可行性[技术是否支持]。
      6.关注和周边平台的数据结构一致和标准
      7.<待补充>

   6、时间评估：
      1.每天列出当天要做的工作、每天下班前回顾当天工作，每周列出本周工作成果、下周工作计划。
      2.任务时间评估 = [成员评估 结合 自评估] + 开发冗余（根据平台特性、开发人员经验及态度判断） + 测试冗余（根据平台特性、测试人员经验及态度判断） + 需求冗余（根据平台特性、需求人员经验及态度判断）+ 其他冗余（如请假、生病、开会等非项目因素）

   7、一些管理笔记：
      1.任务精准、给予空间
      2.狠抓住干、适当放权
      3.敢于承担、顶住冲击
      4.讲究诚信、承诺到位
      5.规则考核、理解包容
      6.用人不疑、疑人不用
      7.功劳大家、黑锅自己

转自：http://blog.csdn.net/jinhill/article/details/3961881

综上，URL还是不适合太长，不是不得已，尽量不要通过GET方式提交大量参数，可以考虑用POST方式（大约在2M左右，应该是和服务器及设定有关）。另外这么长的URL在访问和收藏（有文章提到有些浏览器在收藏超长地址时也是会出现问题）时也是相当不友好的。当然，之前数据库字段设置时还是作为255bytes处理，现在可能要考虑扩充一下了。

参考：

1. What is the maximum length of a URL?
2. What is the limit on QueryString / GET / URL parameters?

1. RPC/编码
2. RPC/文字
3. 文档/编码
4. 文档/文字

除了这些样式之外，还有一种样式也很常见，它称为文档/文字包装的样式，算上这一种，在创建 WSDL 文件时您就有了五种绑定样式可以从中选择。您应该选择哪一种呢？

对于本文的讨论，让我们从 清单1中的 Java 方法开始，并且对其应用 JAX-RPC Java-to-WSDL 规则

public void myMethod(int x);

RPC/编码

采用 清单1中的方法并且使用您喜欢的 Java-to-WSDL 工具来运行它，指定您想让它生成 RPC/编码的 WSDL。您最后应该得到如 清单2所示的 WSDL 片断。

<message name="myMethodRequest">
    <part name="x" type="xsd:int"/>
</message>
<message name="empty"/>
<portType name="PT">
    <operation name="myMethod">
        <input message="myMethodRequest"/>
        <output message="empty"/>
    </operation>
</portType>
<binding .../>  
<!-- I won't bother with the details, just assume it's RPC/encoded. -->

现在用“5”作为参数 x 的值来调用此方法。我们将发送一个与 清单3类似的 SOAP 消息。

<soap:envelope>
    <soap:body>
        <myMethod>
            <x xsi:type="xsd:int">5</x>
        </myMethod>
    </soap:body>
</soap:envelope>

对于这个 RPC/编码的示例中的 WSDL 和 SOAP 消息，有许多需要注意的事项：

优点

• WSDL 基本达到了尽可能地简单易懂的要求。
• 操作名出现在消息中，这样接收者就可以很轻松地把消息发送到方法的实现。

缺点

• 类型编码信息（比如 xsi:type="xsd:int" ）通常就是降低吞吐量性能的开销。
• 您不能简单地检验此消息的有效性，因为只有 <x xsi:type="xsd:int">5</x> 行包含在 Schema 中定义的内容；其余的 soap:body 内容都来自 WSDL 定义。

有没有一种方法能够保留这些优点而消除其中的缺点呢？或许有。让我们来看一看 RPC/文字的样式。

回页首

RPC/文字

用于我们的方法的 RPC/文字的 WSDL 看起来与 RPC/编码的 WSDL 几乎一样（请参见 清单4）。只是绑定的用法由 编码改为 文字。仅此而已。

<message name="myMethodRequest">
    <part name="x" type="xsd:int"/>
</message>
<message name="empty"/>
<portType name="PT">
    <operation name="myMethod">
        <input message="myMethodRequest"/>
        <output message="empty"/>
    </operation>
</portType>
<binding .../>  
<!-- I won't bother with the details, just assume it's RPC/
        literal. -->
      

RPC/文字的 SOAP 消息又是怎样的呢（请参见 清单 5）？这里的更改要多一点。去掉了类型编码。

<soap:envelope>
    <soap:body>
        <myMethod>
            <x>5</x>
        </myMethod>
    </soap:body>
</soap:envelope>

下面是这种方法的优点和缺点：

优点

• WSDL 还是基本达到了尽可能地简单易懂的要求。
• 操作名仍然出现在消息中。
• 去掉了类型编码。

缺点

• 您仍然不能简单地检验此消息的有效性，因为只有 <x xsi:type="xsd:int">5</x> 行包含在 Schema 中定义的内容；其余的 soap:body 内容都来自 WSDL 定义。

文档样式如何呢？它们能够帮助克服这些困难吗？

回页首

文档

我不知道有谁懂得这种方法的真正含义。我也不知道这种方法的任何实现。它将可能从 WSDL 的后续版本中消失。所以我们还是讨论别的吧。

回页首

文档

文档/文字的 WSDL 对 RPC/文字的 WSDL 作了一些更改。它们之间的不同之处显示在 清单6中。

        <types>
    <schema>
        <element name="xElement" type="xsd:int"/>
    </schema>
</types>
<message name="myMethodRequest">
    <part name="x" 
        element="xElement"/>
</message>
<message name="empty"/>
<portType name="PT">
    <operation name="myMethod">
        <input message="myMethodRequest"/>
        <output message="empty"/>
    </operation>
</portType>
<binding .../>  
<!-- I won't bother with the details, just assume it's 
        document/literal. -->
      

而现在的 SOAP 应该如 清单 7所示：

<soap:envelope>
    <soap:body>
        <xElement>5</xElement>
    </soap:body>
</soap:envelope>

下面是这种方法的优点和缺点：

优点

• 没有编码信息
• 您可以在最后用任何 XML 检验器检验此消息的有效性。 soap:body （ <xElement>5</xElement> ）中每项内容都定义在 Schema 中。

缺点

• WSDL 变得有些复杂。不过，这是一个非常小的缺点，因为 WSDL 并没有打算由人来读取。
• SOAP 消息中缺少操作名。而如果没有操作名，发送就可能比较困难，并且有时变得不可能。

文档/文字的样式看起来似乎只是重新安排了 RPC/文字的模型的优点和缺点。您可以检验消息的有效性，但是您失去了操作名。有没有一种方法可以改进这一点呢？有的。它就是文档/文字包装的样式。

回页首

文档

在我说明文档/文字包装的样式的含义之前，让我给您展示 清单 8和 清单9中的 WSDL 和 SOAP 消息。

<types>
    <schema>
        
        <element name="myMethod"/>
            <complexType>
                <sequence>
                    <element name="x" type="xsd:int"/>
                </sequence>
            </complexType>
        </element>
    </schema>
</types>
<message name="myMethodRequest">
    <part name="
        parameters" element="
        myMethod"/>
</message>
<message name="empty"/>
<portType name="PT">
    <operation name="myMethod">
        <input message="myMethodRequest"/>
        <output message="empty"/>
    </operation>
</portType>
<binding .../>  
<!-- I won't bother with the details, just assume it's document/literal. -->
      

WSDL Schema 现在把参数放在包装中（请参见 清单9）。

<soap:envelope>
    <soap:body>
        <myMethod>
            <x>5</x>
        </myMethod>
    </soap:body>
</soap:envelope>

注意到此 SOAP 消息看起来非常类似于 RPC/文字的 SOAP 消息。您可能会说，它看起来与 RPC/文字的 SOAP 消息是完全一样的，不过，这两种消息之间存在着微妙的区别。在 RPC/文字的 SOAP 消息中， <soap:body> 的 <myMethod> 子句是操作的名称。在文档/文字包装的 SOAP 消息中， <myMethod> 子句是单个输入消息的组成部分引用的元素的名称。因此，包装的样式具有这样的一个特征，输入元素的名称与操作的名称是相同的。此样式是把操作名放入 SOAP 消息的一种巧妙方式。

文档/文字包装的样式的特征有：

• 输入消息只有一个组成部分。
• 该部分就是一个元素。
• 该元素有与操作相同的名称。
• 该元素的复杂类型没有属性。

下面是这种方法的优点和缺点：

优点

• 没有编码信息。
• 出现在 soap:body 中的每项内容都是由 Schema 定义的，所以您现在可以很容易地检验此消息的有效性。
• 方法名又出现在 SOAP 消息中。

缺点

• WSDL 甚至更复杂，但是这仍然是一个非常小的缺点。

如您所见，文档/文字包装的样式还是有一些缺点，不过与优点比起来，它们都显得无足轻重。

文档/文字的样式在哪里定义

这种包装的样式来源于 Microsoft。没有定义这种样式的规范；所以虽然这种样式是一个好的东西，但不幸的是，为了与 Microsoft 和其他公司的实现进行互操作，现在惟一的选择就是根据 Microsoft WSDL 的输出来猜测它是如何工作的。文档/文字包装的样式也实现在 IBM WebSphere SDK for Web Services 中（请参见 参考资料）。在这个示例中，样式是相当明显的；但是也存在个别情况，在这些情况中，由于缺少定义而导致需要操作的适当事项不够特别清晰。我们希望看到的最理想的情况就是将来能有像 Web 服务互操作组织（Web Services Interoperability Organization）这样的独立团体来帮助对此进行稳定化和标准化。

回页首

为什么不始终采用文档/文字包装的样式

至此，本文已经给了您这样的一个印象，文档/文字包装的样式是最好的方法。而实际的情况往往确实如此。不过，仍然存在着一些情况，在这些情况下，您最好是换一种别的样式。

采用文档/文字非包装的样式的理由

如果您已经重载了操作，就不能采用文档/文字包装的样式。

想象一下，除了我们一直在使用的方法之外，还有另一种方法，请参见 清单10。

public void myMethod(int x);
        public void myMethod(int x, String y);
      

WSDL 允许重载的操作。但是当您添加包装的样式到 WSDL 时，需要元素有与操作相同的名称，并且在 XML 中不能有两个名称相同的元素。所以您必须采用文档/文字非包装的样式或某种 RPC 样式。

采用 RPC/文字的样式的理由

由于文档/文字非包装的样式没有提供操作名，所以在有些情况下，您将需要采用某种 RPC 样式。比如说 清单11中的一组方法。

public void myMethod(int x);
public void myMethod(int x, String y);
        public void someOtherMethod(int x);
      

现在假定您的服务器接收到文档/文字的 SOAP 消息（您可以回过头在 清单 7中看一看它）。服务器应该发送哪一种方法呢？所有您能确切知道的就是，它一定不是 myMethod(int x, String x) ，因为消息只有一个参数，而这种方法需要两个参数。它可能是其他两种方法中的一种。采用文档/文字的样式，您没有办法知道是哪一种方法。

假定服务器接收到一个 RPC/文字的消息（比如 清单5中的），而不是文档/文字的消息。对于这种消息，服务器很容易决定把它发送到哪一种方法。您知道操作名是 myMethod，并且也知道只有一个参数，所以它必定是 myMethod(int x) 。

采用

采用 RPC/编码的理由有很多。其中两个主要的原因是：

• 数据图形
• 多态性

设想您有一个二进制树，其中的节点定义在 清单12中。

<complexType name="Node">
    <sequence>
        <element name="name" type="xsd:string"/>
        <element name="left" type="Node" xsd:nillable="true"/>
        <element name="right" type="Node" xsd:nillable="true"/>
    </sequence>
</complexType>

根据这种节点定义，我们可以构造一个树形结构，它的根节点 A 通过它左边和右边的的链接可以指向节点 B（请参见 图1）。

发送数据图形的标准方式是使用 href 标记，它是 RPC/编码的样式（ 清单13）的一部分。

<A>
    <name>A</name>
    <left href="12345"/>
    <right href="12345"/>
</A>
<B id="12345">
    <name>B</name>
    <left xsi:nil="true"/>
    <right xsi:nil="true"/>
</B>

在任何文字的样式中，href 属性都是不可用的，这样图形链接就不再起作用了（ 清单14和 图2）。您仍然有一个根节点 A，它从左边指向一个节点 B，从右边指向另一个节点 B。这两个 B 节点是等同的，但它们不是相同的节点。是复制了数据而不是引用了两次数据。

<A>
    <name>A</name>
    <left>
        <name>B</name>
        <left xsi:nil="true"/>
        <right xsi:nil="true"/>
    </left>
    <right>
        <name>B</name>
        <left xsi:nil="true"/>
        <right xsi:nil="true"/>
    </right>
</A>

在文字样式中，您可以通过各种方法构造图形，但是却没有标准的方法；所以您做的任何事情很可能不能与网络中其他端点上的服务进行互操作。

看一看 清单15中使用多态性 Schema 的 WSDL。

<types>
  <schema>
    <complexType name="animal">
      <sequence>
        <element name="name" type="xsd:string"/>
      </sequence>
    </complexType>
    <complexType name="dog">
      <complexContent mixed="false">
        <extension base="animal">
          <sequence>
            <element name="breed" type="xsd:string"/>
          </sequence>
        </extension>
      </complexContent>
    </complexType>
  </schema>
</types>
<message name="in">
  <part name="trainee" type="animal"/>
</message>
<message name="empty"/>
<portType name="AnimalTrainer">
  <operation name="train">
    <input message="in"/>
    <output message="empty"/>
  </operation>
</portType>

当您把一个 dog 的实例传送给 train 操作时，所生成的 SOAP 消息必须包含类型编码信息，这样接收终端才能知道它所接收的是 animal 的哪一个扩展（请参见 清单16）。这种类型编码信息可用在 RPC/编码的样式中。

<soap:envelope>
  <soap:body>
    <train>
      <trainee xsi:type="Dog">
        <name>Bob</name>
        <breed>Bloodhound</breed>
      </trainee>
    </train>
  </soap:body>
</soap:envelope>

总结

有四种绑定样式（其实真正有五种，不过文档/编码的样式没有什么意义）。虽然每种样式都有自己的用武之地，但是在大多数情况下，最好的样式是文档/文字包装的样式。

解决办法：
      通过使用 ntfs-3g 来解决。
      打开ntfs-3g的下载点http://www.tuxera.com/community/ntfs-3g-download/ ，将最新稳定ntfs-3g-2011.1.13下载到linux，
执行以下命令安装：
      1) 编译安装 ntfs-3g：
# tar zxvf  ntfs-3g-2011.1.13.tgz
# cd ntfs-3g-2011.1.15
#./configure
#make
#make install
mount -t ntfs-3g  /dev/sdc1 /mnt/usb

完~