漫谈应用缓存的命中率问题 -欧洲杯足彩官网

robbin

浏览: 4793707 次
性别:
来自: 上海

博主相关

博客

微博

相册

博客专栏

: robbin谈管理
浏览量：135363

文章分类

社区版块

( 265)
( 6203)
( 75)

存档分类

2012-12 ( 2)
2012-11 ( 1)
2012-09 ( 1)

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

博客分类：

java

网络应用企业应用应用服务器 sql sql server

这篇文章源自于：

http://www.iteye.com/topic/77195

其中很多人谈到了缓存命中率的问题，应用缓存的命中率取决于很多的因素：

1、应用场景
是oltp还是olap应用，即使是oltp，也要看访问的频度，一个极少被访问到的缓存等于没有什么效果。一般来说，互联网网站是非常适合缓存应用的场景。

2、缓存的粒度
毫无疑问，缓存的粒度越小，命中率就越高，对象缓存是目前缓存粒度最小的，因此被命中的几率更高。举个例子来说吧：你访问当前这个页面，浏览帖子，那么对于orm来说，需要发送n条sql，取各自帖子user的对象。很显然，如果这个user在其他帖子里面也跟贴了，那么在访问那个帖子的时候，就可以直接从缓存里面取这个user对象了。

3、架构的设计
架构的设计对于缓存命中率也有至关重要的影响。例如你应该如何去尽量避免缓存失效的问题，如何尽量提供频繁访问数据的缓存问题，这些都是考验架构师水平的地方。再举个例子来说，对于论坛，需要记录每个topic的浏览次数，所以每次有人访问这个topic，那么topic表就要update一次，这意味着什么呢？对于topic的对象缓存是无效的，每次访问都要更新缓存。那么可以想一些办法，例如增加一个中间变量记录点击次数，每累计一定的点击，才更新一次数据库，从而减低缓存失效的频率。

4、缓存的容量和缓存的有效期
缓存太小，造成频繁的lru，也会降低命中率，缓存的有效期太短也会造成缓存命中率下降。

所以缓存命中率问题不能一概而论，一定说命中率很低或者命中率很高。但是如果你对于缓存的掌握很精通，有意识的去调整应用的架构，去分解缓存的粒度，总是会带来很高的命中率的。

这里我可以举一个实际的案例，javaeye2.0网站在使用对象缓存之前，通过mysql的监控工具进行观察，在连续24小时的平均每秒发送sql条数超过了200条，在使用对象缓存之后，连续24小时的平均每秒发送sql条数下降到了120条左右，几乎下降了一半。

考虑到很多sql都是分页语句，关联查询，条件查询，集合操作，都是不能被缓存的sql，而真正能够被缓存的sql只有根据主键查询对象和对象关联对象的查询。所以真正能够被缓存的sql估计最多占所有sql的60%。所以换算下来，应用缓存的命中率之高，已经相当惊人了。

不过这里要提醒的一点，有将近一半的sql都被缓存，不意味着性能可以提升一倍。这是因为能够被缓存的都是按照主键查询单条记录的sql，这些sql本身即使发送到数据库，对数据库造成的压力也没有想像的那么大。真正对数据库造成庞大压力的正是那些没有索引的大表查询，和造成了全表扫描的关联查询，这些一旦涉及到全表扫描的查询，才是性能的真正杀手。当然了，不管怎么说，通过使用对象缓存，是毫无疑问可以大幅度降低数据库的负载压力的，有效提升web应用的性能的。

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

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

分享到：

2007-05-09 14:19
浏览 26160
评论(25)
论坛回复 / (24 / 25183)
分类:企业架构

25 楼 zweite 2014-02-08

直接对搜索的结果进行缓存是不是会更快一点呢

24 楼 2007-05-21

robbin 写道

不过这里要提醒的一点，有将近一半的sql都被缓存，不意味着性能可以提升一倍。这是因为能够被缓存的都是按照主键查询单条记录的sql，这些sql本身即使发送到数据库，对数据库造成的压力也没有想像的那么大。真正对数据库造成庞大压力的正是那些没有索引的大表查询，和造成了全表扫描的关联查询，这些一旦涉及到全表扫描的查询，才是性能的真正杀手。

深有感触，索引如果没建好，简直就是灾难，其它的优化都是空谈

23 楼 2007-05-17

downpour 写道

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

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

memcached 有一个 stats 命令，可以查看到它自启动之后的一些统计值，里面有命中次数（get_hits）和失败（get_misses）次数。

bash-2.05a$ telnet 0 11211
stats
stat rusage_user 0.770000
stat rusage_system 75.630000
stat curr_items 291984
stat total_items 500000
stat cmd_get 500000
stat cmd_set 500000
stat get_hits 291984
stat get_misses 208016
end

22 楼 2007-05-10

搜索的话，分页结果差异比较大很难确定，可如果是主题列表，回帖列表，那么不是结果很稳定么。

21 楼 2007-05-10

cherami 写道

kabbesy 写道

对于论坛，大部分功能集中在list、bykey，count
其中count部分又属于易失性的，普通的对象缓存是不适合的，当然50个count（*）就更不适合了

这个可以靠业务逻辑相关的内存计数器来解决

用于分页的count不需要考虑易失性，大数据，频繁更新的数据，查询都是有一个短暂的有效性的，google也无法解决这个问题。100％的精确对于大数据量而且频繁更新的系统而言是不可能的

嗯。确实没有好办法解决分页的count这个问题以达到１００％精确，我想是不是用户请求第一个页面的时候才去查询的总记录数。中间页面的话，就不去查询总记录?

20 楼 2007-05-10

kabbesy 写道

19 楼 2007-05-10

chenqj 写道

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

晕，这个是什么逻辑啊，我说的多一个sql是取全部匹配的记录数，用于计算总共的页数，而且这个sql是共通的，就是在正常的记录查询上包一层

一个列表显示50个帖子，这个也是一个sql而已，如果是用hibernate的缓存机制的话，才可能是50次执行。

18 楼 2007-05-10

chenqj 写道

cherami 写道

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

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

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

17 楼 2007-05-10

cherami 写道

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

16 楼 robbin 2007-05-10

downpour 写道

java的缓存一般是有接口来进行统计的，可以自己编程来监控缓存的命中率。例如confluence自己就在后台提供了缓存命中率的统计监控数据。可以根据命中率来调整缓存大小。

如果是ror去连接memcached，没有什么监控手段，那么我的办法也很直观，就是比较数据库的容量，如果数据库的数据容量达到了500mb，那么我就会给memcached开512mb的缓存空间。

15 楼 2007-05-10

14 楼 2007-05-10

13 楼 robbin 2007-05-09

ajoo 写道

robbin 写道

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

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

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

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

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

全表的扫描不见得能够全部消除掉，很多时候还是不得不写全表扫描的sql。

12 楼 2007-05-09

robbin 写道

11 楼 2007-05-09

kdekid 写道

yfmine 写道

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

mod_rewrite 是可以的

谢谢，刚才查了文档，rewritecond -s可以...

readonly 写道

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

帖子太多,记不住,所以头就大了,所以就记住了......

robbin 写道

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

谢谢robbin,跑题了,不好意思...

10 楼 robbin 2007-05-09

yfmine 写道

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

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

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

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

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

9 楼 2007-05-09

yfmine 写道

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

mod_rewrite 是可以的

8 楼 2007-05-09

7 楼 2007-05-09

janh 写道

不认为这是无太大用处的功能，我就经常点中间的页数，如果第一次看这个帖子时只有4页，过了几天达到8页了，那我显然直接从第4页看起，一次一次点下一页岂不是麻烦，而且更浪费服务器资源，有时要看谁在第几页的发言当然也是直接点页数。

偶是指不要把那么页数显示在分论坛的帖子列表中，在进入单个帖子的页面当然还是需要的。
另外，偶的小脑袋哪能记住几天前看到第几页这种ooxx的事情，还要记住谁在第几页的发言简直是@#￥%...这种大肠帖都是点开最后一页，然后依靠回复时间来找到大致位置

6 楼 2007-05-09

对象缓存是基本的
对于很多应用，查询缓存才是最关键的
尤其对web这种列表应用

« 上一页 1

发表评论

您还没有登录,请您登录后再发表评论

漫谈应用缓存的命中率问题 -欧洲杯足彩官网

最近访客

博主相关

博客专栏

文章分类

社区版块

存档分类

最新评论

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

评论

发表评论

相关推荐

漫谈应用缓存的命中率问题 -欧洲杯足彩官网

最近访客

博主相关

博客专栏

文章分类

社区版块

存档分类

最新评论

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

评论

发表评论

相关推荐

webobjects的来龙去脉