β

系统重构,性能优化的几点心得

万马奔腾 197 阅读

最近接手了一个新的任务,去优化一个现有的网站。由于用户快速的增加,APP推送消息之后,大量用户涌进,导致系统的崩溃。经过一段时间,和几个小伙伴一起优化,最终核心接口的QPS从原来的600到现在的1500左右。业务太复杂,再提升不是那么容易了。

服务抽离

抽离出单独数据访问层,这一层由go实现。php这层只实现业务逻辑,数据从go获得。这样有两个好处

  1. 可以使用之前的不少代码,减少重构时间
  2. php开发业务逻辑速度也快不少

缓存使用

  1. php从原来的直接读取数据库或者Redis,改成go先读本地内存,如果无法命中,再读取数据库或者Redis.
  1. Redis由之前的单一分片,改成多个分片。由于性能瓶颈不在于Redis,提升作用不大。主要是业务增长过快,单一机器扩容不太容易,需要尽快的分片。
  1. php读取网站配置等信息的时候,由于配置信息值太大,导致Redis网卡打满。所以讲这些配置信息,php也会先使用本地缓存。
  2. apc_fetch获得大value的时候,性能会急剧的下降,不如使用文件缓存。开启apc缓存opcode,加载缓存文件,性能损失很小。
  3. 为了防止多个请求,在使用文件缓存在同一时间失效,导致缓存文件大量的重复写。失效时间小于1秒,3秒,设置比较高的概率,继续使用之前的缓存。当失效时间大于5秒的时候,才必须要求重写数据,写入文件缓存。

代码层优化

  1. php引入的类库文件数量,代码行数尽可能小一些。哪怕任何事情都不做,也会拖慢性能。
  2. 当接口返回类型的非html的时候,就不引入smarty,太耗性能了。通过这种方式,性能可以翻倍。
  3. thrift返回结果使用json格式,不用复杂类型。解析比json还耗性能,这样大概能提高5%的性能。同样生成的出来的代码行数降低很多,也能提高不少性能。
  4. 同一个服务,多个接口,连接对象要复用。
  5. 请求同一个服务,可以把多个服务合并请求,让go来并发的来处理。
  6. thrift由于使用内部改造的一种transport,通过xprof查看,发现调用write和read上千次。估计是一种轮训阻塞的方式。由于无法切换到其他的协议,无法知道使用其他协议会带来多少好处。通过搜索了解到一些知识, 预测改成TFramedTransport 或许会有性能改进。

重构之后,第一次压测发现只有300,心都凉了半截,比之前都差,经过一个星期的不断努力,终于比之前还高一倍。信心还是要有的!!!

转载请注明: 万马奔腾 » 系统重构,性能优化的几点心得

作者:万马奔腾
让现在的你喜欢未来的自己
原文地址:系统重构,性能优化的几点心得, 感谢原作者分享。