项目结束后问题也没有得到根本解决。宝路由此引发了一些列的思考，今天想跟大家聊聊。
前一篇文章写了压测报表系统时的问题，问题抛给某厂商后，厂商人员来了两次做现场支持，然而效果并不理想。追问其产品底层原理，为什么内存回收后会导致，报表系统的“不可用现象”，然而。
思考1：脚本采用匿名登录的方式来查询报表。
先解释下这里所说的匿名登录，其实就是个白名单，将执行脚本的机器的ip增加白名单，然后可以通过指定的url来获取token，再拿这个token来访问指定报表。这样就避免了登录系统的步骤。（因为他们自己都没解决登录系统的密码加解密问题，当时也跟他们聊了为不能提供登录密码的加密方式，然而回复却是，目前他们自己测试也是采用匿名登陆方式），这个token在查询完一次报表后就失效了，也就是必须将获取token 跟查询报表均放在LR的action中。
这样的脚本就极其简单，发送请求获取token，再发一个请求（带token)来查看报表，这种方式是否合理？试想真实环境中用户是这种场景么？显然不是。。。。。试想下这样的方式与真正用LR录制出的脚本相比是不是会少了好些页面请求？
思考2：忽略思考时间这种压测方式到底有没有问题
这又要说到，前篇文章测试中提到的压测问题。采用忽略思考时间这种方式压测，报表系统长时间压测就会出现前篇文章中所说的问题。这里又要说到OLTP，OLAP
什么是OLAP：联机分析处理；什么是OLTP：联机事务处理。
我们常见的接口压测（说的再范围一些就平常的增、删、改、查）都是属于OLTP , 然而OLAP 一般就是数据仓库系统的主要应用，用来分析大量OLTP形成的数据，说白就是对这些历史数据进行加工分析，读操作较多。
最后解决方案就是，增加pacing值，3s , 4s ,5s 分别进行了尝试。其实就是对之前的脚本进行了弱化（从发起压力角度来说），这样更贴近真实的业务场景。本来在线用户就少，其实远未达到忽略思考时间的那种查询密集度。现实中也不可能存在业务人员疯狂在不停的查询报表。
但最后还是要说下，忽略思考时间的这种方式本身没有问题。确实不太合适当前的场景，假如真的就是存在这种场景，或者说我就要看你系统在高点击率下的性能表现，那么就要采用这种方式了。
问题又来了，在这种高点击率下，长时间（大概20min左右）的压测，系统却出现了不可用的现象且短时间不可恢复，需要手动重启产品的某个服务才可以，这种现象我觉得是不ok的。这就需要产品人员深挖其原因，是不是产品缺陷导致的。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理
