写点什么

「架构师训练营」第七周作业

用户头像
旭东(Frank)
关注
发布于: 2020 年 07 月 21 日
「架构师训练营」第七周作业

以下两题,至少选做一题

  • 性能压测的时候,随着并发压力的增加,系统响应时间和吞吐量如何变化,为什么?

  • 用你熟悉的编程语言写一个 web 性能压测工具,输入参数:URL,请求总次数,并发数。输出参数:平均响应时间,95% 响应时间。用这个测试工具以 10 并发、100 次请求压测 www.baidu.com



第一题







两个点:

  • 最优并发用户数(The Optimum Number of Concurrent Users)、

  • 最大并发用户数(The Maximum Number of Concurrent Users)。



三个状态描述:

  • 资源饱和(Resource Saturated)、

  • 吞吐下降(Throughput Falling)、

  • 用户受影响(End Users Effected)。



我在很多地方,都看到了对这张图的引用。应该说,做为一个示意图,它真的非常经典,的确描述出了一个基本的状态。但是,示意图也只能用来做示意图,在具体的项目中,我们仍然要有自己明确的判断。



我们要知道,这个图中有一些地方可能与实际存在误差。



首先,很多时候,重负载区的资源饱和,和 TPS 达到最大值之间都不是在同样的并发用户数之下的。比如说,当 CPU 资源使用率达到 100% 之后,随着压力的增加,队列慢慢变长,但是由于用户数增加的幅度会超过队列长度,所以 TPS 仍然会增加,也就是说资源使用率达到饱和之后还有一段时间 TPS 才会达到上限。



大部分情况下,响应时间的曲线都不会像图中画得这样陡峭,并且也不一定是在塌陷区突然上升,更可能的是在重负载区突然上升。



另外,吞吐量曲线不一定会出现下降的情况,在有些控制较好的系统中会维持水平。曾经在一个项目中,因为 TPS 维持水平,并且用户数和响应时间一直都在增加,由于响应时间太快,一直没有超时。我跟我团队那个做压力的兄弟争论了三个小时,我告诉他接着压下去已经没有意义,就是在等超时而已。他倔强地说,由于没有报错,时间还在可控范围,所以要一直加下去。关于这一点争论,我在后续的文章中可能还会提及。



最优并发数这个点,通常只是一种感觉,并没有绝对的数据用来证明。在生产运维的过程中,其实我们大部分人都会更为谨慎,不会定这个点为最优并发,而是更靠前一些。



最大并发数这个点,就完全没有道理了,性能都已经衰减了,最大并发数肯定是在更前的位置呀。这里就涉及到了一个误区,压力工具中的最大用户数或线程数和 TPS 之间的关系。在具体的项目实施中,有经验的性能测试人员,都会更关心服务端能处理的请求数即 TPS,而不是压力工具中的线程数。



这张图没有考虑到锁或线程等配置不合理的场景,而这类场景又比较常见。也就是我们说的,TPS 上不去,资源用不上。所以这个图默认了一个前提,只要线程能用得上,资源就会蹭蹭往上涨。



这张图呢,本来只是一个示意,用以说明一些关系。但是后来在性能行业中,有很多没有完全理解此图的人将它做为很有道理的“典范”给一些人讲,从而引起了越来越多的误解。



You can see that as user load increases, response time increases slowly and resource utilization increases almost linearly. This is because the more work you are asking your application to do, the more resources it needs. Once the resource utilization is close to 100 percent, however, an interesting thing happens – response degrades with an exponential curve. This point in the capacity assessment is referred to as the saturation point. The saturation point is the point where all performance criteria are abandoned and utter panic ensues. Your goal in performing a capacity assessment is to ensure that you know where this point is and that you will never reach it. You will tune the system or add additional hardware well before this load occurs.



按照这段描述,这个人只是随着感觉在描述一种现象,除此无它。比如说,The saturation point is the point where all performance criteria are abandoned and utter panic ensues. 在我的工作经验中,其实在 saturation point 之前,性能指标就已经可以显示出问题了,并且已经非常 panic 了,而我们之所以接着再加压力是为了让指标显示得更为明显,以便做出正确的判断。而调优实际上是控制系统在饱和点之前,这里有一个水位的问题,控制容量到什么样的水位才是性能测试与分析的目标。



第二题

参数

并发数

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



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



吞吐率

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



  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 曲线。



平均响应时间: 所有请求的平均响应时间,取的平均值

95%percentile : 统计学术语,如果将一组数据从小到大排序,并计算相应的累计百分位,则某一百分位所对应数据的值就称为这一百分位的百分位数。可表示为:一组n个观测值按数值大小排列。如,处于p%位置的值称第p百分位数。



例如有100个请求, 每个请求的响应时间分别是 1-100 平均分布

平均响应时间: 1-100 的平均值,即 50.5

95% percentile : 按从小到大排序,累计第95百分位,也就是 95 (即样本里95% 的数据都不高于这个值)





代码实现:



https://github.com/huoxudong125/org.hqf.architect.demo/tree/master/rest-perf-tester



发布于: 2020 年 07 月 21 日阅读数: 91
用户头像

旭东(Frank)

关注

世事洞明皆学问,日思一刻,日拱一卒。 2011.04.01 加入

微信公众号:ThinkingInDev,记录工作过程中点滴思考。这里有坑,有料,有思,有想的开发工作日记

评论

发布
暂无评论
「架构师训练营」第七周作业