今天完成的事情：

1. 压挂服务

2. 比较有无缓存的区别

遇到的问题：

1. maven 编译 war 提示缺失程序包

原因：

之前一直是使用 IDEA 来编译的，servlet api 是通过在 IDEA 中直接导入 jetty 安装路径的 servlet jar 包来完善的。所以使用 maven 编译的时候就会找不到包了。

解决的方法；

pom 导入相应的依赖。

<!-- https://mvnrepository.com/artifact/javax.servlet/javax.servlet-api -->
<dependency>
  <groupId>javax.servlet</groupId>
  <artifactId>javax.servlet-api</artifactId>
  <version>3.1.0</version>
  <scope>provided</scope>
</dependency>

2. DES 加解密中文乱码

Failures:

  DESTest.test:23->decodeTest:36 expected:<[娴嬭瘯涓 涓  DES 鐨勫姞瀵 ]> but was:<[测试一下 DES 的加密]>

解决的方法：

在 getBytes() 、String() 中都设定 charset 为 UTF-8。

/**
  * @Description: 对加密后的密文进行解密
  * @Param: 加密过的密文
  * @return: 解密后的在信息
  * @Author: owlwinter
  * @Date: 2020/6/16
  */
private static final String CHARSET = "UTF-8";
public static String decrypt(String result) throws Exception {
    byte[] src = hexStr2ByteArr(result);
    // DES算法要求有一个可信任的随机数源
    SecureRandom random = new SecureRandom();
    // 创建一个DESKeySpec对象
    DESKeySpec desKey = new DESKeySpec(KEY.getBytes(CHARSET));
    // 创建一个密匙工厂
    SecretKeyFactory keyFactory = SecretKeyFactory.getInstance("DES");
    // 将DESKeySpec对象转换成SecretKey对象
    SecretKey securekey = keyFactory.generateSecret(desKey);
    // Cipher对象实际完成解密操作
    Cipher cipher = Cipher.getInstance("DES");
    // 用密匙初始化Cipher对象
    cipher.init(Cipher.DECRYPT_MODE, securekey, random);
    // 真正开始解密操作
    return new String(cipher.doFinal(src), CHARSET);
}

3. jmeter 在非 GUI 模式的情况下测试有时候无法正常退出

... end of run

The JVM should have exited but did not.

The following non-daemon threads are still running (DestroyJavaVM is OK):

Thread[AWT-Shutdown,5,system], stackTrace:java.lang.Object#wait

sun.awt.AWTAutoShutdown#run at line:314

java.lang.Thread#run at line:748

Thread[AWT-EventQueue-0,6,main], stackTrace:sun.misc.Unsafe#park

java.util.concurrent.locks.LockSupport#park at line:175

java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject#await at line:2039

java.awt.EventQueue#getNextEvent at line:554

java.awt.EventDispatchThread#pumpOneEventForFilters at line:187

java.awt.EventDispatchThread#pumpEventsForFilter at line:116

java.awt.EventDispatchThread#pumpEventsForHierarchy at line:105

java.awt.EventDispatchThread#pumpEvents at line:101

java.awt.EventDispatchThread#pumpEvents at line:93

java.awt.EventDispatchThread#run at line:82

Thread[DestroyJavaVM,5,main], stackTrace:

解决的方法：

修改 jmeter.properties 文件。

jmeterengine.force.system.exit=true

4. 服务挂了之后 mysql 并没有挂，在服务器上还可以登录操作，远程登录就报错

不清楚什么原因导致的，重启 mysql 无效，需要重启服务器。

收获：

1. 设定 jmeter 跑完压测

主要就是线程组的设定要注意一下，最大线程的设置要增加到压挂服务为止。

Ramp-up period 的设置可以算一下每秒要起多少线程，不要设置的太小了，这个参数可以与 Loop Count 做配合来达到我们的目的。

Loop Count 的设置就是每个线程要循环多少次，这里我设置的是 20 次，保障所有的线程可以有一段时间同时工作，否则我们设置再多的线程也没有用，没来得及打到服务上其他的线程好都跑完了。

上面还有一个很重要的参数 Action to be taken after a Sampler error，这个参数设定了线程访问出错了该如何处置，如果设置为 Continue，那么服务挂了线程也会继续去尝试访问，直到预定的线程循环跑完。

对于我来说需要的效果就是压挂服务器，挂了就不管了，所以选择 Continue 只是浪费时间罢了，可以选择 Start Next Thread Loop（停止当前线程，如果还有线程没有开启的话，开启下一个线程）或者是 Stop Thread（停止当前线程）。

2. 有无缓存的测试数据对比

在 jmeter 生成的 tps 报告中可以看到，加了缓存之后服务每秒处理的事务明显高于无缓存的情况，这符合预期，毕竟在缓存中读取数据显然比去数据库读取数据的效率高，消耗的资源也更少。

在每秒请求数-响应时间中位数图中可以看到，加上缓存之后响应时间更加收敛，响应时间中位数接近零轴，postman 实测某个请求不加缓存需要 33 ms，加上缓存之后响应时间为 10 ms。

4. 90%线

90%响应时间（90%Line）

 一组数由小到大进行排列，找到他的第90%个数（假如是12），那么这个数组中有90%的数将小于等于12 。 

用在性能测试的响应时间，也就是90%请求响应时间不会超过12 秒。

明天的计划：

1. 部署两台WEB，使用Nginx的Upstream来做负载。重新压测。