1. 性能分析基础:什么是性能分析、性能指标、性能分析工具概览

大家好,我是你们的老朋友。今天咱们正式开讲《性能分析与代码优化技巧》的第一章。

说实话,性能分析这件事,我做了十几年。刚入行那会儿,我也觉得代码能跑就行,管它快不快呢?直到有一次线上事故——用户量一上来,系统直接挂了,老板拍桌子问我怎么回事。我查了三天三夜,最后发现就是一个循环里多了一次无意义的数据库查询。嗯,从那以后,我再也不敢忽视性能了。

1.1 什么是性能分析?

性能分析,说白了就是回答三个问题:

  • 你的系统跑得快吗?
  • 它还能跑得更快吗?
  • 瓶颈到底在哪?

我个人习惯把性能分析比作「体检」。你想想看,人每年都要体检,查查血压、血糖、心率。系统也一样,需要定期检查它的「健康指标」。只不过系统的指标是响应时间、吞吐量、资源利用率这些。

为什么要做性能分析?我遇到过太多团队,上线前不做压测,结果一上线就崩。性能分析不是锦上添花,而是保命手段。它能帮你:

  • 提前发现瓶颈,避免线上事故
  • 合理规划资源,别花冤枉钱买服务器
  • 提升用户体验,用户可没耐心等3秒

核心观点:性能分析不是一次性的工作,而是贯穿整个开发周期的持续活动。从设计阶段就要考虑,到编码、测试、上线、运维,每一步都不能落下。

1.2 三大核心性能指标

聊性能指标,我一般只看三个维度。多了记不住,少了不够用。咱们一个一个说。

1.2.1 响应时间

响应时间就是用户发出请求到收到响应的时间。你打开一个网页,等了2秒才显示出来,这2秒就是响应时间。

这里有个坑,我踩过。很多人只看平均响应时间,觉得平均100ms挺好啊。但平均会骗人。你想想看,如果90%的请求都是10ms,剩下10%是1秒,平均下来才109ms,看起来不错。但实际体验呢?那10%的用户已经骂娘了。

我建议你看百分位数:

  • P50(中位数):一半请求比这个快,一半比这个慢
  • P95:95%的请求比这个快,重点关注
  • P99:99%的请求比这个快,这是你的「最差体验」

我的经验:线上监控重点关注P99。如果P99超过1秒,说明有少量请求严重拖慢了整体体验。这时候别急着优化平均,先查那1%的慢请求是怎么回事。

1.2.2 吞吐量

吞吐量是单位时间内系统能处理的请求数量。常见的单位有:

  • QPS:每秒查询数,常用于数据库、API接口
  • TPS:每秒事务数,常用于交易系统
  • RPS:每秒请求数,更通用的说法

吞吐量和响应时间是什么关系?很多人以为它们是一回事。其实不是。我举个例子:

你开了一家奶茶店。响应时间就是顾客从下单到拿到奶茶的时间。吞吐量就是每小时能卖多少杯。这两个指标互相影响——顾客多了,排队时间就长,响应时间就上升。但你不能说「我只要响应时间快,不管卖多少杯」,那生意还做不做了?

所以,性能优化的目标往往是:在保证响应时间可接受的前提下,尽可能提升吞吐量。

1.2.3 资源利用率

资源利用率就是CPU、内存、磁盘、网络这些硬件被用了多少。我见过最离谱的事:某团队买了128核的服务器,结果代码是单线程的,CPU利用率只有1%。这不是浪费钱吗?

常见的资源瓶颈:

资源 正常范围 危险信号 常见原因
CPU 40%-70% >90% 持续 死循环、密集计算、GC频繁
内存 60%-80% >90% 或频繁Swap 内存泄漏、大对象、缓存过大
磁盘I/O 利用率 < 60% 等待时间 > 10ms 日志过多、数据库慢查询
网络 带宽 < 40% 丢包率 > 1% 带宽不足、连接数过多

注意:资源利用率不是越低越好。CPU长期低于10%,说明你的机器买贵了,资源在闲置。理想状态是资源利用率稳定在60%-80%,留出余量应对突发流量。

1.3 性能分析工具概览

工具这东西,贵精不贵多。我这些年用下来,真正好用的就那几个。咱们按场景分分类:

1.3.1 系统级工具

  • top / htop:看CPU、内存、进程,Linux必备。我每天上班第一件事就是跑一下top,看看有没有异常进程。
  • vmstat:看系统整体状态,包括CPU、内存、I/O、上下文切换。排查性能问题时,我第一个用它。
  • iostat:专门看磁盘I/O。有一次我发现磁盘利用率不高但响应很慢,一查是磁盘队列太深,iostat直接告诉我了。
  • netstat / ss:看网络连接状态。排查端口占用、连接数过多时很有用。

1.3.2 应用级工具

  • JProfiler / YourKit:Java应用性能分析,能看CPU热点、内存分配、线程状态。我习惯用它们定位代码级别的瓶颈。
  • gprof / perf:C/C++应用的性能分析工具。perf是Linux内核自带的,功能强大,但学习曲线陡。
  • Chrome DevTools:前端性能分析,看网络请求、渲染性能、JS执行时间。做Web优化的同学一定要会用。

1.3.3 数据库级工具

  • EXPLAIN:分析SQL执行计划。我见过90%的慢查询都是没加索引,EXPLAIN一眼就能看出来。
  • 慢查询日志:记录执行时间超过阈值的SQL。线上开启后,定期分析,能发现很多隐藏问题。
  • Redis MONITOR:实时查看Redis命令。排查缓存穿透、热点key时很有用。

1.3.4 全链路监控工具

  • Prometheus + Grafana:监控和可视化。我习惯把CPU、内存、QPS、响应时间都画在同一个仪表盘上,一眼就能看出问题。
  • SkyWalking / Zipkin:分布式链路追踪。微服务架构下,一个请求经过十几个服务,没有链路追踪你根本不知道慢在哪。
  • ELK(Elasticsearch + Logstash + Kibana):日志分析。把错误日志、慢日志集中起来,搜索分析很方便。

我的建议:别一上来就上高大上的工具。先学会用top、vmstat、EXPLAIN这三个,能解决80%的性能问题。工具是辅助,思路才是核心。

1.4 本章知识体系

说了这么多,咱们用一张图把本章的核心内容串起来。这张图是我自己画的,你看完应该能对性能分析有个整体认识。

性能分析知识体系 性能分析 什么是性能分析 三大性能指标 工具概览 回答三个问题:快不快?能不能更快?瓶颈在哪? 类比:系统体检,定期检查健康指标 响应时间:P50/P95/P99 吞吐量:QPS/TPS/RPS 资源利用率:CPU/内存/磁盘/网络 系统级:top/vmstat/iostat 应用级:JProfiler/perf/DevTools 数据库级:EXPLAIN/慢查询日志 全链路:Prometheus/SkyWalking 核心思路:先定位瓶颈,再针对性优化

这张图把本章内容分成了三块:什么是性能分析、三大性能指标、工具概览。你看,其实没那么复杂。核心思路就是先定位瓶颈,再针对性优化。别一上来就瞎优化,那是浪费时间。

好了,第一章就到这里。内容不多,但都是干货。你先把这些基础概念吃透,后面咱们再深入讲具体的分析方法和优化技巧。

可可精品资料库