标签：style http io color os 使用 sp for 数据
交互式系统：以用户感受到的响应时间来描述系统的性能
非交互式系统（银行业务处理）：响应时间只系统对事件产生的响应所需要的时间
用户视角：对于用户，最终使用者而言评价系统的性能好坏只有一个字——“快“。最终用户并不需要关心系统当前的状态——即使系统这时正在处理着成千上万的请求，对于用户来说，由他所发出的这个请求是他唯一需要关心的，系统对用户请求的响应速度决定了用户对系统性能的评价。简单点就是，用户单击一个按钮，发出一条指令或是在web页面上单击一个连接考试，到应用系统把本次操作的结果以用户能察觉的方式展示出来的过程所消耗的时间就是用户对软件性能的直观印象。
系统的运营商和开发商：期望的是能够让尽可能多的用户在任意时刻都拥有最好的体验，这就要确保系统能够在同一时间内处理更多的用户请求。系统的负载（并发用户数）与吞吐量（每秒事务数）、响应时间以及资源利用率（包括软硬件资源）之间存在着一个“此消彼长”的关系。因此，从系统的运营商和开发商的角度来看，所谓的“性能”是一个整体的概念，是系统的负载与吞吐量、可接受的响应时间以及资源利用率之间的平衡。
好的系统意味着更大的最佳并发用户数和最大并发用户数。
另外，从系统的视角来看，所需要关注的还包括三个与“性能”有关的属性：可靠性（Reliability），可伸缩性（Scalability）和 可恢复性（Recoverability）
图中是一个请求的响应时间的组成，包括
C1：用户请求发出前在客户端需要完成的预处理所需要的时间；
C2：客户端收到服务器返回的响应后，对数据进行处理并呈现所需要的时间；
A1：Web/App Server 对请求进行处理所需要的时间；
A2：DB Server 对请求进行处理所需的时间；
A3：Web/App Server 对 DB Server 返回的结果进行处理所需的时间；
N1：请求由客户端发出并达到Web/App Server 所需要的时间；
N2：如果需要进行数据库相关的操作，由Web/App Server 将请求发送至DB Server 所需要的时间；
N3：DB Server 完成处理并将结果返回Web/App Server 所需的时间；
N4：Web/App Server 完成处理并将结果返回给客户端所需的时间；
从用户的角度来看，响应时间＝(C1+C2)+(A1+A2+A3)+(N1+N2+N3+N4)；但是从系统的角度来看，响应时间只包括(A1+A2+A3)+(N1+N2+N3+N4)。理解响应时间的组成可以帮助我们通过对响应时间的分析来更好的识别和定位系统的性能瓶颈。
从用户的角度看，所体会到的响应时间有主观和客观之分，客观来说就是上面提到的从用户操作开始到所有数据返回完成的整个耗时，主观上说如果采用一种优化的数据呈现策略，当少部分数据返回之后就立马将数据呈现在用户面前，则用户感受到的响应时间就会远远小于实际的实物响应时间。
对于一个web应用来说，响应时间的标准是2/5/10秒，而对于一个OA系统，每次可能只使用一次该系统，当点击提交时就算系统在20分钟后才响应，用户仍然不会觉得不能接受。所以合理的响应时间取决于实际的用户需求。
单位时间内系统处理的客户请求的数量。在web系统中主要以请求数（单击数）/秒、页面数/秒来体现。
1. 用户协助设计性能测试场景，以及衡量性能测试场景是否达到了预期的设计目标：在设计性能测试场景时，吞吐量可被用户协助设计性能测试场景，根据估算的吞吐量数据，可以对应到测试场景的事务发生频率，事务发生次数等；另外，在测试完成后，根据实际的吞吐量可以衡量测试是否达到了预期的目标。
2. 用于协助分析性能瓶颈：吞吐量的限制是性能瓶颈的一种重要表现形式，因此，有针对性地对吞吐量设计测试，可以协助尽快定位到性能冰晶所在位置。
?
简单说，当你在性能测试工具或者脚本中设置了100并发用户数后，并不能期望着一定会有每秒100个请求发给服务器。事实上，对于一个虚拟用户来说，每秒发出多少请求只跟服务器返回响应的速度有关。如果虚拟用户在0.5秒内就收到了响应，那么它会立即发出第二个请求；而如果要一直等待3秒才能得到响应，它将会一直等到收到响应后才发出第二个请求。也就是说，并发用户数的设置只是保证服务器在任一时刻都有100个请求需要处理，而并不一定是保证每秒中发送100个请求给服务器。
所以，只有当响应时间恰好是1秒时，并发用户数才会等于每秒请求数；否则，每秒请求数可能大于并发用户数或小于并发用户数。
并发用户数取决于具体的业务场景，它体现的时服务器端承受的最大并发访问数。
一个系统有2000用户（系统用户数），最高峰时有500人在线（同时在线人数），那么系统的并发用户数呢？
500是整个系统使用时最大的业务并发用户数，并不表示服务器实际承受的压力，这与具体的用户访问模式有关。例如这500人中，有40%在看公告，20%在填写表格（表格只有在点击提交时才会对服务器产生负担），20%在发呆，20%在切换页面，这种情况下只有20%的用户真正的对服务器构成了压力。
描述服务器或操作系统性能的一些数据指标，在performance test中发挥这监控和分析的关键作用。
验收性能测试（acceptance performance testing）
负载测试（load testing）
压力测试（stress testing）
配置测试（configuration testing）
并发测试（concurrency testing）
可靠性测试（reliability testing）
失败恢复测试（failure testing）
性能测试重要的一点在于对需求的理解，如果没有正确的理解需求，而充忙的去搭建环境，配置信息，最后得到的会是不正确的测试结果。而往往一些用户或者客户并不十分明确对性能的要求，他们只会给出一个宽泛的表示，那么这时就需要我们自己去寻找需求，从要求中提炼出准确的需求。明确了需求之后才好进行下一部的操作。当然在这之前对于性能测试的主要内容需要掌握，性能的知识点也不是很多，重要的是在实践中的领悟，性能测试并不是功能测试，它是从一个系统，站在更大的立场上去宏观的把握产品，去对系统进行测试，但是并不代表在功能测试的同时不能进行性能测试。性能的要求也会更高，需要了解的知识会更多，对系统的架构要有一定的熟悉度。所以想要真正做好性能测试，任重而道远。加油！
标签：style http io color os 使用 sp for 数据
原文地址：http://www.cnblogs.com/silence-hust/p/4082442.html
