性能测试:系统架构性能优化思路

2797 篇文章 2 订阅
2644 篇文章 26 订阅
文章探讨了业务系统上线后出现性能问题的常见场景,如大并发、数据量增长和网络带宽变化。分析流程包括判断单用户或并发性能问题,通过测试和监控CPU、内存、JVM。硬件环境、数据库和中间件的性能调优是关键,同时指出上线前的性能测试难以完全模拟生产环境,强调软件代码优化的重要性。文章还提到了性能诊断的分类和软件代码可能导致的性能问题,如资源未释放、不适当的缓存策略等。
摘要由CSDN通过智能技术生成

01 系统性能问题分析流程

我们首先来分析下如果一个业务系统上线前没有性能问题,而在上线后出现了比较严重的性能问题,那么实际上潜在的场景主要来自于以下几个方面。

业务出现大并发的访问,导致出现性能瓶颈

上线后的系统数据库数据日积月累,数据量增加后出现性能瓶颈

其它关键环境改变,比如我们常说的网络带宽影响

正是由于这个原因,当我们发现性能问题的时候,首先就需要判断是单用户非并发状态下本身就有性能问题,还是说在并发状态才存在性能问题。对于单用户性能问题往往比较容易测试和验证,对于并发性能问题我们可以在测试环境进行加压测试和验证,以判断并发下的性能。

如果是单用户本身就存在性能问题,那么大部分问题都出在程序代码和SQL需要进一步优化上面。如果是并发性能问题,我们就需要进一步分析数据库和中间件本身的状态,看是否需要对中间件进行性能调优。

在加压测试过程中,我们还需要对CPU,内存和JVM进行监控,观察是否存在类似内存泄漏无法释放等情况,即并发下性能问题本身也可能是代码本身原因导致性能异常。

02 性能问题影响因素分析

对于性能问题影响因素,简单来说包括了硬件环境,软件运行环境和软件程序三个方面的主要内容。下面分别再展开说明下。

硬件环境

硬件环境就是我们常说的计算,存储和网络资源。

对于服务器的计算能力,一般来说厂家都会提供TPMC参数作为一个参考数据,但是我们实际看到相同TPMC能力下的X86服务器能力仍然低于小型机的能力。

除了服务器的计算能力参数,另外一个重点就是我们说的存储设备,影响到存储的重点又是IO读写性能问题。有时候我们监控发现CPU和内存居高不下,而真正的瓶颈通过分析反而发现是由于IO瓶颈导致,由于读写性能跟不上,导致大量数据无法快速持久化并释放内存资源。

比如在Linux环境下,本身也提供了性能监控工具方便进行性能分析。比如常用的iostat,ps,sar,top,vmstat等,这些工具可以对CPU,内存,JVM,磁盘IO等进行性能监控和分析,以发现真正的性能问题在哪里。

比如我们常说的内存使用率持续告警,你就必须发现是高并发调用导致,还是JVM内存泄漏导致,还是本身由于磁盘IO瓶颈导致。

运行环境-数据库和应用中间件

数据库和应用中间件性能调优是另外一个经常出现性能问题的地方。

数据库性能调优

拿Oracle数据库来说,影响数据库性能的因素包括:系统、数据库、网络。数据库的优化包括:优化数据库磁盘I/O、优化回滚段、优化Rrdo日志、优化系统全局区、优化数据库对象。

03 业务系统性能问题扩展思考

对于业务系统的性能优化,除了上面谈到的标准分析流程和分析要素外,再谈下其它一些性能问题引发的关键思考。

上线前的性能测试是否有用?

有时候大家可能觉得奇怪,为何我们系统上线前都做了性能测试,为何上线后还是会出现系统性能问题。那么我们可以考虑下实际上我们上线前性能测试可能存在的一些无法真实模拟生产环境的地方,具体为:

硬件能否完全模拟真实环境?最好的性能测试往往是直接在搭建完成的生产环境进行。

数据量能否模拟实际场景?真实场景往往是多个业务表都已经存在大数据量的积累而非空表。

并发能否模拟真实场景?一个是需要录制复合业务场景,一个是需要多台压测机。

而实际上我们在做性能测试的时候以上几个点都很难真正做到,因此要想完全模拟出生产真实环境是相当困难的,这也导致了很多性能问题是在真正上线后才发现。

系统本身水平弹性扩展是否完全解决性能问题?

第二个点也是我们经常谈的比较多的点,就是我们的业务系统在进行架构设计的时候,特别是面对非功能性需求,我们都会谈到系统本身的数据库,中间件都采用了集群技术,能够做到弹性水平扩展。那么这种弹性水平扩展能力是否又真正解决了性能问题?

实际上我们看到对于数据库往往很难真正做到无限的弹性水平扩展,即使对于Oracle RAC集群往往也是最多扩展到单点的2到3倍性能。对于应用集群往往可以做到弹性水平扩展,当前技术也比较成熟。

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

单点访问性能正常的时候可以扩展集群来应对大并发状态下的同时访问

单点访问本身性能就有问题的时候,要优先优化单节点访问性能

04 业务系统性能诊断的分类

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

操作系统和存储层面

中间件层面(包括了数据库,应用服务器中间件)

软件层面(包括了数据库SQL和存储过程,逻辑层,前端展现层等)

那么一个业务系统应用功能出现问题了,我们当然也可以从动态层面来看实际一个应用请求从调用开始究竟经过了哪些代码和硬件基础设施,通过分段方法来定位和查询问题。

比如我们常见的就是一个查询功能如果出现问题了,首先就是找到这个查询功能对应的SQL语句在后台查询是否很慢,如果这个SQL本身就慢,那么就要优化优化SQL语句。如果SQL本身快但是查询慢,那就要看下是否是前端性能问题或者集群问题等。

软件代码的问题往往是最不能忽视的一个性能问题点

对于业务系统性能问题,我们经常想到的就是要扩展数据库的硬件性能,比如扩展CPU和内存,扩展集群,但是实际上可以看到很多应用的性能问题并不是硬件性能导致的,而是由于软件代码性能引起的。对于软件代码常见的性能问题我在以往的博客文章里面也谈过到,比较典型的包括了。

循环中初始化大的结构对象,数据库连接等

资源不释放导致的内存泄露等

没有基于场景需求来适度通过缓存等方式提升性能

长周期事务处理耗费资源

处理某一个业务场景或问题的时候,没有选择最优的数据结构或算法

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

最后:下方这份完整的软件测试视频教程已经整理上传完成,需要的朋友们可以自行领取【保证100%免费】

软件测试面试文档

我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。

在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值