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

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

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

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

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

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

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

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

        例如数据库、例如网络

第三:业务的分析

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

第四:检查你的架构

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

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

第五:使用性能分析工具

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

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

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

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

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

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

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

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

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

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

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

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

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

相关推荐