|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-03-30
缓存实现的层面有很多：
1、对象缓存 由ORM框架提供，透明性访问，细颗粒度缓存数据库查询结果，无需业务代码显式编程。当软件结构按照ORM框架的要求进行针对性设计，使用对象缓存将会极大降低web系统对于数据库的访问请求。因为类似Hibernate这样的ORM，良好的设计数据库结构和利用对象缓存，在大负载网站，能够提供极高的性能。因为使用对象缓存也无需显式编程，所以适用范围也最广泛。 2、查询缓存 对数据库查询结果行集进行缓存，适用于一些耗时，但是时效性要求比较低的场景。iBATIS就只能使用查询缓存，而无对象缓存。查询缓存和对象缓存适用的场景不一样，是互为补充的。 3、片断缓存 针对动态页面的局部片断内容进行缓存，适用于一些个性化但不经常更新的页面(例如博客)。OSCache提供了相当简陋的片断缓存，而RoR则提供了相当好的片断缓存机制。 4、Action缓存 针对URL访问返回的页面结果进行缓存，适用于粗粒度的页面缓存，例如新闻发布。OScache提供了相当简陋的Action缓存(通过web.xml中的配置)，而RoR提供了相当好的Action缓存。 缓存不能一概而论，以上每种缓存分别适用于各自的场景，缓存不同的层面。当然你可以在应用程序当中把4种缓存一起用上。 |
| 返回顶楼 | |
|
发表时间：2007-03-30
giscat 写道 缓存是应用层的事，
缓存内容，缓存时间，缓存策略，缓存刷新等都可以交给应用层去解决 hibernate的缓存是一刀切，控制粒度是粗放型的 缓存这个东西不能滥用，要用在关键的地方 系统设计人员应该找出性能瓶颈，做出相应的缓存策略 而不是不管37二十一，啥东西都缓存一把 缓存不要滥用 缓存当然不能滥用,这也是为什么缓存设置很复杂, 但对于一些建议的配制通常还是很有效的 虽然不是很恰当,我还是拿手gc作比方,最好只是配制,不要渗透到代码. 当然,针对性地缓存也是解决之道,如提供自己的clusterlisteners之类,但还是不要渗透到具体的应用层代码中. |
| 返回顶楼 | |
|
发表时间：2007-03-30
downpour 写道 的确是这样，所以在这种情况下，一般会选择一个另外一个不同的缓存策略，比如OSCache。
由于我没有给系统加添jar包的权限,所以只能用现有的ehcache1.1,而且连换成1.2的要求我也没有提.我估计如果我说要换jar,ld们会让我用hashtable实现... |
| 返回顶楼 | |
|
发表时间：2007-03-30
robbin 写道 缓存实现的层面有很多：
1、对象缓存 由ORM框架提供，透明性访问，细颗粒度缓存数据库查询结果，无需业务代码显式编程。当软件结构按照ORM框架的要求进行针对性设计，使用对象缓存将会极大降低web系统对于数据库的访问请求。因为类似Hibernate这样的ORM，良好的设计数据库结构和利用对象缓存，在大负载网站，能够提供极高的性能。因为使用对象缓存也无需显式编程，所以适用范围也最广泛。 2、查询缓存 对数据库查询结果行集进行缓存，适用于一些耗时，但是时效性要求比较低的场景。iBATIS就只能使用查询缓存，而无对象缓存。查询缓存和对象缓存适用的场景不一样，是互为补充的。 3、片断缓存 针对动态页面的局部片断内容进行缓存，适用于一些个性化但不经常更新的页面(例如博客)。OSCache提供了相当简陋的片断缓存，而RoR则提供了相当好的片断缓存机制。 4、Action缓存 针对URL访问返回的页面结果进行缓存，适用于粗粒度的页面缓存，例如新闻发布。OScache提供了相当简陋的Action缓存(通过web.xml中的配置)，而RoR提供了相当好的Action缓存。 缓存不能一概而论，以上每种缓存分别适用于各自的场景，缓存不同的层面。当然你可以在应用程序当中把4种缓存一起用上。 还是robbin专业,呵呵 hibernate二级缓存支持1,2,而且经过严格的测试 oscache支持3,4,当然,hibernate的二级缓存极可能就是用的oscache 另外,对于一些小型应用,缓存可能根本起不了作用. 不知javaeye怎么是怎样的一个缓存策略? |
| 返回顶楼 | |
|
发表时间：2007-03-30
giscat 写道 缓存是应用层的事，
缓存内容，缓存时间，缓存策略，缓存刷新等都可以交给应用层去解决 hibernate的缓存是一刀切，控制粒度是粗放型的 缓存这个东西不能滥用，要用在关键的地方 系统设计人员应该找出性能瓶颈，做出相应的缓存策略 而不是不管37二十一，啥东西都缓存一把 缓存不要滥用 各位刚才的论述给了我1点启发,就是还可以利用页面缓存的方式来处理我遇到的问题. 我现在的处理方式,觉得是robbin所说的对查询结果进行缓存,结果集通过jdbc得到,所以无法使用ibatis(我们的项目是hibernate、jdbc混用). 使用缓存的地方我可能没说清楚,我们有6个表,每张的数据量应该不到千万吧,组成数张视图和实体视图(material view)供查询,而我们的程序再过滤一些条件对这些视图做查询(使用jdbc,查询sql已优化).但我们在一个web页面上会对其中的一张视图做近30次不同条件的查询,并对每个查询结果做汇总(count),在访问量小的时候还好,但是在刚上班有个高峰期,易造成数据库压力大(数据库还有其他工作),于是我们对这些汇总的结果做缓存. 看了刚才大家的回答,我觉得页面缓存可能是个更好的解决方式,需要试一下. |
| 返回顶楼 | |
|
发表时间：2007-03-30
robbin 写道 缓存实现的层面有很多：
1、对象缓存 由ORM框架提供，透明性访问，细颗粒度缓存数据库查询结果，无需业务代码显式编程。当软件结构按照ORM框架的要求进行针对性设计，使用对象缓存将会极大降低web系统对于数据库的访问请求。因为类似Hibernate这样的ORM，良好的设计数据库结构和利用对象缓存，在大负载网站，能够提供极高的性能。因为使用对象缓存也无需显式编程，所以适用范围也最广泛。 2、查询缓存 对数据库查询结果行集进行缓存，适用于一些耗时，但是时效性要求比较低的场景。iBATIS就只能使用查询缓存，而无对象缓存。查询缓存和对象缓存适用的场景不一样，是互为补充的。 3、片断缓存 针对动态页面的局部片断内容进行缓存，适用于一些个性化但不经常更新的页面(例如博客)。OSCache提供了相当简陋的片断缓存，而RoR则提供了相当好的片断缓存机制。 4、Action缓存 针对URL访问返回的页面结果进行缓存，适用于粗粒度的页面缓存，例如新闻发布。OScache提供了相当简陋的Action缓存(通过web.xml中的配置)，而RoR提供了相当好的Action缓存。 缓存不能一概而论，以上每种缓存分别适用于各自的场景，缓存不同的层面。当然你可以在应用程序当中把4种缓存一起用上。 robbin推荐的ror的缓存机制个人很感兴趣,但是在这个项目里没法用了  .自己还是买了<应用rails进行敏捷开发>第一版来学习一下.
|
| 返回顶楼 | |
|
发表时间：2007-03-30
性能的瓶颈找出来了
对于耗时耗资源的操作做个缓存,效果肯定很明显 model = xx.getModel(); 如果获取model的过程很耗时耗资源，对这个结果集缓存即可 至于缓存框架，有很多第三方的开源软件 也可以自己整，一个简单实用的缓存框架核心代码200行左右 |
| 返回顶楼 | |
|
发表时间：2007-03-30
giscat 写道 性能的瓶颈找出来了
对于耗时耗资源的操作做个缓存,效果肯定很明显 model = xx.getModel(); 如果获取model的过程很耗时耗资源，对这个结果集缓存即可 至于缓存框架，有很多第三方的开源软件 也可以自己整，一个简单实用的缓存框架核心代码200行左右 的确问题找到了,效果肯定是很明显了,从DBA到用户都不抱怨了. 自己整个缓存框架个人觉得没有必要,有重复发明轮子之嫌  .
刚才和boss谈过,他认为做页面缓存也可以,但是现在不必要,要做别的事!呵呵,此问题暂告一段落. |
| 返回顶楼 | |
|
发表时间：2007-03-30
MVC ，缓存model即可
|
| 返回顶楼 | |
|
发表时间：2007-03-30
其实可以把部分内容静态化，然后include
|
| 返回顶楼 | |
