漫谈应用缓存的命中率问题 -买球官网平台

`
robbin
  • 浏览: 4765703 次
  • 性别:
  • 来自: 上海
博主相关
  • 博客
  • 微博
  • 相册
  • 收藏
  • 博客专栏
    robbin谈管理
    浏览量:132568
    社区版块
    • ( 265)
    • ( 6203)
    • ( 75)
    存档分类
    最新评论

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

      博客分类:
    • java
    这篇文章源自于:

    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。



    分享到:
    |
    评论
    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这个问题以达到100%精确,我想是不是用户请求第一个页面的时候才去查询的总记录数。中间页面的话,就不去查询总记录?
    20 楼 2007-05-10  
    kabbesy 写道

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

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


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


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

    这个可以靠业务逻辑相关的内存计数器来解决
    17 楼 2007-05-10  
    cherami 写道
    显示分页并不会对性能或者缓存造成太大的麻烦,最多是多了一个sql而已,取一个总体的记录数,这个可以通过开发架构解决。

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

    如果是用sql的话,虽然只是多了一个sql,但如果一个列表页显示50个帖子的话,就是多了50个sql
    16 楼 robbin 2007-05-10  
    downpour 写道
    全表扫描真的很难避免,尤其是项目一大,参与的人一多,基本上随便挑一挑就能找出全表扫描的sql。

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


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

    如果是ror去连接memcached,没有什么监控手段,那么我的办法也很直观,就是比较数据库的容量,如果数据库的数据容量达到了500mb,那么我就会给memcached开512mb的缓存空间。
    15 楼 2007-05-10  
    显示分页并不会对性能或者缓存造成太大的麻烦,最多是多了一个sql而已,取一个总体的记录数,这个可以通过开发架构解决。

    如果不提供就极大的限制了功能,不能因为技术而对功能进行限制!
    14 楼 2007-05-10  
    全表扫描真的很难避免,尤其是项目一大,参与的人一多,基本上随便挑一挑就能找出全表扫描的sql。

    我感觉缓存的容量是一个非常关键的数值,频繁的lru几乎就是缓存的杀手。不知道robbin在调整这个参数的时候是如何判断分析的。
    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 写道
    真正对数据库造成庞大压力的正是那些没有索引的大表查询,和造成了全表扫描的关联查询,这些一旦涉及到全表扫描的查询,才是性能的真正杀手。当然了,不管怎么说,通过使用对象缓存,是毫无疑问可以大幅度降低数据库的负载压力的,有效提升web应用的性能的。

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

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

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

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


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

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

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

    另外,想请教下对于新闻发布系统那种纯静态页面,apache有没有什么模块,可以判断静态页面是否存在,如果不存在,才给应用服务器发出请求
    7 楼 readonly 2007-05-09  
    janh 写道
    不认为这是无太大用处的功能,我就经常点中间的页数,如果第一次看这个帖子时只有4页,过了几天达到8页了,那我显然直接从第4页看起,一次一次点下一页岂不是麻烦,而且更浪费服务器资源,有时要看谁在第几页的发言当然也是直接点页数。

    偶是指不要把那么页数显示在分论坛的帖子列表中,在进入单个帖子的页面当然还是需要的。
    另外,偶的小脑袋哪能记住几天前看到第几页这种ooxx的事情,还要记住谁在第几页的发言简直是@#¥%...这种大肠帖都是点开最后一页,然后依靠回复时间来找到大致位置
    6 楼 2007-05-09  
    对象缓存是基本的
    对于很多应用,查询缓存才是最关键的
    尤其对web这种列表应用

    相关推荐

      计算机缓存漫谈.rar,计算机缓存漫谈.pptx

      net 4.0面向对象编程漫谈 应用篇(电子书),分享给大家,欢迎大家学习

      net 4.0面向对象编程漫谈 应用篇.pdf 个人收集电子书,仅用学习使用,不可用于商业用途,如有买球官网平台的版权问题,请联系删除!

      漫谈应用广泛的金属材料.pptx

      net 4.0面向对象编程漫谈 应用篇 值得阅读,对于初学者 是很不错的

      大厂高手骆俊武出品的《漫谈线上问题排查》电子书

      华为防火墙技术漫谈》介绍华为传统防火墙关键技术原理、应用场景和配置方法,主要包括安全策略、攻击防范、nat、双机热备、选路,并结合网上案例给出以上技术的综合应用配置举例,以防火墙网上实际需求为导向,采用...

      [net 4.0面向对象编程漫谈 应用篇].金旭亮---高清版.pdf 个人收集电子书,仅用学习使用,不可用于商业用途,如有买球官网平台的版权问题,请联系删除!

      谈兼容内核之一:reactos怎样实现系统调用.pdf 漫谈兼容内核之二:关于kernel -win32的对象管理.pdf 漫谈兼容内核之三:关于kernel-win32的文件操作.pdf 漫谈兼容内核之四:kernel-win32的进程管理.pdf 漫谈兼容内核...

      漫谈经济管理法律发展问题.doc

      华为防火墙技术漫谈,理论篇共包含十章,涵盖了会话与状态检测、安全策略、攻击防范、nat、gre 、l2tp 、ipsec 、ssl、双机热备、出口选路的原理、应用场景及配置方法

      01.漫谈兼容内核之一:wine的系统结构.pdf 02.漫谈兼容内核之二:关于kernel-win32的对象管理.pdf 03.漫谈兼容内核之三:关于kernel-win32的文件操作.pdf 04.漫谈兼容内核之四:kernel-win32的进程管理.pdf 05.漫谈...

      漫谈兼容内核之一:reactos怎样实现系统调用 漫谈兼容内核之二:关于kernel-win32的对象管理 漫谈兼容内核之三:kernel-win32的文件操作 漫谈兼容内核之四:kernel-win32的进程管理 漫谈兼容内核之五:kernel-win32...

      漫谈兼容内核之一:reactos怎样实现系统调用 漫谈兼容内核之二:关于kernel-win32的对象管理 漫谈兼容内核之三:kernel-win32的文件操作 漫谈兼容内核之四:kernel-win32的进程管理 漫谈兼容内核之五:kernel-win32...

      漫谈光电信息技术应用.pptx

      作者: (苏)ah吉洪诺夫 出版社: 湖南教育 出版时间: 1986 装帧: 平装 页数: 212页

      缓存一直是前端性能优化中,浓墨重彩的一笔。了解前端缓存是打造高性能网站的必要知识。之前,对于缓存的认知一直停留在看《http权威指南》和一些相关帖子的深度,过了一段时间,又总是忘记,正好最近不是很忙,结合...

      漫谈兼容内核 毛德操 完整版 pdf漫谈兼容内核 毛德操漫谈兼容内核 毛德操漫谈兼容内核 毛德操

    global site tag (gtag.js) - google analytics