0 前言
我有个朋友说他们国企的系统从未性能调优，功能测试完就上线，线上也没性能问题，何必还做性能调优？
本文搞清：
- 为什么要做性能调优？
- 啥时开始做？
- 做性能调优是不是有标准？
1 为啥做性能调优？
- 有些性能问题是慢慢产生，到了时间就自爆
- 更多性能问题是由访问量波动导致，如活动或公司产品用户量上升
- 也可能一款产品上线后就半死不活，一直没有大访问量，所以还没有引发这颗定时炸弹
现在假设你的系统要做一次活动，老板告诉你预计几十万的用户访问量，询问系统能否承受得住这次活动的压力。如果你不清楚自己系统的性能情况，也只能战战兢兢地回答老板，可能没问题吧。
要不要做性能调优
所有的系统开发完都有性能问题，先把问题暴露，如压测、模拟可能操作，再性能调优去解决。
- 如用某款 App 查询某条信息，需等待十几s
- 抢购活动中，无法进入活动页面
- ...
系统响应就是体现系统性能最直接的一个参考因素。若系统在线上没出现响应问题，就不用做性能优化了？有位大神在公司一年只做一件事：把服务器数量缩减到原来一半，系统性能指标，还提升了。
好的系统性能调优不仅可提高系统性能，还能为公司节省资源。这也是性能调优的最直接目的。
2 啥时调优？
项目初期
没必要性能优化，这反让我们疲于性能优化，不仅不能性能提升，还影响进度，甚至给系统带新问题。
只需代码层保证有效编码，如减少磁盘 I/O 操作、降低竞争锁使用及使用高效算法等。遇到复杂业务，充分利用设计模式优化业务代码。如设计商品价格，有很多折扣活动，可用装饰模式去设计这个业务。
系统编码完成
就可对系统进行性能测试。这时，产品经理一般提供线上预期数据，我们在提供的参考平台上进行压测，通过性能分析、统计工具统计各项性能指标，看是否在预期范围内。
项目成功上线
还要根据线上实际情况，依照日志监控及性能统计日志，观测系统性能问题，发现问题，就日志分析并及时修复。
3 啥能体现系统性能？
性能指标到底有啥？
3.0 计算机资源
得先知啥计算机资源会成为系统性能瓶颈。
CPU：有的应用需要大量计算，他们会长时间、不间断地占用 CPU 资源，导致其他资源无法争夺到 CPU 而响应缓慢，从而带来系统性能问题。例如，代码递归导致的无限循环，正则表达式引起的回溯，JVM 频繁的 FULL GC，以及多线程编程造成的大量上下文切换等，这些都有可能导致 CPU 资源繁忙。
内存：Java 程序一般通过 JVM 对内存进行分配管理，主要是用 JVM 中的堆内存来存储 Java 创建的对象。系统堆内存的读写速度非常快，所以基本不存在读写性能瓶颈。但是由于内存成本要比磁盘高，相比磁盘，内存的存储空间又非常有限。所以当内存空间被占满，对象无法回收时，就会导致内存溢出、内存泄露等问题。
磁盘 I/O：磁盘相比内存来说，存储空间要大很多，但磁盘 I/O 读写的速度要比内存慢，虽然目前引入的 SSD 固态硬盘已经有所优化，但仍然无法与内存的读写速度相提并论。
网络：网络对于系统性能来说，也起着至关重要的作用。如果你购买过云服务，一定经历过，选择网络带宽大小这一环节。带宽过低的话，对于传输数据比较大，或者是并发量比较大的系统，网络就很容易成为性能瓶颈。
异常：Java 应用中，抛出异常需要构建异常栈，对异常进行捕获和处理，这个过程非常消耗系统性能。如果在高并发的情况下引发异常，持续地进行异常处理，那么系统的性能就会明显地受到影响。
数据库：大部分系统都会用到数据库，而数据库的操作往往是涉及到磁盘 I/O 的读写。大量的数据库读写操作，会导致磁盘 I/O 性能瓶颈，进而导致数据库操作的延迟性。对于有大量数据库读写操作的系统来说，数据库的性能优化是整个系统的核心。
锁竞争：在并发编程中，我们经常会需要多个线程，共享读写操作同一个资源，这个时候为了保持数据的原子性（即保证这个共享资源在一个线程写的时候，不被另一个线程修改），我们就会用到锁。锁的使用可能会带来上下文切换，从而给系统带来性能开销。JDK1.6 之后，Java 为了降低锁竞争带来的上下文切换，对 JVM 内部锁已经做了多次优化，例如，新增了偏向锁、自旋锁、轻量级锁、锁粗化、锁消除等。而如何合理地使用锁资源，优化锁资源，就需要你了解更多的操作系统知识、Java 多线程编程基础，积累项目经验，并结合实际场景去处理相关问题。
这样，便可得到如下指标衡量系统性能。
3.1 响应时间
响应时间是衡量系统性能的重要指标之一，响应时间越短，性能越好，一般一个接口的响应时间是在毫秒级。在系统中，我们可以把响应时间自下而上细分为以下几种：
- 数据库响应时间：数据库操作所消耗的时间，往往是整个请求链中最耗时的；
- 服务端响应时间：服务端包括 Nginx 分发的请求所消耗的时间以及服务端程序执行所消耗的时间；
- 网络响应时间：这是网络传输时，网络硬件需要对传输的请求进行解析等操作所消耗的时间；
- 客户端响应时间：对于普通的 Web、App 客户端来说，消耗时间是可以忽略不计的，但如果你的客户端嵌入了大量的逻辑处理，消耗的时间就有可能变长，从而成为系统的瓶颈。
3.2 吞吐量
在测试中，我们往往会比较注重系统接口的 TPS（每秒事务处理量），因为 TPS 体现了接口的性能，TPS 越大，性能越好。在系统中，我们也可以把吞吐量自下而上地分为两种：磁盘吞吐量和网络吞吐量。
我们先来看磁盘吞吐量，磁盘性能有两个关键衡量指标。
一种是 IOPS（Input/Output Per Second），即每秒的输入输出量（或读写次数），这种是指单位时间内系统能处理的 I/O 请求数量，I/O 请求通常为读或写数据操作请求，关注的是随机读写性能。适应于随机读写频繁的应用，如小文件存储（图片）、OLTP 数据库、邮件服务器。
另一种是数据吞吐量，这种是指单位时间内可以成功传输的数据量。对于大量顺序读写频繁的应用，传输大量连续数据，例如，电视台的视频编辑、视频点播 VOD（Video On Demand），数据吞吐量则是关键衡量指标。
接下来看网络吞吐量，这个是指网络传输时没有帧丢失的情况下，设备能够接受的最大数据速率。网络吞吐量不仅仅跟带宽有关系，还跟 CPU 的处理能力、网卡、防火墙、外部接口以及 I/O 等紧密关联。而吞吐量的大小主要由网卡的处理能力、内部程序算法以及带宽大小决定。
3.3 计算机资源分配使用率
通常由 CPU 占用率、内存使用率、磁盘 I/O、网络 I/O 来表示资源使用率。这几个参数好比一个木桶，如果其中任何一块木板出现短板，任何一项分配不合理，对整个系统性能的影响都是毁灭性的。
3.4 负载承受能力
当系统压力上升时，你可以观察，系统响应时间的上升曲线是否平缓。这项指标能直观地反馈给你，系统所能承受的负载压力极限。例如，当你对系统进行压测时，系统的响应时间会随着系统并发数的增加而延长，直到系统无法处理这么多请求，抛出大量错误时，就到了极限。
4 总结
性能调优可使系统稳定，用户体验更佳，甚至在较大系统，还能帮公司节约资源。
但项目初期，没必要过早介入性能优化，只需编码时保证其优秀、高效及良好程序设计。
完成项目后，就可系统测试，可将以下性能指标，作为性能调优的标准：响应时间、吞吐量、计算机资源分配使用率、负载承受能力。
电商系统、支付系统及游戏充值计费系统，都是千万级用户，且要承受各种大型抢购活动，所以我对系统性能要求苛刻。
大家还可将迭代之前版本的系统性能指标作为参考标准，通过自动化性能测试，校验迭代发版之后的系统性能是否出现异常，这里就不仅仅是比较吞吐量、响应时间、负载能力等直接指标了，还需要比较系统资源的 CPU 占用率、内存使用率、磁盘 I/O、网络 I/O 等几项间接指标的变化。
其它性能指标
除本文常见性能参考指标，还有啥可衡量系统性能的指标？
1. 错误率（Error Rate）
- 含义：指系统请求中出现错误的比例。通常用百分比表示。
- 应用：错误率过高可能暗示系统存在严重问题，如代码逻辑错误、资源配置不足或外部服务不可用。
- 示例：HTTP 状态码 5xx、数据库超时错误等。
2. 并发用户数（Concurrent Users）
- 含义：在同一时间内，使用系统的用户数量。
- 应用：并发用户数越多，对系统的压力越大。需要结合响应时间和吞吐量综合分析系统性能。
- 示例：电商大促期间同时下单的用户数。
3. 延迟（Latency）
- 含义：指网络请求从发出到收到响应的总时间，包括客户端到服务器、服务器到客户端的时间。
- 应用：延迟直接影响用户体验，尤其是实时性要求较高的应用，如直播、游戏等。
- 示例：在游戏中，玩家的动作延迟超过 100ms，体验可能大幅下降。
4. 队列长度（Queue Length）
- 含义：指等待处理的请求数量。
- 应用：队列过长通常意味着系统的处理能力不足，可能需要扩容或优化。
- 示例：高并发情况下，消息队列中未处理的任务数。
5. 连接数（Connections）
- 含义：指系统当前保持的 TCP/IP 连接数。
- 应用：对于高并发系统，连接数的管理尤为关键，过多的连接可能导致系统资源耗尽。
- 示例：WebSocket 长连接数量。
6. 垃圾回收（GC）频率与时间
- 含义：JVM 管理内存时，垃圾回收操作会暂停其他线程，影响系统性能。
- 应用：高频或长时间的垃圾回收可能导致系统响应时间变长。
- 示例：Full GC 导致服务响应时间超过 1 秒。
7. 事务完成率（Transaction Completion Rate）
- 含义：在一定时间内成功完成的事务比例。
- 应用：衡量系统处理请求的成功率和稳定性。
- 示例：支付系统中，完成支付的交易占总交易数的百分比。
8. 线程池状态
- 含义：包括活跃线程数、队列任务数和线程池容量。
- 应用：线程池配置不当可能导致任务堆积或线程资源浪费。
- 示例：线程池满时，新任务无法执行。
9. 系统高峰负载情况（Peak Load Handling）
- 含义：系统在短时间内处理突发高负载的能力。
- 应用：用于评估系统弹性和扩展能力。
- 示例：秒杀活动瞬间访问量暴增时系统的表现。
10. 可用性（Availability）
- 含义：系统在规定时间内能够正常提供服务的时间占比。
- 应用：高可用性是系统稳定性的重要体现。
- 示例：全年系统可用性达到 99.99%（每年允许停机 52 分钟以内）。
11. 冷启动时间（Cold Start Time）
- 含义：系统从启动到完全提供服务所需的时间。
- 应用：对于容器化或 Serverless 系统，冷启动时间是关键性能指标。
- 示例：某云函数冷启动时间为 300ms。
12. 服务级别目标（SLO）达成率
- 含义：实际服务性能达到预定义服务目标（如响应时间、可用性等）的比例。
- 应用：SLO 达成率直接影响服务的用户满意度。
- 示例：API 响应时间低于 200ms 的请求比例为 98%。
本文已收录在Github，关注我，紧跟本系列专栏文章，咱们下篇再续！
作者简介：魔都架构师，多家大厂后端一线研发经验，在分布式系统设计、数据平台架构和AI应用开发等领域都有丰富实践经验。
各大技术社区头部专家博主。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。
负责：
- 中央/分销预订系统性能优化
- 活动&券等营销中台建设
- 交易平台及数据中台等架构和开发设计
- 车联网核心平台-物联网连接平台、大数据平台架构设计及优化
- LLM Agent应用开发
- 区块链应用开发
- 大数据开发挖掘经验
- 推荐系统项目
目前主攻市级软件项目设计、构建服务全社会的应用系统。
参考：
标签：指南,超全,示例,性能,系统,响应,调优,时间 From： https://www.cnblogs.com/JavaEdge/p/18646146本文由博客一文多发平台 OpenWrite 发布！