Tomcat既支持阻塞式IO,也支持非阻塞式IO。
如果要使用NIO,需要修改server.xml的配置。
<Connector executor="tomcatThreadPool" port="8080" [color=red]protocol="org.apache.coyote.http11.Http11NioProtocol"[/color] connectionTimeout="20000"
redirectPort="8443" URIEncoding="UTF-8"/>
web服务器一般有两种处理http请求的机制,阻塞和非阻塞,阻塞式因为每一个连接都产生一个线程,当线程数达到一定数量的时候,CPU用于线程切换的时间会变多,整体的性能会下降,所以线程池的数量要控制在一定的数量内,这是就需要引入非阻塞的机制,就是把连接先缓冲在一个队列中,然后再分给后台的线程池中的空闲线程慢慢处理。
Comet属于长连接,所以对于web服务器的吞吐量要求要更高,也就是要具备处理大量http请求的能力,所以必须使用Http11NioProtocal来提高吞吐量。
至于把连接缓存在队列中,依然排队等待的问题,和阻塞式处理方式比,至少客户端不会收到500 connection refused,只是感觉响应慢一些,还有因为comet属于消息推送,一般客户端的http请求是异步的,比如通过ajax在后台发起http请求,所以对于这种情况,连接缓存在等待队列中也没有关系,因为是异步的,而且用户也看不到,所以对用户的使用也没有影响。
下面看一下这两种方式的区别:
1.Http11Protocal
使用阻塞IO,服务器端使用Socket类和ServerSocket类负责请求的接入
一个请求接入线程,专门负责请求的接入accept,接入后把socket扔给后面的线程池,线程池中有具体的处理线程,负责后续的处理,一个线程对应一个请求,直到请求处理完毕并返回response,这个线程数就是web服务器能承载的最大线程数,如果线程池中没有空闲线程,那么下一个请求就无法接入,如果ServerSocket的等待队列也满了的话,客户端就会收到500 connection refused。
2.Http11NioProtocal
使用非阻塞IO,服务器端使用SocketChannel类和ServerSocketChannel类负责请求的接入
这种方式也有一个请求接入线程,专门负责请求的接入accept,但是接入后不是直接扔给后面的处理线程池,而是又多了一个或两个中间线程,这个中间线程里面有一个队列,接入后直接把SocketChannel以及对应的Selector监听信息包装成一个事件对象扔到中间线程的队列中(如果有两个中间线程,那么平均使用这两个线程,这次是线程1,下次是线程2,在下次是线程1,以此类推,所以每个中间线程会处理多个连接),这个队列可以容纳足够多的事件对象,Selector相当于对socket状态进行监视的监听器。这个中间线程不断地对这个事件队列进行循环处理,当Selector中有需要处理的事件时(比如socket read就绪,socket write就绪),再把socket转给后面的处理线程池进行后续的处理。
前面提到的中间线程可以有一个或者两个,每个里面都有一个队列,所以可以容纳足够多的socket连接。这样即使后面的线程池中没有空闲线程,一样可以对请求进行接入,然后缓存在中间线程的队列中。这样就加大了web服务器的吞吐量。comet长连接很多时也可以应付得了。
这种方式不单单是对连接进行缓存,前面提到了中间线程对Selector中的事件进行监视,直到有事件到达时才把socket转给后台线程池进行处理,这样就减少了线程池中的处理线程的等待时间,此外,对每个SocketChannel都分配了readbuffer和writebuffer,这样可以减少实际的socket流的读写次数,以减少IO等待。
如果要使用NIO,需要修改server.xml的配置。
<Connector executor="tomcatThreadPool" port="8080" [color=red]protocol="org.apache.coyote.http11.Http11NioProtocol"[/color] connectionTimeout="20000"
redirectPort="8443" URIEncoding="UTF-8"/>
web服务器一般有两种处理http请求的机制,阻塞和非阻塞,阻塞式因为每一个连接都产生一个线程,当线程数达到一定数量的时候,CPU用于线程切换的时间会变多,整体的性能会下降,所以线程池的数量要控制在一定的数量内,这是就需要引入非阻塞的机制,就是把连接先缓冲在一个队列中,然后再分给后台的线程池中的空闲线程慢慢处理。
Comet属于长连接,所以对于web服务器的吞吐量要求要更高,也就是要具备处理大量http请求的能力,所以必须使用Http11NioProtocal来提高吞吐量。
至于把连接缓存在队列中,依然排队等待的问题,和阻塞式处理方式比,至少客户端不会收到500 connection refused,只是感觉响应慢一些,还有因为comet属于消息推送,一般客户端的http请求是异步的,比如通过ajax在后台发起http请求,所以对于这种情况,连接缓存在等待队列中也没有关系,因为是异步的,而且用户也看不到,所以对用户的使用也没有影响。
下面看一下这两种方式的区别:
1.Http11Protocal
使用阻塞IO,服务器端使用Socket类和ServerSocket类负责请求的接入
一个请求接入线程,专门负责请求的接入accept,接入后把socket扔给后面的线程池,线程池中有具体的处理线程,负责后续的处理,一个线程对应一个请求,直到请求处理完毕并返回response,这个线程数就是web服务器能承载的最大线程数,如果线程池中没有空闲线程,那么下一个请求就无法接入,如果ServerSocket的等待队列也满了的话,客户端就会收到500 connection refused。
2.Http11NioProtocal
使用非阻塞IO,服务器端使用SocketChannel类和ServerSocketChannel类负责请求的接入
这种方式也有一个请求接入线程,专门负责请求的接入accept,但是接入后不是直接扔给后面的处理线程池,而是又多了一个或两个中间线程,这个中间线程里面有一个队列,接入后直接把SocketChannel以及对应的Selector监听信息包装成一个事件对象扔到中间线程的队列中(如果有两个中间线程,那么平均使用这两个线程,这次是线程1,下次是线程2,在下次是线程1,以此类推,所以每个中间线程会处理多个连接),这个队列可以容纳足够多的事件对象,Selector相当于对socket状态进行监视的监听器。这个中间线程不断地对这个事件队列进行循环处理,当Selector中有需要处理的事件时(比如socket read就绪,socket write就绪),再把socket转给后面的处理线程池进行后续的处理。
前面提到的中间线程可以有一个或者两个,每个里面都有一个队列,所以可以容纳足够多的socket连接。这样即使后面的线程池中没有空闲线程,一样可以对请求进行接入,然后缓存在中间线程的队列中。这样就加大了web服务器的吞吐量。comet长连接很多时也可以应付得了。
这种方式不单单是对连接进行缓存,前面提到了中间线程对Selector中的事件进行监视,直到有事件到达时才把socket转给后台线程池进行处理,这样就减少了线程池中的处理线程的等待时间,此外,对每个SocketChannel都分配了readbuffer和writebuffer,这样可以减少实际的socket流的读写次数,以减少IO等待。