压力测试-分析（阿里云PTS,Lite）

2016-05-24

此文阅次

分析

并发用户数 - 成功TPS - 响应时间 - 失败TPS

并发用户数：人数慢慢增加过程（预热时间），关注长时间打压后，后端是否出现内存溢出，或延迟逐渐升高

成功TPS：每秒可处理的事务数量。

1
2
3

公式： 成功并发人数/正常处理完的平均时间= 每秒可处理的事务数量（TPS）/1
?( 成功并发人数 )/0.7=30/1    ，0.7s内成功事务数是21个，1s可处理30 个
?/0.1 = 30/1                             ，0.1s中成功事务数是3个，1s可处理30个

响应时间：
正常情况为业务接口响应时间。当系统超出承受出现的线程等待，此等待时间也将计入响应时间。
施压机的步调如果为2s，2s后重新请求会关闭上一个未结束（等待状态）的线程，所以等待的最大值为2s，由此可知道，响应时间在超出承受后时间一般接近步调值2s。
失败TPS：系统出现瓶颈，请求不能正常处理。出现的节点，可推算出系统的承载人数。
步调2s：一个用户请求接口的间隔时间，等同用户使用同一个功能的频率。（秒杀，摇一摇步调较短2~5）

【TPS-50,步调-2】可得出承受用户数量=tps50 步调2=100人
当用户超过100人，则超出系统正常处理负荷，此时即将出现失败请求。（考虑是否可使用队列解决失败请求？）
如果步调放大为10,则系统将可承受50 10=500人
结论：系统的具体承受取决于
（系统基础TPS - 业务接口损耗TPS=业务接口实际TPS）* 步调（取决实际业务）=业务接口的承受用户量

步调0s：
接口 TPS50 步调0 = 极限支持用户量就是0，所以可以看出，从系统一开始就出现了失败请求。
随着人数的增加，50人并发[0.1~1.0s ]的极限步调=承受的人数

步调1s：
明显超过50人后，系统才出现失败请求
公式: 接口TPS50*步调1s = 系统承受人数50（超过50人则超出承受，异常请求就会出现）

反推：系统如需支持200人在线，在接口现状的TPS50下，步调多少可以正常处理所有请求呢。
公式：200承受人数 / 接口TPS50 = 步调4s

步调4s：意外了，结果并不是正常处理完所有请求，为什么？
原因：步调也可能齐步走，所以并发人数同时请求，时刻的压力=人数200/步调(1~4) = 200~50之间

如果50内，系统可以承受，超过则出现异常（200时为最大值）
波动的幅度就是步调（1~4）中的齐步走线程数量

再推算: 在正常处理所有请求的情况下，应该配置多少人并发。【50人并发】- TPS失控了，不是预想的50
步调1S （解决齐步走并发人数同时请求）
接口TPS50 * 步调1S = 50并发人数
实际数据确认，TPS在36时，用户人数也是36时，系统刚好处理完所有请求。这，其实已经可以证明TPS数(36)在1s的步调下只能承受等同的人数(36)
为什么TPS只达到（35~40)？这是新的思考问题，猜测：因为TPS不是个常量而是变量，所以在系统负载一段时间后可能会发生变化（降低）
而承受的在线人数（1s的步调下）是与TPS数同步的。

配合当前的TPS数(30)，配置并发人数(30)，步调1s
结果和想的一样，所有请求全部成功。

最终结论：
系统的同时刻承载用户数应该就是业务接口的时刻TPS数。在实际的场景中因为单用户的步调不一致，或同时刻请求的用户不一致，系统可承载的用户量也是无限大的。

但是依然可以通过系统的基本参数，推断系统可承受的活跃用户。

如：任意接口的平均TPS（50） * 单用户请求任意接口的步调为10s = 系统承受500活跃用户同时在线

对具体的接口推算将更准确，因为TPS更明确。步调也相对明确。
（如，评估一次秒杀活动，摇一摇活动，抽奖活动，就能相对准确的推算出系统承受的同时在线人数）

如果想提高在线用户人数，因为步调由业务决定不方便改变，TPS值可通过软件优化，硬件扩容，集群部署等多方法提高，从而达到预算支撑的同时在线人数。

TPS 与并发人数（步调为1s）的关系

依据上文中结论，应该是并发人数超过DPS数就会出现失败请求（即，在无失败请求的情况下，并发人数 = TPS数。- 前提步调是1s）

有时会看到并发人数超过了TPS数？ -步调1s基础
出现了失败TPS 或步调>1s 或响应时间边长?
提示 在允许小量的失败率情况下，支撑的并发人数会超过一定量的TPS数。

下面看看数据

机器配置 阿里云 ECS 2核 4G
注意 曲线观察时，注意左右两侧的参考线.
如：成功TPS与失败TPS的参考线不一致时，低数值的曲线可能在高数值的上面。这不能直接代表什么，需要认真看具体数值（依据参考线）

1.nginx性能：
http://**.43/ng-test.html
在此场景下，TPS可达到1663左右（每秒并发数）
失败率是0,说明还没打压到性能瓶颈，而lite版最高并发只能配置2000
可以使用企业版TPS或使用自己的机器做施压机+ad， loadrunner

66.98(处理事物数量)/0.034 = 1970/1 ≈ 2000用户数

2.Tomcat性能：

http://**.43/test/test.html

在此场景下，TPS可达到1596左右（每秒并发数）

3.访问框架空接口（tomcat + Spring MVC）的性能：

http://
**
.43/k12platform/service/helloWorld

在此场景下，TPS可达到585左右（每秒并发数）

4.访问框架单次数据库查询的最佳性能（获取市下学校-一次单表交互）：
http://**.43/k12platform/service/school/330110
在此场景下，TPS可达到240左右（每秒并发数）

*
5
.访问一键登录接口的性能：

http://**.43/k12platform/service/login/oneLogin/student/15158136199/88

在此场景下，TPS可达到130左右（每秒并发数）

监控

tomcat Catalina.sh

1 2	CATALINA_OPTS="$CATALINA_OPTS -Xloggc:/usr/local/apache-tomcat-7.0.59/webapps/sys/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps"

优化手段

jvm Catalina.sh -> 4G内存为例


JAVA_OPTS="-server"
JAVA_OPTS="$JAVA_OPTS -Xms2500m"
JAVA_OPTS="$JAVA_OPTS -Xmx2500m"
JAVA_OPTS="$JAVA_OPTS -XX:PermSize=512m"
JAVA_OPTS="$JAVA_OPTS -XX:MaxPermSize=1024m"

应用服务器 tomcat http连接数 conf/ server.xml

<Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443"
           minProcessors="10" 
               maxThreads="3000" maxProcessors="3000" enableLookups="false" acceptCount="3000" debug="0"
           />

应用连接数据库连接数 工程数据库连接池配置如:config.properties

1
2
3

` maxActivity` 连接池的最大数据库连接数(建议值：*)

`maxIdea` 最大空闲数，数据库连接的最大空闲时间 (建议值：*)

数据库连接数 mysql max_connections
1
1000~5000 并行连接

分析

TPS 与 并发人数 （步调为1s）的关系

下面看看数据

监控

优化手段

TPS 与并发人数（步调为1s）的关系