软件系统的性能指标

• 一、软件性能的概念与关注点
• • 1.概念及关注点
  • 2.软件性能模型
• 二、不同视角下的软件性能
• • 1.终端用户视角
  • 2.测试人员视角
  • 3.开发人员视角
• 三、衡量软件性能的常用指标
• • 1.响应时间
  • 2.并发用户数
  • 3.吞吐量
• 总结

一、软件性能的概念与关注点

1.概念及关注点

一般来说，性能是一种指标，是与软件功能相对应的一种非常重要的非功能特性，表征了软件系统对时间、及时性、资源经济性的要求。
常用的性能指标包括：响应时间，并发用户数，吞吐量等

2.软件性能模型

这里用一张图来描述软件性能模型

二、不同视角下的软件性能

1.终端用户视角

从用户的角度来看，软件性能非常直观的特性就是系统对用户的操作的响应时间。
比如当用户单击一个按钮、发出一条执行或者在网页上单击一个链接，从用户单击开始到应用系统把本次操作的结果以用户能够觉察到的方式展示出来，这个整个过程所消耗的时间就是用户对软件性能的直观印象。常用的系统交互过程中，响应时间还可以细分为：

服务器端响应时间
这个时间指的是服务器完成交易请求的时间，不包括客户端到服务器的反应，这个服务器端响应时间可以度量服务器的处理能力；

网络响应时间
这是网络硬件传输交易请求和交易结束所耗费的时间；

客户端响应时间
这是客户端在构建请求和展现交易结果所耗费的时间；

2.测试人员视角

从测试人员的角度来看，软件系统的性能首先表现在系统的响应时间上，这一个和用户没有区别，但是测试人员在此关注点之外，还会关心系统状态的相关程度，比如

• 某个业务响应时系统状态如使用状况合理么？
• 应用服务器和数据库的资源使用状况合理么？
• 系统是否能够实现扩展？
• 系统最多能支持多少用户的访问？
• 系统最大的业务处理量是多少？
• 系统可能的瓶颈在哪里？
• 更换哪些设备能提高系统性能？
• 系统能够支持全时段的业务处理？

3.开发人员视角

算法设计，架构设计，数据库，性能**时间等。作为软件开发人员，更多的主力已应该是如何提升系统的性能瓶颈。
作为软件开发人员，面对性能，更要关注性能的优化方法。软件性能的优化方法有很多，但是不意味着所有的优化方法在每个场景都可用的。

可以分为宏观和微观两个层次：宏观主要是基础设施以及工程化的优化，这个层面是不会对实现做很大的变动的；而微观则是对具体的编码进行调整，内部调整可能会非常大。

宏观层面：

• 升级基础设施，硬件升级，操作系统升级，编程语言升级，编译器升级
• 架构设计
• 结构和流程设计

微观层面：

• 变量
• 内存管理
• 多线程和并发
• 面向对象
• 数据结构和算法
• IO和系统调用
• 编译

具体到对应的日常工作中，经常会接触到的场景通常会涉及到的有：

• 虚拟机内存优化
• 应用服务器性能优化
• 数据库性能优化

三、衡量软件性能的常用指标

1.响应时间

响应时间是指系统对请求响应的时间，这个指标与人对软件性能的主管感受是非常一致的，因为它完整的记录了整个计算机系统的处理请求的时间。由于一个系统通常会提供许多功能，不同的功能处理逻辑也有千差万别，因而不同功能的响应时间也不尽相同，设置同一功能在不同输入数据的情况下响应设计也不相同。
所以，在探讨一个系统的响应时，人们通常是指该系统所有功能的平均响应时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应设计和最大响应时间。
响应时间的绝对值并不能直接反应软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间。

2.并发用户数

业务层面的并发用户数，后端服务器层面的并发用户数。
这里要区分一些概念，系统用户数和同事在线人数。同时针对平均并发用户数和并发用户峰值的区别。
并发数计算
假设有一个OA系统，该系统有3000个用户，平均每天大约有400个用户需要访问系统，对一个典型用户来说，一天之内用户从登陆到退出该系统的平均时间为4个小时，在一天的时间内，用户只在9小时内使用系统。
C=4004/8 = 200平均
C1=200+3sqr(200)=242峰值

3.吞吐量

吐量是指系统在单位时间内内处理请求的数量。对于无并发的应用系统而言，吞吐量与相应时间构成严格的反比关系，实际上此时吞吐量就是相应时间的倒数。系统负载承受能力的指标，需要和其他指标一起使用才能更好的说明问题。

一个系统的吞吐量（承压能力）与request对CPU的消耗、外部接口、IO等紧密关联。
单个request对CPU消耗越高，外部系统接口，IO影响速度越慢，系统的吞吐能力越低，反之越高。
吞吐量的几个重要参数：QPS（TPS）、并发数、响应时间
QPS（TPS）：每秒钟request/事务 数量
并发数：系统同时处理的request/事务数
响应时间：一般取平均响应时间
一个系统的吞吐量通常由QPS（TPS）、并发数另个因素觉得，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了。如果压力继续增大，系统的吞吐量反而会下降，原有是系统超负荷工作，上下文切换、内存等等其他消耗导致系统性能下降。

决定系统响应时间要素
我们做项目要排计划，可以多人同时并发做多项任务，也可以一个人或者多个人串行工作，始终会有一条关键路径、这条关键路径就是项目工期。
系统一次调用的响应时间跟项目机会一样，也有一条关键路径，这个关键路径就是系统的响应时间。关键路径是有CPI运算，IO、外部系统响应等组成。

系统吞吐量评估：
我们在做系统设计的时候就需要考虑CPU运算，IO，外部系统响应因素造成的影响以及对系统性能的初步预估。

总结

本文从软件性能指标关注点出发，介绍了不同视角下的对软件性能的理解以及常用衡量指标。对于一个项目而言，性能指标作为软件非功能性需求的重要组成部分，其关注程度越来越重要。以至于在一些场景下，成为优秀软件项目的关键因素，更应该值得我们去关注研究。