压测过程中的一些Bug
压测是模拟真实环境中多用户并发情况下对于系统接口的使用,主要要做的事脚本文件的编写:
脚本的内容其实就是一个单元测试的内容,而使用压力机的方式可以模拟出很多个用户同时访问该接口。
GET
请求的脚本,直接进行字符串的拼接即可构建出一条简单的GET
命令。因为获取到的命令是一个含有域名的GET
命令,对域名进行解析可得到相关的IP
组,这里会引入一个随机读(可自行搜索)的类对IP
组进行一个随机读取以保证负载均衡。POST
请求的脚本,其实本质还是网络请求,不过这里不能直接使用字符串拼接达到自己的目的,需要新编写一个POST
请求(可搜索,例子很多),按照随机读取的方法从预先准备好的文件中读取数据。内部接口的脚本,这个相对而言是最简单的,使用自己的内部账号对
maven
设置文件进行修改即可获取公司仓库的内容。因为项目是采用的Spring
框架,这里直接在响应的bean
设置文件中设置即可使用相关接口的实现。
遇到too many result
的问题
首先对于每一个接口为了防止无用的请求,是会要求设置一个
filter
来检查调用信息的token
和tokenName
是不是正确的一开始以为是因为访问数据库返回了多个对象导致的原因,但是后续发现代码的逻辑上是返回对象数组的第一个元素,因此可以排除这个问题。最后在组内大佬的帮助下找到了问题。
在使用过滤器的基础上,如果存在着多个
token
的注册则会发生too many result
的问题。
遇见了本地测试通过而实际测试不通过的情况
第一个是服务器的问题,服务器启动之后一直显示
JSF
的远程连接连接不上,可以尝试重启一次服务器尝试(这里显示的是一直失败)第二个是测试直接从数据库中提取,因为对于一般的接口如果需要进行数据的获取:一般是从
redis
、es
中获取得到初始的数据。而这里从数据库中获取,开始进行本地测试因为只有一个用户进行访问,因此可以顺利读取到数据。后来用于测试中,因为同时存在多并发的情况对于数据库的访问无可用数据。(这里显示的是没有可用数据)
其余一些常见:
存在着之前过滤器中提到的问题,当不使用拦截器的时候无法直接访问到内部使用的接口
很重要的一点,这里提到的过滤器用于过滤请求是防止公司内部其他部分无意之间调用到该接口或对数据库产生影响(接口只是某一个
service
提供的一个方法,可能该service
中会存在着其他的方法可以对数据库进行操控,因此需要一个过滤器指定特定的部分使用该service
)- 对于之前提到的并发线程数,这里注意到尽管可能并发用户数设置成1,但是
TPS
的值完全可以达到一个很高的数值。也就是存在并发线程数上升而TPS
下降的问题。