关于NIO一些优化
2015-06-17 14:38
197 查看
1. 使用NIO开发web服务,传输文件内容,可以使用FileChannel.transferTo(position,count,socketChannel)来提升性能:
经过测试,确实能提升10% - 30%的处理性能。
相关提示链接:(mina) http://414149609.iteye.com/blog/1186036
API文档介绍:
public abstract long transferTo(long position, long count, target) throws
将字节从此通道的文件传输到给定的可写入字节通道。
试图读取从此通道的文件中给定 position 处开始的 count 个字节,并将其写入目标通道。此方法的调用不一定传输所有请求的字节;是否传输取决于通道的性质和状态。如果此通道的文件从给定的 position 处开始所包含的字节数小于 count 个字节,或者如果目标通道是非阻塞的并且其输出缓冲区中的自由空间少于 count 个字节,则所传输的字节数要小于请求的字节数。
此方法不修改此通道的位置。如果给定的位置大于该文件的当前大小,则不传输任何字节。如果目标通道中有该位置,则从该位置开始写入各字节,然后将该位置增加写入的字节数。
与从此通道读取并将内容写入目标通道的简单循环语句相比,此方法可能高效得多。很多操作系统可将字节直接从文件系统缓存传输到目标通道,而无需实际复制各字节。
参数:position - 文件中的位置,从此位置开始传输;必须为非负数count - 要传输的最大字节数;必须为非负数target - 目标通道
返回:实际已传输的字节数,可能为零抛出:- 如果关于参数的前提不成立- 如果不允许从此通道进行读取操作- 如果目标通道不允许进行写入操作- 如果此通道或目标通道已关闭- 如果正在进行传输时另一个线程关闭了任一通道- 如果正在进行传输时另一个线程中断了当前线程,因此关闭了两个通道并将当前线程设置为中断- 如果发生其他 I/O 错误
2. NIO的输出缓存区可以设置的大一些:
.allocate(int capacity)
以前我们常用8192(8K),现在使用NIO,可以使用 16384(16K),经过测试也能提高一些性能。
相关文章:NIO trick and trap NIO的技巧与陷阱http://www.blogjava.net/cooperzh/archive/2011/12/20/366884.html
分析完mina2.0和grizzly2.0对Selector的管理后(http://www.blogjava.net/killme2008/default.html?page=17)我们可以得到几个启示:
1、在处理大量连接的情况下,多个Selector比单个Selector好
2、多个Selector的情况下,处理OP_READ和OP_WRITE的Selector要与处理OP_ACCEPT的Selector分离,也就是说处理接入应该要一个单独的Selector对象来处理,避免IO读写事件影响接入速度。
3、Selector的数目问题,mina默认是cpu+2,而grizzly总共就2个,我更倾向于mina的策略,但是我认为应该对cpu个数做一个判断,如果CPU个数超过8个,那么更多的Selector线程可能带来比较大的线程切换的开销,mina默认的策略并非合适,幸好可以设置这个数值。
2012-06-18
经过测试,确实能提升10% - 30%的处理性能。
相关提示链接:(mina) http://414149609.iteye.com/blog/1186036
API文档介绍:
public abstract long transferTo(long position, long count, target) throws
将字节从此通道的文件传输到给定的可写入字节通道。
试图读取从此通道的文件中给定 position 处开始的 count 个字节,并将其写入目标通道。此方法的调用不一定传输所有请求的字节;是否传输取决于通道的性质和状态。如果此通道的文件从给定的 position 处开始所包含的字节数小于 count 个字节,或者如果目标通道是非阻塞的并且其输出缓冲区中的自由空间少于 count 个字节,则所传输的字节数要小于请求的字节数。
此方法不修改此通道的位置。如果给定的位置大于该文件的当前大小,则不传输任何字节。如果目标通道中有该位置,则从该位置开始写入各字节,然后将该位置增加写入的字节数。
与从此通道读取并将内容写入目标通道的简单循环语句相比,此方法可能高效得多。很多操作系统可将字节直接从文件系统缓存传输到目标通道,而无需实际复制各字节。
参数:position - 文件中的位置,从此位置开始传输;必须为非负数count - 要传输的最大字节数;必须为非负数target - 目标通道
返回:实际已传输的字节数,可能为零抛出:- 如果关于参数的前提不成立- 如果不允许从此通道进行读取操作- 如果目标通道不允许进行写入操作- 如果此通道或目标通道已关闭- 如果正在进行传输时另一个线程关闭了任一通道- 如果正在进行传输时另一个线程中断了当前线程,因此关闭了两个通道并将当前线程设置为中断- 如果发生其他 I/O 错误
2. NIO的输出缓存区可以设置的大一些:
.allocate(int capacity)
以前我们常用8192(8K),现在使用NIO,可以使用 16384(16K),经过测试也能提高一些性能。
相关文章:NIO trick and trap NIO的技巧与陷阱http://www.blogjava.net/cooperzh/archive/2011/12/20/366884.html
分析完mina2.0和grizzly2.0对Selector的管理后(http://www.blogjava.net/killme2008/default.html?page=17)我们可以得到几个启示:
1、在处理大量连接的情况下,多个Selector比单个Selector好
2、多个Selector的情况下,处理OP_READ和OP_WRITE的Selector要与处理OP_ACCEPT的Selector分离,也就是说处理接入应该要一个单独的Selector对象来处理,避免IO读写事件影响接入速度。
3、Selector的数目问题,mina默认是cpu+2,而grizzly总共就2个,我更倾向于mina的策略,但是我认为应该对cpu个数做一个判断,如果CPU个数超过8个,那么更多的Selector线程可能带来比较大的线程切换的开销,mina默认的策略并非合适,幸好可以设置这个数值。
2012-06-18
相关文章推荐
- 重写ListView实现下拉刷新上拉加载
- UNDO表空间使用率过高
- TCP/IP Socket 编程读书笔记
- OCX中主Frame中处理view(备用)
- POJ 1019 Number Sequence 解读
- NIO[读]、[写]在同一线程(单线程)中执行,让CPU使用率最大化,提高处理效率
- 控制台版java 计算机 +=-/()
- iAPP(08)智能手机呼吸灯控制
- zabbix所有键值
- 素数
- Python程序员的进化过程
- GPS定位类型
- 关于动态规划问题
- QTP无法录制web应用解决方法
- libjpeg.h文件
- 将ant执行的日志输出到文本中
- 素数
- Java 解析 lnk 快捷方式文件的方法(转)
- 解码(ByteBuffer): CharsetDecoder.decode() 与 Charset.decode() 的不同
- 《The Design and evolution of C++》读书笔记1