我们知道fabric中间件可以实现HA故障自动切换、水平分片、读写负载等功能。无需额外安装代理,使用方便。那fabric本身是否会存在性能瓶颈点呢?
因此,接下来我们就对fabric中间件进行压力测试。
思路:
fabric中间件主要起路由功能,客户端连接池一旦初始化之后,和fabric的关系已经不大。当然也有一些连接池会配置定时检测连接池的健康状态,此时会定时连接一下fabric。
所以,fabric中间件服务器的压力关键在于连接的初始化这块。fabric中间件的压测,就变成对fabric连接请求的处理能力的压测了。
压测过程:改写java连接fabric的jar包:实现只连接fabric,不连接业务库。
写一个jsp页面来循环执行fabric的连接动作(特意不使用连接池,以达到压测的效果,且只做连接fabric的动作,不连接到业务数据库)。
压测结果:
连接fabric请求10000次,花了376秒。即:每秒可以请求26.6次连接,每次连接消耗37.6ms。
进行计算:
假设有500个应用(即500个连接池),每个连接池初始化100个连接,fabric中间件每秒可以处理26.6次,我们这里按25次来算,则500个应用的连接初始化时间为:
500*100/25/60=33.33分钟。
就是说:假如机房停电,然后fabric中间件的500个应用都要上来进行初始化连接池时,则要经过33分钟才来完全初始化好。
当然,实际情况是应用的连接池初始化通常是有的先有的后,不会一下子拥上来,但我们要知道这么大的连接,一下子拥上来,这是非常耗时间的。
压测过程,硬件资源使用情况:IO使用率在0.3%左右,CPU使用率5%。也就是对硬件的使用率还是非常低的。
补充:
fabric的连接走的是xmlrpc协议,且客户端的一次fabric连接请求,实际上做了两次的连接fabric数据库(注:不是业务数据库,而是fabric的数据库,即backing store哦),同时操作fabric数据库10次(6次select,4次insert)。因此,fabric连接请求的时间相对于jdbc直连的效率要低多了。
原文:http://nycle.blog.51cto.com/1119720/1614503