所以，刚做测试时，我们群里热议论，如果我们每个人都开一个压力工具对百度网站进行加压。百度，服务器会不会挂掉。有测友说这样是不道德人。呵呵！其实，完全不必有这个担心。一般人家用的带宽，我确保，你向百度服务器发送的请求大部分都死在半路上，算不死到了百度服务器已经不能叫并发了。何况百度服务器的集群技术以及其他各种分压技术。所以，做性能测试不了解被测系统的架构，以及各种技术的性能。很难做出有效的测试报告。

　　下面我们看看性能测试的一些技术指标。

　　Work Load = Virtual Users

　　工作负荷 = 虚拟用户数

　　对服务器产生多大压力，可以由多少用户同时对服务器发送请求来衡量。也是服务器的性能可以看它同时处理多少用户发送来的请求来衡量。

　　虚拟用户数可以用进程或线程的方式进行模拟。

　　response time  响应时间

　　从客户端将数据包发出，到接收到服务器端发来的请求。这个过程的总体时间叫response time

　　这个时间用来衡量的处理请求的速度（抛出网速限制的前提下）

　　throughput ~Ti & To

　　这个表示，吞吐量，吞吐量越大表示系统性能越强。1个用户跑100天和10个用户跑1分钟。当然是1个用户跑100天的吞吐量大。所以，我们要想看系统的性能应该用“吞吐率”，是单位时间的吞吐量，比如吞吐量/秒。

　　站在服务器端，T-in表示“吞”；T-out表求“吐”

　　Ti：T-in 主要衡量客户端的能力，看客户端往服务器发送的请求数据包的吞吐率。

　　To： T-out 主要衡量的服务器端的能力，看服务器处理返回请求数据包的吞吐率。

　　Hits/Request

　　网页点击数/请求

　　Response/Successful Response

　　响应/成功的响应

　　Request与Response是对应，一个请求对应一个响应。但当客户端对服务器的压力达到一直程度后，不是每一请求都能得到响应的。去年末火了个牛B的“电子商务”网站。12306（铁路网上订票系统），虽然有很差的用户体验，但每天还是大把的人拼命的登录（过年回家的人伤不起），甚至用外挂登录。见有网友云云点击（请求）了几十几百次才订票（响应）成功。所以，成功响应率也是很重要的一个指标。客户端发送一千个请求的成功得到响应的几率。

　　Hits Per Second

　　每秒中点击次数

　　和吞吐量一样，单单用点击数（hits）来衡量系统也是不合理的。所以，用每秒钟的点击数才能衡量出服务器的处理能力。

　　响应时间图分析

　　横坐标表示用户数

　　纵坐标表示时间

　　红色虚线，表求的是一种系统的理想状态。

　　当服务器处理10个用户请求时所用的时间是2秒（假设），当服务器处理200用户请求时所用的时间也是2秒。所以说这种状态是一种理想的状态。现实中，不管是如何超级强的服务器当用户数达到一定数量时，响应时间必会变慢。

　　蓝色斜线，是服务器常见的一种曲线状态。

　　服务器的响应时间虽然用户数量的增加逐渐变慢。

　　当系统出现这种斜线，应该说系统性能是相当健壮的。随着用户的增长响应时间逐渐变长。

　　黑色曲线，个人觉得是服务器处理能力的真实曲线状态。

　　为什么说黑线才是真实服务器处理能力的曲线呢？当用户处理一个用户请求是2秒（假设），当处两个用户请求是马上变成3秒（假设），当处理3个用户请求时变成4秒（假设）。再差的服务器也有个处理范围，比如是，100用户同时并发，服务器可以轻松应对，不管是10个用户还是80个用户同时请求，服务器都可以即可响应（请参考理发店模式）。只有当用户数量达到某个数量点后，服务器性能急剧下降。如上图黑色十字星处是系统的拐角点。

　　我们假设有一个门，在一个时间点上可同时过10个人，不管你是同时来3个还是10个都可以在同一时间点过门，假如来了11个人，必然有一个人要等10个人过门之后才能过。那么当超过10人来过门时，过门的速度开始变慢。那么10是服务器性能的拐角点。我们通常做压力测试找服务器的拐角点是很重要的任务之一。

　　关蓝色曲线与黑色区线只是我们常见两种曲线。现实的测试中可能出现各种样式的曲线。当然还要看你做测试的细度，比如，10个用户是系统的拐点，如果你做完5个用户的一轮测试后，是20用户的测试。那么画出来的曲线变成斜线，拐点将被护忽略掉。