我们知道fabric中间件可以实现HA故障自动切换、水平分片、读写负载等功能。无需额外安装代理，使用方便。那fabric本身是否会存在性能瓶颈点呢?

　　因此，接下来我们就对fabric中间件进行压力测试。

　　

思路：

　　fabric中间件主要起路由功能，客户端连接池一旦初始化之后，和fabric的关系已经不大。当然也有一些连接池会配置定时检测连接池的健康状态，此时会定时连接一下fabric。

　　所以，fabric中间件服务器的压力关键在于连接的初始化这块。fabric中间件的压测，就变成对fabric连接请求的处理能力的压测了。


压测过程：

  1. 改写java连接fabric的jar包：实现只连接fabric，不连接业务库。

  2. 写一个jsp页面来循环执行fabric的连接动作(特意不使用连接池，以达到压测的效果，且只做连接fabric的动作，不连接到业务数据库)。

  3. 压测结果：

    连接fabric请求10000次，花了376秒。即：每秒可以请求26.6次连接，每次连接消耗37.6ms。

    注：这里的连接指的是jsp客户端连接到fabric的一个完整的连接请求过程(这个请求过程，实际上做了很多动作：连接两次fabric数据库，执行了6个select,4个insert)。

  4. 进行计算：


    　　假设有500个应用(即500个连接池)，每个连接池初始化100个连接，fabric中间件每秒可以处理26.6次，我们这里按25次来算，则500个应用的连接初始化时间为：

    　　500*100/25/60=33.33分钟。

    　　就是说：假如机房停电，然后fabric中间件的500个应用都要上来进行初始化连接池时，则要经过33分钟才来完全初始化好。

    　　当然，实际情况是应用的连接池初始化通常是有的先有的后，不会一下子拥上来，但我们要知道这么大的连接，一下子拥上来，这是非常耗时间的。

  5. 压测过程，硬件资源使用情况：IO使用率在0.3%左右，CPU使用率5%。也就是对硬件的使用率还是非常低的。


补充：

fabric的连接走的是xmlrpc协议，且客户端的一次fabric连接请求，实际上做了两次的连接fabric数据库(注：不是业务数据库，而是fabric的数据库，即backing store哦)，同时操作fabric数据库10次(6次select，4次insert)。因此，fabric连接请求的时间相对于jdbc直连的效率要低多了。