庄周梦蝶

生活、程序、未来
   :: 首页 ::  ::  :: 聚合  :: 管理

最近的工作(mina vs. yanf4j)

Posted on 2009-06-26 21:46 dennis 阅读(5644) 评论(4)  编辑  收藏
     最近工作上是在处理一个线程安全的问题,如何保证对某个资源的访问是独占的,不会有并发的隐患。在此过程中接了checkthread,一个线程安全的静态分析工具,通过annotation标记在编译期检查可能的并发隐患,提供了一个eclipse插件,有兴趣可以看看他的 example。这个东西有个最不好的地方就是要依赖他的自定义annotation,如果不介意的话还是不错的选择,一些常见的隐患都能够标示出来。
    另外就是去了解了下netty3,jboss的子项目,netty2和mina作者的另一个作品,关注它是因为在他的benchmark中,netty3的表现很优秀,可以看这篇报告《Performance comparision between java nio framework》。大概看了下他的设计思路,其实与mina并无多大区别,不过使用了一些有意思的trick,例如对于write的处理,一般的nio框架都是放入一个队列,然后注册写事件(队列为空的时候),等待写,写通常也是单线程去写。而netty3做了一个优化,发送消息时同样有一个队列,在放入队列后判断当前是否正在写循环中,如果正在写,那么就注册一个WriteTask唤醒selector等待写;如果没有,那么发送线程立即就去执行这个写操作,这里的一个好处是少了两个开销:注册事件等待触发以及线程切换。Selector.wakeup的操作是比较昂贵的,netty3也做了优化。更多东西等待探索。

   山寨nio框架yanf4j已经挺久没有做出任何改进,这次索性将很多过去考虑不成熟、实践中证明不必要的代码删除和简化,然后做了个与mina 2.0 -M5的性能对比,采用的netty3作者的benchmark源码,yanf4j的Echo Server如下:
Echo Server

   最后的分析报表,可以看到yanf4j的性能与mina2的性能相近,不过mina在内存使用上非常狠。此外,Xmemcached 1.1.3 将采用最新的yanf4j 0.7.0。

(横坐标是并发连接数,纵坐标是吞吐量,单位为M/s,测试JDK为1.6.4,具体硬件环境不再详细列出,与xmemcached的benchmark同)

四张图分别是在消息长度为64、256、1024、4096字节下的对比。










评论

# re: 最近的工作(mina vs. yanf4j)  回复  更多评论   

2009-07-15 14:28 by 虎.无名
从图上看,感觉yanf4j随着线程增大,性能下降很快呀。而不是像mina2一样,微微下降,基本保持平稳。会不会像apache一样,超过一定线程,导致崩溃了?

# re: 最近的工作(mina vs. yanf4j)  回复  更多评论   

2009-07-15 15:20 by dennis
@虎.无名
这张图其实已经过时啦,现在没有这个现象了,我啥时候更新下。

只有注册用户登录后才能发表评论。


网站导航: