终究还是郁闷着了,为了JTangMQ的性能。
都是因为MQ,这个令人又爱又恨的家伙。想起当初刚刚开始设计JTangMQ的豪言壮志,为MQ设计、coding的三百多个日夜历历在目,如今却坐在椅子上一声叹息。为何JTangMQ的性能还是那么不尽如人意?为什么呢? 最初的设计目标是“超过国产MQ,迈向SonicMQ”,而现在的产品同JBossMQ相比还有那么一点的差距。这个差距令人诧异的地方是发送者&接受者分别在10个以下的时候,比JBossMQ要优越许多,而当发送者&接收者分别多于100个的时候,测试数据表明速度比JBossMQ还要少上几十个。记得当初设计的时候,就是因为JBossMQ为每个连接创建一个读线程&一个写线程,随着连接数的上升,线程数便会成倍增长,线程的切换会导致过多的cpu开销的原因,才利用NIO来设计JTangMQ的通讯层,想籍此点来提高JTangMQ在多连接数的性能。而现在的测试结构与原来的设计恰恰相反,连接数少的时候性能反而好。难道是因为线程的切换开销反不及减少线程数导致的cpu开销?是不是服务器端的线程数不够多呢?线程数在什么数量上才会是最好的选择呢?
也许试验才是最好的方式,明天再试试吧。不管行不行,都得继续走下去。