性能测试：系统架构性能优化，2024年最新35岁之后找不到工作怎么办

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注软件测试）

正文

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

要调整首先就需要对数据库性能进行监控

我们可以在init.ora参数文件中设置TIMED_STATISTICS=TRUE 和在你的会话层设置ALTER SESSION SET STATISTICS=TRUE 。运行svrmgrl 用 connect internal 注册，在你的应用系统正常活动期间，运行utlbstat.sql 开始统计系统活动，达到一定的时间后，执行utlestat.sql 停止统计。统计结果将产生在report.txt 文件中。

数据库性能优化应该是一个持续性的工作，一个方面是本身的性能和参数巡检，另外一个方面就是DBA也会经常提取最占用内存的低效SQL语句给开发人员进一步分析，同时也会从数据库本身的以下告警KPI指标中发现问题。

比如我们可能会发现Oracle数据库出现内存使用率高的告警，而通过检查会发现是产生了大量的Redo日志导致，那么我们就需要从程序上进一步分析为何会产生如此多的回滚。

应用中间件性能分析和调优

应用中间件容器即我们常说的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倍性能。对于应用集群往往可以做到弹性水平扩展，当前技术也比较成熟。

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

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

业务系统性能诊断的分类

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

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

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

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

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

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

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

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

通过IT资源监控或APM应用工具来发现性能问题

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
的技术提升。**

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）
[外链图片转存中…(img-CqZgRMQl-1713551257836)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！