神券的改进
压测的目的是为了根据压测的结果来进行进一步的性能调优,这里记一下这段时间看到过的一些性能调优
某一个根据当前坐标查询某一个范围内对应商家的数目
涉及到的一些有趣的Tips:
es
的使用geohash
算法 :序列化:
filter
:线程池:
尝试做的一些优化:
最开始的时候需要对需求做一些优化,要求对当前的耗时以及单位时间处理的速度进行较大幅度的提升。而通过测试发现,接口使用的大部分时间存在于数据的获取,而目前使用的是从
es
中获取到数据,而猜想使用本地缓存会较大幅度解决数据获取的速度。而在将数据的获取从
es
换成从本地缓存中获取之后,发现并没有实现进一步速度的提升。于是猜测是否是在序列化的过程中(这里使用远程调用会涉及到序列化),当前项目中使用的JDK包的版本和目前企业平台使用的JDK版本存在差异导致速率变化。于是在运行的服务器中修改不同版本的JDK序列化包。这个时候发现实际的性能上并没有得到太好的提升,排除该原因,而关于数据获取的原因猜测为因为
filter
中需要控导致(其相关作用考虑上文:https://blog.csdn.net/qq_34861102/article/details/80643385)。于是修改,将当前的filter
的限制去除,进行测试。TPS
得到显著的提升。
后续对需求又有了更高的要求,进行进一步性能调优:
首先对代码进行检查,发现目前使用的线程池中最大线程数设置较小(关于线程池)会导致线程中可能出现的等待情况。同时进行了其他的一些项目资源的调整:去掉项目中目前无用的
MQ
的使用,然后进行优化以前的一些代码,但是效果都不明显。为了实现响应的性能要求,于是和业务方提出了一种降级方案, 缩小了坐标的指定框的大小:即目前使用的是
geohash
算法通过限制得到的Hash
值的模糊比较范围实现,在实际业务中不会涉及到过大的范围查询,通过减少模糊比较范围实现了性能的要求