业务系统性能问题诊断和优化分析( 二 ) _业务系统性能

应用中间件性能分析和调优
应用中间件容器即我们常说的Weblogic, Tomcat等应用中间件容器或Web容器。应用中间件调优一个方面是本身的配置参数优化设置，一个方面就是JVM内存启动参数调优。
对于应用中间件本身的参数设置，主要包括了JVM启动参数设置，线程池设置，连接数的最小最大值设置等。如果是集群环境，还涉及到集群相关的配置调优。
对于JVM启动参数调优，往往也是应用中间件调优的一个关键点，但是一般JVM参数调优会结合应用程序一起进行分析。

文章插图

比如我们常见的JVM堆内存溢出，如果程序代码没有内存泄漏问题的话，我就需要考虑调整JVM启动时候堆内存设置。在32位操作系统下只能够设置到4G，但是在64位操作系统下已经可以设置到8G甚至更大的值。
其中JVM启动的主要控制参数说明如下:

-Xmx设置最大堆空间
-Xms设置最小堆空间
-XX:MaxNewSize设置最大新生代空间
-XX:NewSize设置最小新生代空间
-XX:MaxPermSize设置最大永久代空间(注：新内存模型已经替换为Metaspace)
-XX:PermSize设置最小永久代空间(注：新内存模型已经替换为Metaspace)
-Xss设置每个线程的堆栈大小

那么这些值究竟设置多大合适，具体来讲：

文章插图

Java整个堆大小设置，Xmx 和 Xms设置为老年代存活对象的3-4倍，即FullGC之后的老年代内存占用的3-4倍。永久代 PermSize和MaxPermSize设置为老年代存活对象的1.2-1.5倍。
年轻代Xmn的设置为老年代存活对象的1-1.5倍。
老年代的内存大小设置为老年代存活对象的2-3倍。

注意在新的JVM内存模型下已经没有PermSize而是变化为Metaspace，因此需要考虑Heap内存和Metaspace大小的配比，同时还需要考虑相关的垃圾回收机制是采用哪种类型等。

对于JVM内存溢出问题，我前面写过一篇专门的分析文章可以参考。
从表象到根源-一个软件系统JVM内存溢出问题分析解决全过程

文章插图

软件程序性能问题分析
在这里首先要强调的一点就是，当我们发现性能问题后首先想到的就是扩展资源，但是大部分的性能问题本身并不是资源能力不够导致，而是我们程序实现上出现明显缺陷。
比如我们经常看到的大量循环创建连接，资源使用了不释放，SQL语句低效执行等。
为了解决这些性能问题，最好的方法仍然是在事前控制。其中包括了事前的代码静态检查工具的使用，也包括了开发团队对代码进行的Code Review来发现性能问题。
所有已知的问题都必须形成开发团队的开发规范要求，避免重复再犯。
业务系统性能问题扩展思考对于业务系统的性能优化，除了上面谈到的标准分析流程和分析要素外，再谈下其它一些性能问题引发的关键思考。
上线前的性能测试是否有用？
有时候大家可能觉得奇怪，为何我们系统上线前都做了性能测试，为何上线后还是会出现系统性能问题。那么我们可以考虑下实际上我们上线前性能测试可能存在的一些无法真实模拟生产环境的地方，具体为：

硬件能否完全模拟真实环境？最好的性能测试往往是直接在搭建完成的生产环境进行。
数据量能否模拟实际场景？真实场景往往是多个业务表都已经存在大数据量的积累而非空表。
并发能否模拟真实场景？一个是需要录制复合业务场景，一个是需要多台压测机。

而实际上我们在做性能测试的时候以上几个点都很难真正做到，因此要想完全模拟出生产真实环境是相当困难的，这也导致了很多性能问题是在真正上线后才发现。
系统本身水平弹性扩展是否完全解决性能问题？
第二个点也是我们经常谈的比较多的点，就是我们的业务系统在进行架构设计的时候，特别是面对非功能性需求，我们都会谈到系统本身的数据库，中间件都采用了集群技术，能够做到弹性水平扩展。那么这种弹性水平扩展能力是否又真正解决了性能问题？
实际上我们看到对于数据库往往很难真正做到无限的弹性水平扩展，即使对于Oracle RAC集群往往也是最多扩展到单点的2到3倍性能。对于应用集群往往可以做到弹性水平扩展，当前技术也比较成熟。