当前定义的性能测试介入点，是功能测试第一轮结束之后。而第一轮功能测试主要目的是发现bug，此时介入可能会该性能测试带来一些不必要的麻烦。

常见的问题，是页面vm存在bug。当页面被大量访问时，velocity log里每次都打印出vm的错误日志。假定每条日志为200bytes，每秒的访问量为30，一秒的日志量为200*30=6，000bytes。约为 5.86K。以这样的速度计算，一分钟会达到351.6K。随着时间的推移，日志量是相当可怕的。如果vm上有多处错误，日志量将更加恐怖。

模版的bug是功能问题，本身是不会影响系统性能的。但是当log达到一定量之后，比如单个文件1G，影响的效果比较明显了。为了这么大的文件再继续往里写，是会消耗服务器资源的。

怎么办？

方法有两个：第一、屏蔽velocity log；第二、不屏蔽，利用技术手段定时删除velocity log。下面分别介绍一下。

一、屏蔽velocity log

干脆的办法。屏蔽之后该log不再打印了，但需要系统开发人员的配合。

二、不屏蔽，利用crontab定时删除velocity log

第一种方法固然很好，但需要外部人员配合，而且如果该vm的bug是由于压力引起，不打印日志没办法看到错误了。

crontab是一个很方便的在linux上定时循环执行某个任务的程序。利用它，可以定时将velocity log置空，将其控制在一定大小范围内。

先写一个置空log的shell脚本，然后再通过crontab调用，每隔5分钟执行一次。示例脚本如下：

***********************************************

cleanLog.sh ?放置在/home/admin目录下

echo “” > Path/appName-velocity.log ? Path为该应用的log路径，appName为该应用的应用名

***********************************************

crontab ?admin的crontab

*/5 * * * * sh /home/admin/cleanLog.sh ?实现每5分钟执行一次cleanLog.sh脚本

***********************************************

这两种方式都能有效的减小大量/超大量log对性能测试结果的影响。当然也各有利弊，请酌情使用。

除了vm的bug会大量记录错误日志外，apache的访问日志有时候也是非常非常恐怖的。如果你想减小影响，不妨也试试上述两种方法。