Terracotta性能问题

12-03-14 MichelleAnn
                   

问大家一个关于Terracotta实现分布式计算的问题,因为本人的基础不算很扎实,所以遇见这个问题不知道从哪里入手。

场景是这样的:我们现在的应用就是使用多线程技术实现多任务分布式计算,通过Terracotta DSO特性,来实现集群。在我们的项目中会涉及到Buyside 和 SellSide。Buysides会发大量的信息(订单)到我们的应用,SellSide会发处理结果到我们的应用 我们的应用就类似于一个转换器。我们的应用是用一个LinkedBlockingQueue当做接受任务的容器,然后再由处理程序去处理LBQ里面的任务如果结合TC 把LBQ作为DSO ROOT 那么把我们应用部署到到多台APP SERVER(TC CLIENT)后处理程序就会增多,按照原理,处理速度应该会增快。但事实上,经过我们测试后,发现性能并没有多大的提高,是不是有些地方我忽视了,或者说terracotta不适合我们的这种业务场景?

                   

1
banq
2012-03-14 10:04

2012年03月14日 09:41 "@MichelleAnn"的内容
那么把我们应用部署到到多台APP SERVER(TC CLIENT)后处理程序就会增多,按照原理,处理速度应该会增快。但事实上,经过我们测试后,发现性能并没有多大的提高 ...

这里有几个概念需要搞清楚:吞吐量和延迟,如果部署到多台APP,按道理,是吞吐量增长,就象原来小港口现在变成大港口,货物吞吐量上去了,但是每个货物的装卸速度和兵马俑无关,也就是你所说的性能。

你所说的性能是每个页面的加载速度或每个交易的处理时间。

以上指标需要定性,可参考jivejdon的Jmeter测试结果,其中averge min max是你要的性能,而througout是吞吐量,和分布式系统有关,也就是说,你使用了集群 分布式系统是扩展了吞吐量,无法提高单机性能的。

对于你这个案例,非常类似LMAX架构,使用单线程每秒可处理600万订单,这才是你要的性能。

提高性能,向非堵塞NoBlocking方面发展,你使用的LinkedBlockingQueue是一种堵塞队列,性能肯定不高,推荐使用Disruptor替代,见这个帖子

MichelleAnn
2012-03-14 10:12

恩,十分感谢你的回复,你给的参考我马上去看,这里先再补充一个问题。

就是,我如果不适用TC,单台服务的性能会比多台使用TC的性能要好,如果是因为用LBQ造成的,那后来我又使用TC自己提供的那个tim-masterworker的Moudle拿去测试,貌似还是存在处理速度不行,照这样说来,应该使我们本身的应用在处理单的时候,性能不够理想,对吗?

banq
2012-03-14 10:21

2012年03月14日 10:12 "@MichelleAnn"的内容
照这样说来,应该使我们本身的应用在处理单的时候,性能不够理想 ...

使用TC分布式集群系统肯定影响性能,因为其有锁机制,你原来有锁,再加把锁,当然越来越慢。

锁作用是保证业务交易的事务性和安全性,但是又是性能的克星。

这时你就需要好好分析你的业务应用,分清楚哪些需要锁,哪些不需要锁,可以用不变性等其他方式替代的。

兵马俑属于一种数据网格,和一般无锁的分布式缓存如memcache和Redis区别就是其有一套锁机制,见这个案例,分析了数据网格和分布式缓存区别。

如果你的订单是将买卖双方撮合,那么使用LMAX架构非常合适,那也是一个撮合交易系统,如果类似售票系统,那么不是一种撮合,而是一种连续ID分配问题。

所以,根据你的业务特点选择合适架构。因为我无法深入了解你的系统,只能说到这里,针对性不是很强,希望对你有帮助。