cache测试点

了解cache在业务中的实现规则，那些业务使用了cache,有效时间长度是多少，被测服务器端物理内存为多少，分配了多少空间给了cache

了解正在测试过程中需要重点关注的相关的性能计数器（如内存）

测试第一步，验证

验证cache是否存在，是否满足实现规则。例如访问一个已经加有cache的动态页面，第一次请求的页面响应时间为10秒，第二次为3秒，90Percent 的响应时间不大于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一样变的很短。

对数据库的压力减少是显而易见。

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