关于性能优化的一点思考

关于性能优化的一点思考

背景

  最近,在做一个项目需要对某些数据进行处理并且提供API接口查询。该项目每天的数据量,经过压缩后大概是10G左右。而且这个项目对于实时性要求很高,不宜直接使用Mysql来读写数据。

  于是采用了Redis的集群,把每天的实时数据存在Redis里面,再通过别的方式将旧数据存放在Mysql里面做一个备份。

第一次尝试:数据量测试

  把存储数据的方式确定为Redis后,我们开始了第一次的尝试,对数据的容量做一次测试,对每天的数据都是通过JSON的形式存在Redis中。本以为40G内存的Redis完全可以应付每天的数据。结果,一天的数据还没接收完,Redis就因为可使用的内存不足导致宕机。没办法,可用的内存有限,不得不将数据进行压缩。

使用Protobuf

  经过一次数据容量的测试,发现以JSON的数据结构存在Redis中太浪费内存了,于是又经过一轮讨论,我们决定使用Protobuf,将数据通过Protobuf序列化存在Redis中。改造完后,又进行了一次压力测试,终于Redis集群没有再次宕机。并且,将原来每天最少40G的数据量,成功的减少到了10G,也就是说减少了4倍的内存占用。

第二次尝试:API接口的压力测试

  搞定了接收数据的程序,并且也搞定了第一版的API接口,于是我们对API进行了一次压力测试。

第一次测试

API服务器配置为8核32G,压测服务器8和32G,使用wrk工具进行简单的压力测试

一共有3个接口,QPS测试结果(大致数据):

  • 当日数据接口(217/QPS)
  • 五日数据接口(30/QPS)
  • 详细数据接口(4000+/QPS)

初次测试的结果并不是很理想,特别是当日数据和五日数据接口,都没有达到测试的标准。并且这两个接口每次请求都会对数据进行一次计算,于是继续改造。将需要算的数据,都放在接收数据的程序中,API只是获取数据

第二次测试

把API计算的部分放在了接收的程序中,让接收程序进行计算,不让API每次都进行计算。并且再次进行了一次对当日数据和五日数据接口的压力测试,测试结果如下:

  • 当日数据接口(340+/QPS)
  • 五日数据接口(300+/QPS)

通过这次的压力测试,可以发现这两个接口的有一定的提升,也就是说这次优化是有效的。但,我依旧不够满意。我发现,这些数据有一个特点,就是旧的数据它不会变,那么就可以对旧的数据在本地内存中进行缓存,减少从Redis获取数据发起的网络请求。

第三次测试

  将API接口改为了将历史数据缓存在本地内存中,并且减少了发起网络请求的次数。再次进行压力测试,测试结果如下:

  • 当日数据接口(10000+/QPS)
  • 五日数据接口(6400+/QPS)

可以发现,对旧的历史数据缓存,减少发起网络请求的优化之后,QPS有明显的提升。

总结

在对程序性能的分析时,使用了阿里开源的Arthas工具,发现最影响程序性能的地方,就是从Redis获取数据时发起的网络请求最耗时。

经过这次的优化中,我有几点总结:

  • 直接将JSON数据存在Redis太浪费,并且API获取数据时,需要的时间会明显的高于Protobuf序列化后存在Redis中的数据获取时间。
  • 减少API对数据计算的次数,最好不计算,把需要计算的数据放在别的地方,并且存起来
  • 减少发起网络请求的次数,因为在这次测试的结果中,经过分析后发现最耗时间也最浪费性能的地方就是获取Redis数据时,需要发起的网络请求。

评论

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×