性能优化对于程序员来说是需要长期关注的一个问题,而今天我们就通过案例分析来了解一下,java服务性能优化包含哪些方面的内容。
服务器高CPU、高负载
先要解决的问题就是服务导致服务器整体负载高、CPU高的问题。
我们的服务整体可以归纳为从某个存储或远程调用获取到一批数据,然后就对这批数据进行各种花式变换,后返回。由于数据变换的流程长、操作多,系统CPU高一些会正常,但平常情况下就CPUus50%以上,还是有些夸张了。
我们都知道,可以使用top命令在服务器上查询系统内各个进程的CPU和内存占用情况。可是JVM是Java应用的领地,想查看JVM里各个线程的资源占用情况该用什么工具呢?
jmc是可以的,但使用它比较麻烦,要进行一系列设置。我们还有另一种选择,就是使用jtop。
熔断框架优化
服务熔断框架上,我们选用了Hystrix,虽然它已经宣布不再维护,更推荐使用resilience4j和阿里开源的sentinel,但由于部门内技术栈是Hystrix,而且它也没有明显的短板,就接着用下去了。
先介绍一下基本情况,我们在控制器接口外层和内层RPC调用处添加了Hystrix注解,隔离方式都是线程池模式,接口处超时时间设置为1000ms,大线程数是2000,内部RPC调用的超时时间设置为200ms,大线程数是500。
响应时间不正常
要解决的一个问题是接口的响应时间不正常。在观察接口的access日志时,可以发现接口有耗时为1200ms的请求,有些甚至达到了2000ms以上。由于线程池模式下,Hystrix会使用一个异步线程去执行真正的业务逻辑,而主线程则一直在等待,一旦等待超时,主线程是可以立刻返回的。所以接口耗时超过超时时间,问题很可能发生在Hystrix框架层、Spring框架层或系统层。