对于不同类型的系统，软件性能的关注点各不相同，比如：

• Web 类应用和手机端应用，一般以终端用户感受到的端到端的响应时间来描述系统的性能；
• 非交互式的应用，比如典型的电信和银行后台处理系统，响应时间关注更多的是事件处理的速度，以及单位时间的事件吞吐量。

从开发人员视角关注软件性能

在软件设计开发人员眼中，软件性能通常会包含算法设计、架构设计、性能最佳实践、数据库相关、软件性能的可测试性这五大方面。其中，每个方面关注的点，也包括很多。

第一，算法设计包含的点：
核心算法的设计与实现是否高效；
必要时，设计上是否采用 buffer 机制以提高性能，降低 I/O；
是否存在潜在的内存泄露；
是否存在并发环境下的线程安全问题；
是否存在不合理的线程同步方式；
是否存在不合理的资源竞争。

第二，架构设计包含的内容：
站在整体系统的角度，是否可以方便地进行系统容量和性能扩展；
应用集群的可扩展性是否经过测试和验证；
缓存集群的可扩展性是否经过测试和验证；
数据库的可扩展性是否经过测试和验证。

第三，性能最佳实践包含的点：
代码实现是否遵守开发语言的性能最佳实践；
关键代码是否在白盒级别进行性能测试；
是否考虑前端性能的优化；
必要的时候是否采用数据压缩传输；
对于既要压缩又要加密的场景，是否采用先压缩后加密的顺序。

第四，数据库相关的点：
数据库表设计是否高效；
是否引入必要的索引；
SQL 语句的执行计划是否合理；
SQL 语句除了功能是否要考虑性能要求；
数据库是否需要引入读写分离机制；
系统冷启动后，缓存大量不命中的时候，数据库承载的压力是否超负荷。

第五，软件性能的可测试性包含的点：
是否为性能分析（Profiler）提供必要的接口支持；
是否支持高并发场景下的性能打点；
是否支持全链路的性能分析。

性能测试常用衡量指标

并发用户数

• 业务层面的并发用户数，指的是实际使用系统的用户总数。但是单靠这个指标并不能反映系统实际承载的压力，我们还要结合用户行为模型才能得到系统实际承载的压力。
• 后端服务器层面的并发用户数，指的是“同时向服务器发送请求的数量”，直接反映了系统实际承载的压力。

场景举例：
一个已经投入运行的 ERP 系统，该系统所在企业共有 5000 名员工并都拥有账号，也就是说这个系统有 5000 个潜在用户。根据系统日志分析得知，该系统最大在线用户数是 2500 人。

业务层面的并发用户数=2500人 （此数值仅仅表明在最高峰时段有 2500 个用户登录了系统，而服务器所承受的实际压力取决于登录用户行为，所以它不能准确反映服务器此时此刻实际承载的压力）

用户行为分析建模：
假设在某一时间点上，这 2500 个用户中，30% 用户处于页面浏览状态（对服务器没有发起请求），20% 用户在填写订单（也没有对服务器发起请求），5% 用户在递交订单，15% 用户在查询订单，而另外的 30% 用户没有进行任何操作。

后端服务器层面的并发用户数=500人（这 2500 个“并发用户”中真正对服务器产生压力的只有 500 个用户（（5%+15%）*2500=500））。

从这个例子可以看出，后端服务器层面的并发用户数，同时取决于业务层面并发用户数和用户行为模式，而且用户行为模式占的比重较大。因此，分析得到准确的用户行为模式，是性能测试中的关键一环。获得精准的用户行为模式，是除了获取性能需求外，最困难的工作。

响应时间 RT

RT：处理一次请求所需要的平均处理时间
响应时间是终端用户对系统性能的最直观印象，包括系统响应时间和前端展现时间

• 系统响应时间又可以进一步细分为后台系统处理时间、数据库处理时间和网络传输时间等；
• 前端展现时间，取决于客户端收到服务器返回的数据后渲染页面所消耗的时间

系统吞吐率 TPS

TPS：每秒钟处理完的事务次数，即吞吐率；一般TPS是对整个系统来讲的。一个应用系统1s能完成多少事务处理，一个事务在分布式处理中，可能会对应多个请求，对于衡量单个接口服务的处理能力，用QPS比较多

QPS

QPS: 服务器一秒钟处理完请求的数量；注意这里是处理完。具体是指发出请求到服务器处理完成功返回结果。可以理解在server中有个counter，每处理一个请求加1，1秒后 counter=QPS
计算公式：QPS = 并发用户数 / 平均响应时间

举个列子：
如果一次性可以处理100个请求并发量，每个请求耗时100毫秒，则qps = 1000
如果一次性可以处理50个请求并发量，每个请求耗时200毫秒，则qps = 250
所以QPS与单个请求处理时间以及服务器一次性可以处理多少请求是成比例关系的

部分内容参考极客时间: https://time.geekbang.org/column/article/14577#previewimg