以前做的一个有关Page Cache方面的测试，今天提出来说说我的测试方法，希望对读者有所帮助。

　　问题回顾

　　由于网站被频繁请求的页面为动态生成WEB页，导致消耗大量系统资源，为了提高用户对此类网页访问的响应时间，采用对其该部分页面使用Cache技术。

　　对于这种类型的测试其实很简单，只要求测试人员做到以下两点就完全可以应付：

　　1、对Cache在业务中的实现规则有充分了解（具体说来就是，有哪些页面使用了Cache，Cache的有效时间长度为多少，被测服务器端物理内存为多少，分配了多少空间给了Cache）。

　　2、理解在测试过程中需要重点关注的相关性能计数器（例如内存）。

　　测试第一步，验证

　　验证Cache是否存在，是否满足实现规则。例如访问一个已经加有Cache的动态页面，第一次请求的页面响应时间为10秒，第二次为3秒，90 Percent 的响应时间不大于4秒，那么我们暂时可以认为Cache生效。在随后的测试过程中，使用ramp -up 方法对Cache进行测试，看到response time结果大致为，当第一个线程访问该页面时，RPT在一个很高的起点上，因为这时Web 服务器必须访问数据库，并生成页面，再将其存储在缓存中，这个过程消耗了大部分RPT，运行到第二线程时RPT成曲线下降到一个很低的点上，这是因为第二线程直接从内存中的Cache里读到了所需的页，这个点和随后增加的线程几乎在同一水平线上，平稳延续，当场景运行到20分钟左右，正好是到了Cache生命周期结束的时间点上，重复以上描述RPT曲线轨迹。在这里RPT不是随着用户的上升而上升，给人的感觉象是使用了COOKIE。

　　测试第二步，并发

　　通过设置并发点对同一动态页面的访问，测试Cache是否有等待时间过长的现象。因为第一到达目的地的线程会先到内存中存储它访问完数据库并生成完页面的缓存，这个时候其他线程只有乖乖等待第一线程做完写操作后方可进行读操作，大家知道一个线程在一次操作过程中只允许有写或者是读的权限，两种权限不允许在一个线程内同时进行，如果程序中的线程同步锁处理的不够好，那么可能会导致意外情况发生。例如在多用户同时访问该页面时，可能会出现所有线程请求失败，遇到这种情况，测试人员可以先多尝试用串行或者不加并发点进行测试并得出结论。根据经验遇到这种问题大多数为线程同步机制出现问题所导致。在测试过程中要更多关注WEB SERVER 的内存计数器其中包括（页交换比率\ pages reads\ private byte\ working set ）如果缓存命中率底，那么内存页交换和pages reads会很高，如果大用户量访问，内存不能及时释放空间，则 working set和private byte会很高，如果怀疑有memory leak现象，可以把其他相关业务同时加上，把执行场景的时间拉长一些，看对其他业务的影响程度。在这里Cache的命中率是Cache的关键问题，如对以上计数器不是很理解还请查一下相关帮助文件，在这里就不做过多解释了。

　　使用Cache的优点

　　节省生成页面时所消耗的CPU和内存资源。对于大用户量的访问使RPT一样变的很短。

　　对数据库的压力减少是显而易见.我个人觉得这个是最重要优势。

　　对于最终用户和服务器之间，用户的请求时间变短了，那么就缩小了服务器的资源浪费。