这里lr就可以运行压力测试了，同时我们可以从下图中看到正在测试过程中的各项参数，如下图（注意红字标注部分）：
从上图中的“并发用户”图中，答道可以看到，大经销商在5分钟时，并发用户数达到了1000的‘上限’，而在“响应时间”中我们看到“发主题”操作的执行曲线在3分钟时创出响应时间的‘高峰’，且其执行时间普遍高于其它页面。而就在3分钟时并发用户数开始接近于1000，看来大并发对于发主题操作的压力不小呀。其实在正常环境下，用户要求的响应时间维护在3-8秒左右，而像上图所posttopic_transaction中的“平均值”却达到了26秒多，显然是不可接受的，但正如我在前一篇中所说的那样，这次测试是抱着一种将“服务器”压死的目的来测试的，所以设置的参数基本上已接近那台1u服务器所能承受的上限了，当然这会上平均页面的响应时间变得‘过长’，但我认为正是这种‘慢动作’的‘假象’才能让系统处于‘疲于奔命’的情况，也才能让其问题能够暴露的更全面一些。当然除了这种加大并发和工作量的方式之后，在lr中还可以通过设置‘集合点’的方式来制造更大的压力，只不过后者更倾向于对那些正在改进或已改进的程序代码进行压力测试的情况，我会在后面优化程序的时候加以说明。
注：这里有必要介绍一下什么是“点击率（Hits/sec）”, 即每秒点击数，是在场景或会话步骤运行过程中VUser每秒向WEB服务器提交的HTTP请求数. 而上图中就是0--5分钟这段采样时间内VUser平均每秒发送的HTTP请求数。而这个值的图表‘走势’是与系统的‘吞吐量（Throughput）’相对应的，这一点会在生成测试报告时加以解释说明。
一般在这个时间，我会在到达1000并发用户（图中4分钟左右）时，习惯性的去看一下服务器的cpu，内存和网络情况，因为这时如果cpu处于长时间100%时就是已到了系统瓶颈了，下面就是此时服务器端的cpu，内存使用情况：
上图中，我们看到cpu经常在100%的使用率上徘徊，并且一旦到了100%的高峰上时，就会持续一段时间，大约为3-5秒，然后就会迅速下跌。这说明系统在此时‘可能’出现了资源争用情况，比如内存，文件或数据库等，而此时图中内存使用情况并不高，可以排除内存方面的问题，还有就是此时的网络情况也并未造成拥塞（如下图：经常处于20-50%的状态下），所以网络方面的因素也应该予以排除了。
那么就只剩下文件访问和数据库方面的问题了。因为在discuznt中使用了配置文件方式来设置系统参数，并且其文件被加载之后就被static方式进行声明，所以一旦系统运行起来之后，就不会频繁访问文件了，这一点在之前的“Discuz!NT之配置文件类”中已做过说明，所以最后就剩下数据库方面的因素了。
文章来源于领测软件测试网 https://www.ltesting.net/
