Dubbo 性能调优经历（一）

Dubbo调优经历

原型阶段，主要影响如下：

服务的日志I/O 会影响性能。

数据库的I/O 会严重影响性能。

服务的部署情况 会影响性能。

原型优化：

1.优化数据库，尝试使用内存，增大内存buff。

2.调整服务部署，服务间调用，由于该宿主机器的cpu占用率不同和磁盘I/O网络等不同，需要不断的尝试服务部署机器之间的分配，要将需求资源大的服务部署在较好的环境，并且竞争较少的情况可以提升tps。

3. 服务本身耗时极低，几乎忽略。

4.将调用者和被调用者尽量部署在同一宿主机，可以降低一部分耗时。

5.将所有服务部署在一台非常好的机器 32U 128G机器上，CPU /内存皆没达到瓶颈，将数据库部署在另外一台这样的PC物理机上，延迟会大大降低，但是依然存在RPC调用在400并发下8-10秒的耗时。（后续可以优化这个RPC耗时） 

过程：

使用工具:

Linux 常用工具包

Jemeter http post请求

 

涉及中间件:

Zookeeper

Redis

 

原型阶段：

共涉及服务10个，涉及数据库5个。内部协议 dubbo 对外协议:rest

 

部署大致如下:

3台pc机，3台宿主机，超分，每个虚机上部署一个服务。大致是宿主机4颗8核2GHz *2、4颗6核心1.87GHx  *1、4C8G PC机8台。

 

部署完后直接使用jemeter跑出结果 1700TPS。

 

现象：各服务和数据库的cpu都不高，三台数据库io很高，相关应用服务出现网络阻塞等待。

分析结果：三台数据库插入操作多，数据库服务器的磁盘io达到瓶颈

 

改动1:因为资源有限，无法顾及I/O问题，顾临时修改数据库为内存写，不落盘。TPS提升

但是查看到redis内存消耗不足,redis服务器内存达到瓶颈

此时tps:2400

 

改动2: 将Redis移至主频和内存高的pc机，资源有限，将原本pc机上的服务移至虚机。

Tps提示至2800

 

资源有限，没有进一步测试。

 

后将服务的分布调整更合理之后，并将数据库部署在本地PC机上，磁盘IO 单线程10M/s的情况下，并发数400达到TPS 3800.

 

Duboo单服务调用，使用rest接口，TPS 1W9（关掉日志等IO影响）（开启日志1W3 达到写日志磁盘I/O瓶颈 写等待出现队列 utils 90%）