文档章节

性能测试的简单几个概念

D
 Dreamsnow6
发布于 2017/03/28 11:59
字数 2867
阅读 623
收藏 3

基本概念

  开始前,先简单介绍一下性能测试的几个基本概念。

  并发数

  并发数是指在同一个时间点,同时请求服务的客户数量。

  比如大家常说的:『 我的网站可以承受一万并发。 』在通常情况下指的是:如果同时有一万名用户访问网站,所有人都可以正常获得服务。而不会有超时或连接拒绝情况发生。

  吞吐率

  吞吐率指的是服务处理请求的效率,计算方式为 ( 总处理请求数 / 总耗时 )。

  HTTP 服务的吞吐率通常以 RPS(Requests Per Second 请求数每秒)作为单位。吞吐量越高,代表服务处理效率就越高。换句话说就是网站的性能越高。

  注意:吞吐率和并发数是两个完全独立的概念。拿银行柜台来举个例子,并发数指同时有多少人往银行柜台涌来。吞吐率则指银行柜台在一段时间内可以服务多少个人。

  但是在性能测试中,二者之间通常会呈现出一种关联关系。当并发数增大时,吞吐率通常也会随之上升( 多用户发挥出并行处理优势) 。但在并发数超过某个边界值后,吞吐率则会下降 (用户过多,花在上下文切换的开销急剧增大,又或者内存消耗过多) 。

  响应时间

  响应时间指的是用户从发出请求到接收完响应之间的总耗时,它由网络传输耗时、服务处理耗时等多个部分组成。通常以毫秒(ms)作为单位。

  与并发数的关系:一般来说,随着并发数增大,单个用户的响应时间通常会随之增加。这很好理解,餐馆吃饭的人越多,单个顾客等待的时间就越长。

  与吞吐率的关系:更高的吞吐率通常意味着更低的响应时间。因为吞吐率是以 单位时间 内的请求处理能力来计算的。

  平均响应时间与百分位响应时间

  平均响应时间指的是所有请求平均花费的时间,如果有100个请求,其中 98 个耗时为 1ms,其他两个为 100ms。那么平均响应时间为 (98 * 1 + 2 * 100) / 100.0 = 2.98ms 。

  百分位数( Percentile - Wikipedia )是一个统计学名词。以响应时间为例, 99% 的百分位响应时间 ,指的是 99% 的请求响应时间,都处在这个值以下。

  拿上面的响应时间来说,其整体平均响应时间虽然为 2.98ms,但 99% 的百分位响应时间却是 100ms。

  相对于平均响应时间来说,百分位响应时间通常更能反映服务的整体效率。现实世界中用的较多的是 98% 的百分位响应时间,比如 GitHub System Status 中就有一条 98TH PERC. WEB RESPONSE TIME 曲线。

  准备工作

  1. 挑选测试目标

  一个网站通常有很多个不同的页面和接口。如果要完全模拟真实环境的访问,就得为各页面设置不同的权重,同时访问所有页面。或者取巧一点,采用重放真实环境访问记录的方式。

  进行整体性能测试比较复杂,这里不打算介绍相关内容。 这次主要讨论对单个页面测试。

  那么,怎么挑选测试的目标页面呢?一般来说,那些用户访问较多的页面通常是比较好的选择,它们可能是:

  · 首页/Landing Page :通常是用户第一个打开的页面

  · 关键行为页面 :如果网站的主要功能是发放优惠券,那就测试发放优惠券的接口

  · 活动页面 :新活动上线推广前,理所应当应该进行性能测试

  尽量模拟真实的用户情况

  举个例子,如果你想压测一个文章列表页,那么一定先要挑选一位拥有一定数量文章的用户,然后使用其身份来进行测试。千万不要用那些一篇文章没有、或只有少数文章的测试账号。那样会产生失真的测试结果,让你对服务能力产生过于乐观的估计。

  所以,在测试与用户相关的动态内容时,请细心挑选用户身份,尽量反映绝大多数用户的情况。

  别忘了关注边界情况

  让测试过程反映绝大多数用户的情况很重要,但也请别忘了那些边界情况。

  比如,当用户拥有 50 篇以下的文章时,你的文章列表页面响应速度非常好,吞吐率非常高。那么如果某个用户拥有 1000 篇文章呢?列表页的性能表现还能满足需求吗?响应时间会不会呈指数级上升?这些都是你需要测试的。

  牢记『木桶效应』,你的服务很可能会因为没有处理好这些边界情况而崩溃。

  2. 选择测试工具

  市面上开源的 HTTP 性能测试工具非常多,我使用过的就有 wrk 、 ab 、 vegeta 、 siege 等。所有工具都支持对单个地址进行测试,部分工具支持通过地址列表进行批量测试。

  除了 ab 这种历史比较悠久的工具,大部分现代压测工具效率都非常高,所以挑选哪个区别不大。像我就是 wrk 的粉丝。

  3. 记录关键信息

  硬件配置对测试结果影响非常大。所以,在开始测试前,最好记录下你的服务器硬件情况,这包括 CPU、内存、网卡速度等等。如果有必要的话,那些关键的关联服务 - 比如数据库 - 的硬件配置也应该一并记录下来。

  除了硬件配置外,还应该记录下与你的服务密切相关的其他配置信息,比如:

  · 服务 Worker 类型是什么?线程、协程或是进程?开启了多少个?

  · 是否使用数据库连接池

  等等等等。当你对比多份测试结果时,这些配置信息就会派上用场。如果你还想分享测试结果给他人,那么提供这些配置信息是必须的。

  进行压测

  接下来就可以开始具体的压测过程了。一般来说,针对单页面的压测过程都是非常简单的。你只需要提供少数几个参数:并发数、持续时间、页面地址,然后等待测试完成即可。以 wrk 为例:

  $ wrk --latency -c100 -t5 -d 10 http://localhost:8080/hello/piglei

  # -c 100:使用 100 个并发数

  # -t 5:开启 5 个线程

  # -d 10:持续 10 秒钟

  一份完整的测试报告,通常要覆盖多个不同的并发数配置,比如 [10, 100, 256, 512, 1024, 2048] 等等。你最终的测试结果,需要体现出服务在不同并发数下的性能表现差异。

  在压测过程中,还有几个注意点:

  1. 专机专用

  执行测试工具的机器与测试目标服务所在的机器上,最好不要运行其他无关的程序。这样可以最大程度减小对测试结果的影响。

  2. 测试时间不要过短

  缓存需要预热,服务也需要一段时间来稳定下来。所以,测试时间不要太短,比如小于 30 秒钟。过短的测试时间会影响结果的可靠性。

  为了让测试结果更可靠,请让每次测试时间至少超过一分钟,比如 3-5 分钟。

  3. 不要让测试机成为瓶颈

  现在的服务器配置越来越强大,很有可能,你的目标服务处理能力还没达到瓶颈。你的测试机就已经先不行了。所以,在测试过程中,请一并关注你的测试机负载情况。

  如果发现因为测试机自身瓶颈导致测试结果不准确,请使用更好的机器,或尝试同时使用多台测试机。

  4. 调整好系统参数

  在开始压测前,确保系统的最大文件描述符数量等参数已经被调优过,避免影响压测过程。

查看压测结果

  以下是执行 wrk 后的输出结果:

Running 10s test @ http://localhost:8080/hello/piglei

5 threads and 100 connections

Thread Stats   Avg      Stdev     Max   +/- Stdev

Latency   336.28ms  651.93ms   1.72s    81.42%

Req/Sec   657.74    547.89     3.47k    72.81%

Latency Distribution

50%   28.88ms

75%   38.64ms

90%    1.71s

99%    1.72s

33320 requests in 10.00s, 4.10MB read

Requests/sec:   3331.92

Transfer/sec:    419.74KB

在一次压测结果中,有很多有用的指标:

  · 吞吐率 Requests/sec: 服务吞吐能力,也就是一秒钟平均处理多少请求数。它通常是压测结果中最重要的指标。

  · 数据传输速率 Transfer/sec: 数据传输速率,压测响应结果较大的页面时,请尤其注意该值有没有达到网络瓶颈。

  · 响应时间 Latency: 有关响应时间有很多不同值,请不要只关注平均响应时间,更需要注意最小值、最大值、百分位值、标准差等等。

  · 错误请求数: 当并发数过高,或服务处理能力不够时。请求就可以发生错误。你的服务可以最多承受多少并发而不产生错误?这是需要重点关注的指标之一。

  可能影响压测结果的因素

  1. HTTP 响应是否开启 Gzip 压缩

  如果目标服务处在 Nginx 等支持 gzip 压缩的服务后,而刚好请求响应体又比较大。那么是否开启压缩会较大程度影响到压测结果。每个工具开启压缩的方式都不一样,一般情况下,你需要手动添加 Accept-Encoding: gzip, defalte 请求头来开启 Gzip 压缩。

  2. 测试机器与目标服务之间的网络质量

  测试机器和目标服务之间的网络状况会很大程度影响压测结果。所以,最好保证测试机与目标服务处在同一网段。同时关注压测结果中的数据传输速度(Transfer/sec)是否接近网络速率极限值。

  3. 负载均衡器

  如果你的目标服务前面有配置负载均衡器,那么它可能会对测试结果产生影响。

  比如,使用 Nginx 的 proxy_pass 配置的后端服务,极限 RPS 在几千左右。如果后端服务的吞吐率非常高,那就需要考虑负载均衡器会不会成为你测试的瓶颈所在。

  4. 是否开启了 HTTP 长连接

  较现代的 HTTP 服务器基本都支持持久化连接(以前俗称 keep-alive),在测试过程中,请确定你的测试工具与服务端是否都开启了 HTTP 长连接选项。

  因为每次压测通常要产生非常多次请求,客户端的连接是否可以复用对结果影响非常大。可以的话,请将开启或关闭长连接作为两种情况分开测试。

 

 

© 著作权归作者所有

D
粉丝 3
博文 13
码字总数 6760
作品 0
杭州
QA/测试工程师
私信 提问
压力测试的概念 & apache ab压测工具

写在前面 在学习ab工具之前,我们需了解几个关于压力测试的概念 吞吐率(Requests per second) 概念:服务器并发处理能力的量化描述,单位是reqs/s,指的是某个并发用户数下单位时间内处理的...

fdhay
2016/06/15
84
0
Checking Table 设计模式 - 从概念、建模、设计到实现

文章转自 IBM developerWorks 简介: 如何基于业务需求驱动理念来开展我们的模式创新,成为了当今架构师、设计师的重要职责之一。本文通过具体的 Checking Table 设计模式案例创新过程,阐述...

IBMdW
2011/06/11
379
1
《LoadRunner 没有告诉你的》之四——理解性能

版权声明:本文可以被转载,但是在未经本人许可前,不得用于任何商业用途或其他以盈利为目的的用途。本人保留对本文的一切权利。如需转载,请在转载是保留此版权声明,并保证本文的完整性。也...

不最醉不龟归
2016/09/30
7
0
性能测试相关(TPS/RT/PV等)

对于我们开发来说,我们日常最熟悉的工作就是把客户的需求实现并交付。但是,事情并不是往往就这样结束了,我们还需要后续对上线的系统进行跟踪调查,查看系统的运行情况。为什么呢?一方面,...

tantexian
2016/05/30
485
0
如何评估Kubernetes持久化存储方案

在2018年的Garnter技术成熟度曲线中,容器存储出现在了技术触发期,已经开始进入大众的视野。我相信,在未来的两年内,容器存储会随着Kubernetes的进一步成熟和商业化,其地位会越来越重要。...

Docker
01/16
0
0

没有更多内容

加载失败,请刷新页面

加载更多

用Javascript评估用户输入密码的强度

密码已经是我们生活工作中必不可少的工具,但一个不安全的密码有又有可能会给我们造成不必要的损失。作为网站设计者,如果我们在网页中能对用户输入的密码进行安全评估,并显示出相应的提示信息...

花漾年华
29分钟前
0
0
Python 打开目录与指定文件

Python打开外部文件有很多方法, os.popen打开外部程序,但发现只能打开文件所在目录的文件 os.system可打开外部文件os.system(command) command 要执行的命令,相当于在Windows...

shzwork
31分钟前
2
0
Leetcode # 118:Pascal's Triangle 杨辉三角

118:Pascal's Triangle 杨辉三角 Given a non-negative integer numRows, generate the first numRows of Pascal's triangle. 给定一个非负整数 *numRows,*生成杨辉三角的前 numRows 行。 ......

iCodeBugs
41分钟前
1
0
IntelliJ IDEA导入Gradle项目

1.File > Open 找到项目后选择build.gradle文件,点击ok image 2.点击Open as Project image 3.选择本地Gradle以及JDK image 4.点OK完成...

青峰Jun19er
45分钟前
2
0
Python实现斐波那契数列

斐波那契数列大家都很熟悉吧,咱们在高中学数学的时候,老师会讲这个定律以及算法,其实数据结构和数学息息相关,数学思维好的往往逻辑思维就比较好,今天小猿圈带大家学习一下python的斐波那...

小猿圈加加
46分钟前
3
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部