漫谈应用缓存的命中率问题

robbin讲的都是对象缓存，想冒昧请问一下，javaeye使用了页面缓存吗？对于页面缓存，那么是算作粗粒度还是细粒度呢？这样做的也应该可以控制到比较高的命中率吧，和对象缓存相比，两者各有什么优劣，或者说两者一起使用是否能够做到比单纯的对象缓存更好呢？

在我们做过的一个web项目中，是通过模版生成伪静态页面，说它是伪静态，是因为这个页面本身也是一个模版，在生成最终页面呈现给用户时，会填入一些动态的数据，就比如这个论坛的投票数量什么的。相当于磁盘缓存了，但这个是应用服务器的本地磁盘，速度上很快，而且避免了服务器之间的网络通信。比如论坛里每个帖子的文章内容，不需要再去数据库或者缓存里取，这样是不是能减少与memcached通信的流量呢。

web应用多数都是查询大于数据操作，那么cache用于解决性能是屡试不爽，但是对于插入，更新频繁的企业应用，一般是应该从哪方面去解决的呢。

另外，想请教下对于新闻发布系统那种纯静态页面，apache有没有什么模块，可以判断静态页面是否存在，如果不存在，才给应用服务器发出请求

mod_rewrite 是可以的

另外，偶的小脑袋哪能记住几天前看到第几页这种OOXX的事情，还要记住谁在第几页的发言简直是@#￥%...这种大肠帖都是点开最后一页，然后依靠回复时间来找到大致位置

http://robbin.iteye.com/blog/66582

真正对数据库造成庞大压力的正是那些没有索引的大表查询，和造成了全表扫描的关联查询，这些一旦涉及到全表扫描的查询，才是性能的真正杀手。当然了，不管怎么说，通过使用对象缓存，是毫无疑问可以大幅度降低数据库的负载压力的，有效提升web应用的性能的。

关于这一点，我再给出一组数据来加深大家的印象，通过使用操作系统网络工具进行统计：

JavaEye网站web server的端口每秒数据流量是2MB；
JavaEye网站的MySQL数据库端口的每秒数据流量是1.2MB；
而网站的memcached的端口每秒的数据流量高达5MB。

robbin这个解释很清楚了。就是说对象缓存最起作用的是数据库无能为力的地方。
这点我完全同意。

那么另外一个疑问：
全表扫描是相当相当可怕的。也许在几万条记录的表里面还无所谓，但是如果是上百万条的表，那么一个select要等上十秒二十秒不算什么新闻。
可是，不管缓存如何，第一次总要query数据库的。那么用户在第一次的时候还是要经过漫长的等待的。这样似乎也不太理想。我总觉得遇到这种情况，最根本的解决方法是优化数据库，建索引也好，冗余也好，改变对象设计也好，总之目标是干掉全表扫描。而如果这么干了，那么回过头来，对象缓存的作用就又被稀释了。

全表扫描真的很难避免，尤其是项目一大，参与的人一多，基本上随便挑一挑就能找出全表扫描的SQL。

我感觉缓存的容量是一个非常关键的数值，频繁的LRU几乎就是缓存的杀手。不知道Robbin在调整这个参数的时候是如何判断分析的。

显示分页并不会对性能或者缓存造成太大的麻烦，最多是多了一个SQL而已，取一个总体的记录数，这个可以通过开发架构解决。

如果不提供就极大的限制了功能，不能因为技术而对功能进行限制！

如果是用sql的话，虽然只是多了一个sql，但如果一个列表页显示50个帖子的话，就是多了50个sql

如果是用sql的话，虽然只是多了一个sql，但如果一个列表页显示50个帖子的话，就是多了50个sql