压力测试

docs/Solution/记一次商品标签压测.md

@@ -0,0 +1,44 @@
+---
+layout: default
+title: 记一次商品标签压测
+parent: Solution
+---
+
+# 1. 背景
+
+商品线提供一个新的接口给交易线进行查询商品的标签，交易线要求QPS可以达到10,000。由于存在前期的
+灰度，因此暂时只选择一个sku较少的省区，前期灰度要求QPS是6000。
+RT在100ms内。
+
+请求报文除了一些固定的标识，如系统来源，电商主体，主要就是一个数组，内容是sku，一次最多是50个，
+返回报文中，每个sku可以携带的标签可以100个。
+
+# 过程
+
+在测试环境压力测试进行压力测试
+
+## 场景一：只有一个sku，返回的数据只一个sku及8个标签
+
+QPS可以达到10,000,可以超过预定的6000
+RT可以达到20ms内
+
+jmeter返回的报告中，RT和QPS相当，都比较稳定
+
+## 场景一：全程50sku，返回的数据50个sku及每个sku都20个标签
+
+业务系统部署1台机器和6台机器返回结果是一样
+QPS可以达到1,400,远低于预定的6000
+RT可以平均达到140ms内
+
+jmeter返回的报告中，RT和QPS相当都比较不稳定，QPS开始是上升的，到达一定时间后，出现了
+快速下降，此时RT时间上升，QPS有一定上升，但达不到一开始的波峰，RT时间下不去
+
+# 排查
+
+通过查看业务机器的日志，发现dubbo的线程化，出现了大量的EXHAUSTED，拒绝了请求。但是什么导致
+线程池拒绝，进一步分板，单次线程执行时间过长，请求又过多，线程池得不到满足。单次线程执行时间过长
+的原因是redis的性能瓶颈，测试环境的redis是单机的。
+
+# 解决方案
+
+准备在压测环境，部署redis集群，来观察测试的结果

docs/test/压测场景.md

@@ -0,0 +1,17 @@
+---
+layout: default
+title: Jmeter理论
+parent: Test
+---
+
+# QPS上不去
+
+
+# QPS先上升，后下降，缓慢上升后，缓慢下降，趋于稳定，但成功率很低
+
+1 业务系统的DUBBO线程池，提示EXHAUSTED错误，线程池满，拒绝新的请求，会出现下降，
+2 下降后，部分线程业务完成，可以接受新的请求，又缓存上升
+3 成功率下降，是因为拒绝请求，返回是异常，不是成功的报文
+
+
+# 

docs/test/测试面试.md

@@ -0,0 +1,17 @@
+---
+layout: default
+title: Jmeter理论
+parent: Test
+---
+
+# 测试理论
+
+# 业务系统
+
+# 测试用例设置
+
+# 压测结果分析
+
+# 压测场景设计
+
+