架构师训练营」第 7 周作业

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



看到这题目 又是一期很难做的作业，之前也没有接触过这方面的，公司很少有这么大的并发量 让你去实践，今天特意查了些资料做一些记录：首先看一些概念（来自百度百科）。

首先对吞吐量（）、QPS、并发数、响应时间（RT）几个概念一直比较模糊，也不知道哪些指标可以较好的衡量系统的性能。



响应时间(RT) 

　　响应时间是指系统对请求作出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。 

　　对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。 



吞吐量(Throughput) 

     吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。 

　　对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多不走难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要原因。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。 



并发用户数 

　　并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。一网站系统为例，假设用户只有注册后才能使用，但注册用户并不是每时每刻都在使用该网站，因此具体一个时刻只有部分注册用户同时在线，在线用户就在浏览网站时会花很多时间阅读网站上的信息，因而具体一个时刻只有部分在线用户同时向系统发出请求。这样，对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。 



QPS每秒查询率(Query Per Second) 

　　每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。 （看来是类似于TPS，只是应用于特定场景的吞吐量）



吞吐量是指系统在单位时间内处理请求的数量

在系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间

QPS（TPS）：每秒钟request/事务 数量

并发数： 系统同时处理的request/事务数

响应时间：  一般取平均响应时间

（很多人经常会把并发数和TPS理解混淆）



理解了上面三个要素的意义之后，就能推算出它们之间的关系：

QPS（TPS）= 并发数/平均响应时间  

并发数 = QPS*平均响应时间



如何提高系统QPS？

由前面的公式：QPS（TPS）= 并发数/平均响应时间 可以看出，要提高qps,

我们必须做2个方面努力



1.增加并发数

1.比如增加tomcat并发的线程数，开喝服务器性能匹配的线程数，可以更多满足服务请求。

2.增加数据库的连接数，预建立合适数量的TCP连接数

3.后端服务尽量无状态话，可以更好支持横向扩容，满足更大流量要求

4.调用链路上的各个系统和服务尽量不要单点，要从头到尾都是能力对等的，不能让其中某一点成为瓶颈。

5.RPC调用的尽量使用线程池，预先建立合适的连接数。

6.减少CPU的使用时间

（哪些代码会消耗CPU：循环、字符串拼接\查找\替换、编码\解码、序列化\反序列化、压缩） 

7.增加CPU的数量 

8.减少同步锁 （如果CPU不能被压到85%以上，并且此时的QPS已经达到了峰值，则说明另有瓶颈，接下去关注内存）



2.减少平均响应时间

1.请求尽量越前结束，越好，这样压力就不要穿透到后面的系统上，可以在各个层上加上缓存

2.流量消峰。放行适当的流量，处理不了的请求直接返回错误或者其他提示。和水坝道理很类似

3.减少调用链

4.优化程序

5.减少网络开销，适当使用长连接

6.优化数据库，建立索引



RT提升带来什么？

响应速度提升说明单词请求的处理速度提升，用户感觉任务处理速度更快，系统反应速度更快。当然在处理能力不变的情况下，RT的提升必然会提升QPS。 



如何提升RT？ 

1）减少I/O的响应时间 

2）减少I/O的调用次数 

3）减少CPU使用时间（当然在I/O占大头的应用里，这方面优化效果肯定不明显）



最后，要优化的地方还有很多，优化的指导原则就是增加并发数 和减少平均响应时间



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



这里使用ab工具来进行压测

ab

简介

ApacheBench 是 Apache服务器自带的一个web压力测试工具，简称ab。ab又是一个命令行工具，对发起负载的本机要求很低，根据ab命令可以创建很多的并发访问线程，模拟多个访问者同时对某一URL地址进行访问，因此可以用来测试目标服务器的负载压力。总的来说ab工具小巧简单，上手学习较快，可以提供需要的基本性能指标，但是没有图形化结果，不能监控。

ab属于一个轻量级的压测工具，结果不会特别准确，可以用作参考。



安装

# 在linux环境安装
sudo yum -y install httpd

用法

Usage: ab [options] [http[s]://]hostname[:port]/path
用法：ab [选项] 地址
选项：
Options are:
    -n requests      #执行的请求数，即一共发起多少请求。
    -c concurrency   #请求并发数。
    -s timeout       #指定每个请求的超时时间，默认是30秒。
    -k               #启用HTTP KeepAlive功能，即在一个HTTP会话中执行多个请求。默认时，不启用KeepAlive功能。

压测命令

# 使用ab压测工具，对百度的链接 请求100次，并发数1
ab -n 100 -c 1 https://www.baidu.com/
# 使用ab压测工具，对百度的链接 请求10次，并发数1
ab -n 10 -c 1 https://www.baidu.com/

请求10次压测结果



[root@wj-pzl-server04 ~]# ab -n 10 -c 1 https://www.baidu.com/
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.baidu.com (be patient).....done
Server Software:        BWS/1.1
Server Hostname:        www.baidu.com
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
Document Path:          /
Document Length:        227 bytes
Concurrency Level:      1
Time taken for tests:   1.292 seconds
Complete requests:      10
Failed requests:        0
Write errors:           0
Total transferred:      10820 bytes
HTML transferred:       2270 bytes
Requests per second:    7.74 [#/sec] (mean)
Time per request:       129.209 [ms] (mean)
Time per request:       129.209 [ms] (mean, across all concurrent requests)
Transfer rate:          8.18 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       73  100  39.0     84     175
Processing:    25   29   2.6     29      33
Waiting:       25   29   2.6     29      32
Total:         99  129  40.8    114     207
Percentage of the requests served within a certain time (ms)
  50%    114
  66%    117
  75%    126
  80%    202
  90%    207
  95%    207
  98%    207
  99%    207
 100%    207 (longest request)



请求100次压测结果



[root@wj-pzl-server04 ~]# ab -n 100 -c 1 https://www.baidu.com/
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.baidu.com (be patient).....done
Server Software:        BWS/1.1
Server Hostname:        www.baidu.com
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
Document Path:          /
Document Length:        227 bytes
Concurrency Level:      1
Time taken for tests:   13.709 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      108195 bytes
HTML transferred:       22700 bytes
Requests per second:    7.29 [#/sec] (mean)
Time per request:       137.093 [ms] (mean)
Time per request:       137.093 [ms] (mean, across all concurrent requests)
Transfer rate:          7.71 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       77  104  30.4    100     281
Processing:    25   33   3.6     33      41
Waiting:       25   33   3.6     33      41
Total:        103  137  31.7    134     313
Percentage of the requests served within a certain time (ms)
  50%    134
  66%    138
  75%    144
  80%    149
  90%    153
  95%    191
  98%    300
  99%    313
 100%    313 (longest request)

• 主要关注的测试指标

• Concurrency Level 并发请求数

• Time taken for tests 整个测试时间

• Complete requests 完成请求个数

• Failed requests 失败个数

• Requests per second 吞吐量，指的是某个并发用户下单位时间内处理的请求数。等效于QPS，其实可以看作同一个统计方式，只是叫法不同而已。

• Time per request 用户平均请求等待时间

• Time per request 服务器处理时间