type
status
date
slug
summary
tags
category
icon
password
前言
功能实现后做了一下性能测试，发现数据很烂，所以考虑优化下
存在的问题
- 并发多个请求发现Waiting时间依次递增
|次序| 接口 | Status | Time |
|----------------------|
|1| toPng | 200 | 275ms |
|2| toPng | 200 | 480ms |
|3| toPng | 200 | 726ms |
|4| toPng | 200 | 1.00s |
|5| toPng | 200 | 1.23s |
|6| toPng | 200 | 1.49s |
于是检查代码,发现了这个:
nodejs里怎么能有同步I/O呢，肯定要玩异步啦，于是变成了这样:
满心欢喜的去测试,发现成了酱紫:
|次序| 接口 | Status | Time |
|----------------------|
|1| toPng | 200 | 1.40s |
|2| toPng | 200 | 474ms |
|3| toPng | 200 | 856ms |
|4| toPng | 200 | 1.61s |
|5| toPng | 200 | 650ms |
|6| toPng | 200 | 1.11s |
- 怀疑是并发读取文件，磁盘响应变得更慢导致的;
- 因为测试的时候用的是同一份数据，字体也是同一个,不知道并发读取同一个文件有没有额外影响(这个没测试，懒)
初步优化
- 因为字体文件数量有限,所以考虑把字体读取后缓存在内存中,理论上命中率应该很高；
- 根据ab的结果，发现每个接口的处理速度很快，但是并发高的时候会存在任务堆积，导致响应变慢；
压测数据如下:
并发数为20:
并发数为50:
继续优化
- 使用OneAPM进行追踪,发现获取背景图片那一步耗时过大；
- 根据业务需求,背景图数量有限,所以都缓存到内存中；
- 再次使用ab进行压测；
压测数据如下:
并发数为20:
并发数为50:
优化结果
- 根据ab结果，平均响应时间有所下降，所以图片缓存是有效的；
- 但是效果貌似不是很明显,所以排查其它方面的问题继续处理；
- 通过监控系统资源占用发现,在并发20个请求的时候cpu占用就100%,所以单机性能优化暂时就到这里了；