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

当中间件能够做到完全弹性扩展的时候，实际上仍然可能存在性能问题，即随着我们系统的运行和业务数据量的不断积累增值。实际上你可以看到往往非并发状态下的单用户访问本身就很慢，而不是说并发上来后满。因此也是我们常说的要给点，即：

单点访问性能正常的时候可以扩展集群来应对大并发状态下的同时访问
单点访问本身性能就有问题的时候，要优先优化单节点访问性能

业务系统性能诊断的分类
对于业务系统性能诊断，如果从静态角度我们可以考虑从以下三个方面进行分类

操作系统和存储层面
中间件层面（包括了数据库，应用服务器中间件）
软件层面（包括了数据库SQL和存储过程，逻辑层，前端展现层等）

那么一个业务系统应用功能出现问题了，我们当然也可以从动态层面来看实际一个应用请求从调用开始究竟经过了哪些代码和硬件基础设施，通过分段方法来定位和查询问题。
比如我们常见的就是一个查询功能如果出现问题了，首先就是找到这个查询功能对应的SQL语句在后台查询是否很慢，如果这个SQL本身就慢，那么就要优化优化SQL语句。如果SQL本身快但是查询慢，那就要看下是否是前端性能问题或者集群问题等。
软件代码的问题往往是最不能忽视的一个性能问题点
对于业务系统性能问题，我们经常想到的就是要扩展数据库的硬件性能，比如扩展CPU和内存，扩展集群，但是实际上可以看到很多应用的性能问题并不是硬件性能导致的，而是由于软件代码性能引起的。对于软件代码常见的性能问题我在以往的博客文章里面也谈过到，比较典型的包括了。

循环中初始化大的结构对象，数据库连接等
资源不释放导致的内存泄露等
没有基于场景需求来适度通过缓存等方式提升性能
长周期事务处理耗费资源
处理某一个业务场景或问题的时候，没有选择最优的数据结构或算法

以上都是常见的一些软件代码性能问题点，而这些往往需要通过我们进行Code Review或代码评审的方式才能够发现出来。因此如果要做全面的性能优化，对于软件代码的性能问题排查是必须的。
通过IT资源监控或APM应用工具来发现性能问题

文章插图
图片来源 OneAPM
对于性能问题的发现一般有两条路径，一个就是通过我们IT资源的监控，APM的性能监控和预警来提前发现性能问题，一个是通过业务用户在使用过程中的反馈来发现性能问题。
APM应用性能管理主要指对企业的关键业务应用进行监测、优化，提高企业应用的可靠性和质量，保证用户得到良好的服务，降低IT总拥有成本(TCO) 。
资源池-》应用层-》业务层
这个可以理解为APM的一个关键点，原有的网管类监控软件更多的是资源和操作系统层面，包括计算和存储资源的使用和利用率情况，网络本身的性能情况等。但是当要分析所有的资源层问题如何对应到具体的应用，对应到具体的业务功能的时候很难。
传统模式下，当出现CPU或内存满负荷的时候，如果要查找到具体是哪个应用，哪个进程或者具体哪个业务功能，哪个sql语句导致的往往并不是容易的事情。在实际的性能问题优化中往往也需要做大量的日志分析和问题定位，最终才可能找到问题点。

比如在我们最近的项目实施中，结合APM和服务链监控，我们可以快速的发现究竟是哪个服务调用出现了性能问题，或者快速的定位出哪个SQL语句有验证的性能问题。这个都可以帮助我们快速的进行性能问题分析和诊断。

资源上承载的是应用，应用本身又包括了数据库和应用中间件容器，同时也包括了前端；在应用之上则是对应到具体的业务功能。因此APM一个核心就是要将资源-》应用-》功能之间进行整合分析和衔接。
而随着DevOps和自动化运维的思路推进，我们更加希望是通过APM等工具主动监控来发现性能问题，对于APM工具最大的好处就是可以进行服务全链路的性能分析，方便我们发现性能问题究竟发生在哪里。比如我们提交一个表单很慢，通过APM分析我们很容易发现究竟是调用哪个业务服务慢，或者是处理哪个SQL语句慢。这样可以极大的提升我们性能问题分析诊断的效率。