软件性能与性能指标
标签（空格分隔）：软件性能与性能指标
当我们说道性能的时候到底是说的什么？
⽬前，对软件性能最普遍的理解就是软件处理的及时性。但其实，从不同的系统类型，以及不同的视⾓去讨论软件性能，都会有所区别。
对于不同类型的系统，软件性能的关注点各不相同，⽐如：
Web 类应⽤和⼿机端应⽤，⼀般以终端⽤户感受到的端到端的响应时间来描述系统的性能；
⾮交互式的应⽤，⽐如典型的电信和银⾏后台处理系统，响应时间关注更多的是事件处理的速度，以及单位时间的事件吞吐量。
这很容易理解。同样地，对同⼀个系统来说，不同的对象体对软件性能的关注点和期望也不完全相同，甚⾄很多时候是对⽴的。这⾥，不同的对象体可以分为四⼤类：终端⽤户、系统运维⼈员、软件设计开发⼈员和性能测试⼈员。
终端⽤户是软件系统的最终使⽤者，他们对软件性能的反馈直接决定了这个系统的应⽤前景；⽽，软件开发⼈员、运维⼈员、性能测试⼈员，对性能测试的关注点则直接决定了⼀个系统交付到⽤户⼿中的性能。
只有全⾯了解各类体对软件系统的不同需求，才能保证这个系统具有真正⾼可靠的性能。所以，接下来我会从这四类⼈的视⾓和维度了解性能；
终端⽤户眼中的软件性能
从终端⽤户（也就是软件系统使⽤者）的维度来讲，软件性能表现为⽤户进⾏业务操作时的主观响应时间。具体来讲就是，从⽤户在界⾯上完成⼀个操作开始，到系统把本次操作的结果以⽤户能察觉的⽅式展现出来的全部时间。对终端⽤户来说，这个时间越短体验越好。
这个响应时间是终端⽤户对系统性能的最直观印象，包括了系统响应时间和前端展现时间。
系统响应时间，反应的是系统能⼒，⼜可以进⼀步细分为应⽤系统处理时间、数据库处理时间和⽹络传输时间等；
前端展现时间，取决于⽤户端的处理能⼒。
从这个⾓度来看，你就可以⾮常容易理解性能测试为什么会分为后端（服务器端）的性能测试和前端（通常是浏览器端）的性能测试了。
系统运维⼈员眼中的软件性能
从软件系统运维（也就是系统运维⼈员）的⾓度，软件性能除了包括单个⽤户的响应时间外，更要关注⼤量⽤户并发访问时的负载，以及可能的
更⼤负载情况下的系统健康状态、并发处理能⼒、当前部署的系统容量、可能的系统瓶颈、系统配置层⾯的调优、数据库的调优，以及长时间运
⾏稳定性和可扩展性。
⼤多数情况下，系统运维⼈员和终端⽤户是站在同⼀条战线上的，希望系统的响应速度尽可能地快。但，某些情况下他们的意见是对⽴的，最常
见的情况就是，系统运维⼈员必须在最⼤并发⽤户数和系统响应时间之间进⾏权衡取舍。⽐如，当有两套系统配置⽅案可以提供以下系统能⼒的
时：
配置⽅案 A 可以提供 100 万并发访问⽤户的能⼒，此时⽤户的登录响应时间是 3 秒
配置⽅案 B 可以提供 500 万并发访问⽤户的能⼒，此时⽤户的登录响应时间是 8 秒。
⽬前，有些系统为了能够承载更多的并发⽤户，往往会牺牲等待时间⽽引⼊预期的等待机制。⽐如，⽕车票购票⽹站，就在处理极⼤并发⽤户时
采⽤了排队机制，以尽可能提⾼系统容量，但却增加了⽤户实际感受到的响应时间。
软件设计开发⼈员眼中的软件性能
从软件系统开发（也就是软件设计开发⼈员）的⾓度来讲，软件性能关注的是性能相关的设计和实现细节，这⼏乎涵盖了软件设计和开发的全过程。
在软件设计开发⼈员眼中，软件性能通常会包含算法设计、架构设计、性能最佳实践、数据库相关、软件性能的可测试性这五⼤⽅⾯。其中，每个⽅⾯关注的点，也包括很多。
第⼀，算法设计包含的点：
核⼼算法的设计与实现是否⾼效；
必要时，设计上是否采⽤buffer机制以提⾼性能，降低I/O；
是否存在潜在的内存泄露；
是否存在并发环境下的线程安全问题；
是否存在不合理的线程同步⽅式；
是否存在不合理的资源竞争。
第⼆，架构设计包含的内容：
站在整体系统的⾓度，是否可以⽅便地进⾏系统容量和性能扩展；
应⽤集的可扩展性是否经过测试和验证；
缓存集的可扩展性是否经过测试和验证；
前端测试和后端测试的区别
数据库的可扩展性是否经过测试和验证。
第三，性能最佳实践包含的点：
代码实现是否遵守开发语⾔的性能最佳实践；
关键代码是否在⽩盒级别进⾏性能测试；
是否考虑前端性能的优化；
必要的时候是否采⽤数据压缩传输；
对于既要压缩⼜要加密的场景，是否采⽤先压缩后加密的顺序。
第四，数据库相关的点：
数据库表设计是否⾼效；
是否引⼊必要的索引；
SQL 语句的执⾏计划是否合理；
SQL 语句除了功能是否要考虑性能要求；
数据库是否需要引⼊读写分离机制；
系统冷启动后，缓存⼤量不命中的时候，数据库承载的压⼒是否超负荷。
第五，软件性能的可测试性包含的点：
是否为性能分析（Profiler）提供必要的接⼝⽀持；
是否⽀持⾼并发场景下的性能打点；
否⽀持全链路的性能分析。
需要注意的是，软件开发⼈员⼀般不会关注系统部署级别的性能，⽐如软件运⾏⽬标操作系统的调优、应⽤服务器的参数调优、数据库的参数调
优、⽹络环境的调优等。
系统部署级别的性能测试，⽬前⼀般是在系统性能测试阶段或者系统容量规划阶段，由性能测试⼈员、系统架构师，以及数据库管理员（DBA）
协作完成。
性能测试⼈员眼中的软件性能
从性能⼯程的⾓度看，性能测试⼯程师关注的是算法设计、架构设计、性能最佳实践、数据库相关、软件性能的可测试性这五⼤⽅⾯。
在系统架构师、DBA，以及开发⼈员的协助下，性能测试⼈员既要能够准确把握软件的性能需求，⼜要能够准确定位引起“不好”性能表现的制约因素和根源，并提出相应的解决⽅案。
⼀个优秀的性能测试⼯程师，⼀般需要具有以下技能：
1.性能需求的总结和抽象能⼒；
2.根据性能测试⽬标，精准的性能测试场景设计和计算能⼒；
3.性能测试场景和性能测试脚本的开发和执⾏能⼒；
4.测试性能报告的分析解读能⼒；
5.性能瓶颈的快速排查和定位能⼒；
6.性能测试数据的设计和实现能⼒；
7.⾯对互联⽹产品，全链路压测的设计与执⾏能⼒，能够和系统架构师⼀起处理流量标记、影⼦数据库等的技术设计能⼒；
8.深⼊理解性能测试⼯具的内部实现原理，当性能测试⼯具有限制时，可以进⾏扩展⼆次开发；
9.极其宽⼴的知识⾯，既要有“⾯”的知识，⽐如系统架构、存储架构、⽹络架构等全局的知识，还要有⼤量“点”的知识积累，⽐如数据库 SQL 语句
的执⾏计划调优、JVM 垃圾回收（GC）机制、多线程常见问题等等。
现在，我再来和你说说衡量软件性能的三个最常⽤的指标：
并发⽤户数、
响应时间，
以及系统吞吐量。
只要你接触过性能测试，或者你的团队开展过性能测试，你都应该听说这三个指标。但其实很多⼈对它
们的理解还都停留在表⾯，并没有深⼊细
致地考虑过其本质与内涵，这也导致了性能测试很多时候并没有发挥应有的作⽤。
并发⽤户数
并发⽤户数，是性能需求与测试最常⽤，也是最重要的指标之⼀。它包含了业务层⾯和后端服务器层⾯的两层含义。
业务层⾯的并发⽤户数，指的是实际使⽤系统的⽤户总数。但是，单靠这个指标并不能反映系统实际承载的压⼒，我们还要结合⽤户⾏为模型才
能得到系统实际承载的压⼒。
后端服务器层⾯的并发⽤户数，指的是“同时向服务器发送请求的数量”，直接反映了系统实际承载的压⼒。
为了让你更好地理解这两层含义之间的区别，我们先⼀起来看⼀个实例：⼀个已经投⼊运⾏的 ERP 系统，该系统所在企业共有 5000 名员⼯并都拥有账号，也就是说这个系统有 5000 个潜在⽤户。
根据系统⽇志分析得知，该系统最⼤在线⽤户数是 2500 ⼈，那么从宏观⾓度来看，2500 就是这个系统的最⼤并发⽤户数。但是，2500 这个数据仅仅是说在最⾼峰时段有 2500 个⽤户登录了系统，⽽服务器所承受的压⼒取决于登录⽤户的⾏为，所以它并不能准确表现服务器此时此刻正在承受的压⼒。
假设在某⼀时间点上，这 2500 个⽤户中，30% ⽤户处于页⾯浏览状态（对服务器没有发起请求），20% ⽤户在填写订单（也没有对服务器发起请求），5% ⽤户在递交订单，15% ⽤户在查询订单，⽽另外的 30% ⽤户没有进⾏任何操作。那么此时，这 2500 个“并发⽤户”中真正对服务器产⽣压⼒的只有 500 个⽤户
（（5%+15%）*2500=500）
在这个例⼦中，5000 是最⼤的“系统潜在⽤户数”，2500 是最⼤的“业务并发⽤户数”，500 则是某个时间点上的“实际并发⽤户数”。⽽此时这 500 个⽤户同时执⾏业务操作所实际触发的服务器端的所有调⽤，叫作“服务器并发请求数”。
从这个例⼦可以看出，在系统运⾏期间的某个时间点上，有⼀个指标叫作“同时向服务器发送请求的数量”，这个“同时向服务器发送请求的数量”就是服务器层⾯的并发⽤户数，这个指标同时取决于业务并发⽤户数和⽤户⾏为模式，⽽且⽤户⾏为模式占的⽐重较⼤。
因此，分析得到准确的⽤户⾏为模式，是性能测试中的关键⼀环。但，获得精准的⽤户⾏为模式，是除了获取性能需求外，最困难的⼯作。
⽬前，获取⽤户⾏为模式的⽅法，主要分为两种：
1.对于已经上线的系统来说，往往采⽤系统⽇志分析法获取⽤户⾏为统计和峰值并发量等重要信息；
2.⽽对于未上线的全新系统来说，通常的做法是参考⾏业中类似系统的统计信息来建模，然后分析。
响应时间
通俗来讲，响应时间反映了完成某个操作所需要的时间，其标准定义是“应⽤系统从请求发出开始，到客户端接收到最后⼀个字节数据所消耗的时间”，是⽤户视⾓软件性能的主要体现。
响应时间，分为前端展现时间和系统响应时间两部分。其中，前端时间，⼜称呈现时间，取决于客户端收到服务器返回的数据后渲染页⾯所消耗
的时间；⽽系统响应时间，⼜可以进⼀步划分为 Web 服务器时间、应⽤服务器时间、数据库时间，以及各服务器间通信的⽹络时间。
除⾮是针对前端的性能测试与调优，软件的性能测试⼀般更关注服务器端。但是，服务器端响应时间的概念⾮常清晰、直接，就是指从发出请求
起到处理完成的时间，没有⼆义性；⽽前端时间的定义，在我看来存在些歧义。所以，接下来我会和你详细聊聊前端时间这个话题。
虽然前端时间⼀定程度上取决于客户端的处理能⼒，但是前端开发⼈员现在还会使⽤⼀些编程技巧在数据尚未完全接收完成时呈现数据，以减少
⽤户实际感受到的主观响应时间。也就是说，我们现在会普遍采⽤提前渲染技术，使得⽤户实际感受到的响应时间通常要⼩于标准定义的响应时
间。
鉴于此，我认为响应时间的标准定义就不尽合理了，尤其是对于“接收到最后⼀个字节”。
我来举个实际案例吧。加载⼀个⽹页时，如果 10 秒后还是⽩屏，那你⼀定会感觉很慢、性能⽆法接受。但是，回想⼀下你曾经上新浪⽹的经历，当加载新浪⾸页时，你应该不会感觉速度很慢吧。其实，实际情况是，新浪⾸页的加载时间要远⼤于 10 秒，只是新浪采⽤了数据尚未完全接收完成时进⾏呈现的技术，⼤⼤缩短了⽤户主观感受到的时间，提升了⽤户体验。
所以，严格来讲，响应时间应该包含两层含义：技术层⾯的标准定义和基于⽤户主观感受时间的定义。⽽在性能测试过程中，我们应该使⽤哪个层⾯的含义将取决于性能测试的类型。显然，对于软件服务器端的性能测试肯定要采⽤标准定义，⽽对于前端性能评估，则应该采⽤⽤户主观感受时间的定义。
当然，我们在前端性能测试中，会利⽤⼀些事件的触发（⽐如 DOM-Load、Page-load 等）来客观地衡量“主观的前端性能”。
系统吞吐量
系统吞吐量，是最能直接体现软件系统负载承受能⼒的指标。
这⾥需要注意的是，所有对吞吐量的讨论都必须以“单位时间”作为基本前提。其实，我认为把“Throughput”翻译成吞吐率更贴切，因为我们可以这样理解：吞吐率 =吞吐量 / 单位时间。但既然国内很多资料已经翻译为了“吞吐量”，所以通常情况下我们不会刻意去区分吞吐量和吞吐率，统称为吞吐量。
性能测试⽽⾔，通常⽤“Requests/Second”“Pages/Second”“Bytes/Second”来衡量吞吐量。当然，从业务的⾓度来讲，吞吐量也可以⽤单位时间的
业务处理数量来衡量
以不同⽅式表达的吞吐量可以说明不同层次的问题。⽐如：
“Bytes/Second”和“Pages/Second”表⽰的吞吐量，主要受⽹络设置、服务器架构、应⽤服务器制约；
Requests/Second”表⽰的吞吐量，主要受应⽤服务器和应⽤本⾝实现的制约。
这⾥需要特别注意的是：虽说吞吐量可以反映服务器承受负载的情况，但在不同并发⽤户数的场景下，即使系统具有相近的吞吐量，但是得到的
系统性能瓶颈也会相差甚远。
⽐如，某个测试场景中采⽤ 100 个并发⽤户，每个⽤户每隔 1 秒发出⼀个 Request，另外⼀个测试场景采⽤ 1000 个并发⽤户，每个⽤户每隔 10
秒发出⼀个 Request。显然这两个场景具有相同的吞吐量, 都是 100 Requests/second，但是两种场景下的系统性能拐点肯定不同。因为，两个场
景所占⽤的资源是不同的。
这就要求性能测试场景的指标，必然不是单个，需要根据实际情况组合并发⽤户数、响应时间这两个指标。
总结
⾸先，我从终端⽤户、系统运维⼈员、软件设计开发⼈员和性能测试⼈员，这四个维度介绍了软件系统的性能到底指的是什么：
终端⽤户希望⾃⼰的业务操作越快越好；
系统运维⼈员追求系统整体的容量和稳定；
开发⼈员以“性能⼯程”的视⾓关注实现过程的性能；
性能测试⼈员需要全盘考量、各个击破。
然后，介绍了软件性能的三个最常⽤的指标：并发⽤户数，响应时间，系统吞吐量：
并发⽤户数包含不同层⾯的含义，既可以指实际的并发⽤户数，也可以指服务器端的并发数量
；响应时间也包含两层含义，技术层⾯的标准定义和基于⽤户主观感受时间的定义；
系统吞吐量是最能直接体现软件系统承受负载能⼒的指标，但也必须和其他指标⼀起使⽤才能更好地说明问题。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。