欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

系统设计和开发中,方法论比技术更重要--兼谈怎样做Java服务器的性能分析和调整

程序员文章站 2022-07-03 16:21:38
...

 

记得在前些年,有一次,在客户那里做系统的性能分析和调整时,也是一点一点的分析,也没有什么头绪。有一个客户那边的负责人,对我们当时的一些做法表示不理解,当时他说了一句话:“做性能分析和调整,首先你得有自己的方法论,然后再谈具体的技术手段”。当时我们还觉得这个客户对我们有意见,觉得自己的做法没有什么不对的。但是在后面这些年里,我深刻的感觉到,这句话真是金玉良言。

 

其实我并不大喜欢充满哲学味道的东西,我喜欢简单直白的,但是,过于直白,直指目标的一些做法,让自己走了很多弯路,付了很多额外的代价,回过头来,再琢磨,原来那些简单又质朴的话,是不能违背的规律,是必须遵守的守则。

 

意识到这些之后,我特意针对性能分析和性能调优进行了很多的总结,尤其侧重在方法论,简单的描述一下吧。

 

第一:要判断性能分析的目标

 

          是为了PK,还是为了实际使用?

 

          你的真实场景,到底需要什么样的性能?

 

 

第二:你的周边环境,到底可以为你提供什么样的效率和性能?

 

        例如数据库、例如网络

 

 

第三:业务的分析

 

      业务流程是否可以优化?来提高效率?这个最好是对着每一个业务的流程图仔细思考。

 

第四:检查你的架构

 

      软件实现层面的效率问题,很多都是由架构不良带来的,你即便每一行代码都精简,都无法扭转坏的架构带来的影响。

 

     例如在哪里应当使用缓存,在哪里必须实时读数据库;在哪里需要等待(Sleep),在哪里可以立即进行;在哪里必须使用同步锁,在哪里可以并行或异步,等等等等。

 

第五:使用性能分析工具

 

     一般来讲,一般不使用性能分析工具来判断架构是否存在问题,而是用来判断具体代码环节是否有问题。使用工具,理念就是“先查找到瓶颈,再进行优化”。实际上,应该是前边几条之后,再进行这一层面上的分析。

 

工具有几类,有Java自带的工具,有其他第三方工具。

 

    Java命令行可以通过参数,直接进行CPU、内存的分析。当然,还有JConsole和VisualVM,可以用来辅助进行性能分析。还可以分析GC的活动。

 

   第三方工具包括JProfile之类工具,可以进行更加细致的分析,分析结果直接转换成实时的曲线图,非常容易定位性能瓶颈。

 

使用工具,一般应该首先关注CPU(当然,除非你怀疑自己的系统有内存泄漏问题而进行排查,那样的话,优先关注内存),其次得关注线程(是否有过多的锁定和等待)。

 

关注CPU,直接定位到最消耗CPU的部分和方法,那么可以非常有针对性的把方法替换为高效实现,这是最简单的系统优化方法。

 

例如在某个系统分析时,发现Base64.encode消耗CPU非常多,于是在网上搜到了一个FastBase64的实现,替换上去,就发现系统性能马上提高一大截。

 

当然,最常见的是,解决了一个瓶颈,性能有所改进,又遇到另外一个瓶颈,每一步都非常艰难,每一步都有所进步。

 

 

关注线程,非常有利于发现配置不当引起的性能问题。例如数据库连接池配置的太小,例如线程池配置的太小,引起很多时候都在等待空闲连接(或空闲线程)的释放,发现哪里的问题,就可以通过调整配置的方式来改进系统。

 

 

关注内存,可以发现是否因为内存的不当使用,使系统很多时候在做GC,从而引起业务的暂停。

 

最后一点:要考虑系统特性的平衡

 

系统在某一个性能数据上,达到了一种极致。在此时,再继续做性能的优化,一定会牺牲系统的其他特性。在此时,如何折衷?是性能至上,继续高歌猛进,牺牲其他特性(例如可扩展性等等);还是优先考虑其他特性,接受当前的性能呢?这是所有架构师需要仔细考虑的问题。

 

 

说句题外话,在产品的设计、实现期间,又何尝不是如此,先要有了工作的方法论,再谈技术。没有方法论,产品变成一堆技术的杂烩,是一件可悲的事情。