在Web应用中，有些报表的生成可能需要数据库花很长时间才能计算出来；有的网站提供天气信息，它需要访问远程服务器进行SOAP调用才能得到温度信息。所有这一切都属于复杂信息的例子。在Web页面中加入过多的复杂信息可能导致Web服务器、数据库服务器负荷过重。JSP代码块缓冲为开发者带来了随意地增加各种复杂信息的自由。
JSP能够在标记库内封装和运行复杂的Java代码，它使得JSP页面文件更容易维护，使得非专业开发人员使用JSP页面文件更加方便。现在已经有许多标记库，它们或者是商业产品，或者是源代码开放产品。但这些产品中的大多数都只是用标记库的形式实现原本可以用一个简单的Java Scriptlet实现的功能，很少有产品以某种创造性的方式使用定制标记，提供在出现JSP定制标记库之前几乎不可能实现的用法。
OSCache标记库由OpenSymphony设计，它是一种开创性的JSP定制标记应用，提供了在现有JSP页面之内实现快速内存缓冲的功能。虽然已经有一些供应商在提供各种形式的缓存产品，但是，它们都属于面向特定供应商的产品。OSCache能够在任何JSP 1.1兼容的服务器上运行，它不仅能够为所有用户缓冲现有JSP代码块，而且能够以用户为单位进行缓冲。OSCache还包含一些提高可伸缩性的高级特性，比如：缓冲到磁盘，可编程的缓冲刷新，异常控制，等等。另外，正如OpenSymphony的其他产品，OSCache的代码也在一个开放源代码许可协议之下免费发行。
本文以一个假想的拍卖网站设计过程为例，介绍OSCache的工作过程。这个假想的Web网站将包含：
1 ：一个报告最近拍卖活动的管理页面；
2 ：一个功能完整、带有各种宣传信息的主页；
3 ：一个特殊的导航条,包含了用户所有尚未成交的拍卖活动信息。
二、管理页面
拍卖网站包含一个管理报表，数据库服务器需要数秒时间才能创建这样一个报表。报表生成时间长这一点很重要，因为我们可能让多个管理员监视系统运行情况，同时又想避免管理员每次访问时都重新生成这个报表。为了实现这一点，我们将把整个页面封装到一个应用级的缓冲标记之内，这个缓冲标记每隔1小时刷新。其他供应商提供的一些产品也具有类似的功能，只是OSCache比它们做得更好。
为简单计，我们将不过多地关注格式问题。在编写管理页面时，我们首先把标记库声明加入到页面：
<%@ taglib uri="cachetags" prefix="cache" %>
接下来我们要用cache标记来包围整个页面。cache标记的默认缓冲时间是1小时。
<cache:cache> .... 复杂的管理报表 .... </cache:cache>
现在管理页面已经被缓冲。如果管理员在页面生成后的一个小时之内再次访问同一页面，他看到的将是以前缓存的页面，不需要由数据库服务器再次生成这个报表。
三、主页
拍卖网站的主页显示网站活动情况，宣传那些即将结束的拍卖活动。我们希望显示出正在进行的拍卖活动数量，当前登录用户数量，在短期内就要结束的拍卖活动的清单，以及当前时间。这些信息有着不同的时间精确度要求。网站上的拍卖活动通常持续数天，因此我们可以把缓冲有效拍卖活动数量的时间定为6个小时。用户数量的变化显然要频繁一些，但这里我们将把这个数值每次缓冲15分钟。最后，我们希望页面中显示的当前时间总是精确的页面访问时间。
在主页中声明标记库之后，我们首先以不带缓冲的方式直接输出当前日期：
现在是：<%=new java.util.Date()%>
接下来，我们要显示一个清单，列出那些将在短期内结束的拍卖活动：
<cache:cache> <ul> <% // 构造一个包含最近拍卖活动的Iterator Iterator auctions = .... while (auctions.hasMore()) { Auction auction = (Auction)auctions.next(); %><li><%=auction%></li%< } %> </ul> </cache:cache>
最后，我们希望显示出正在进行的拍卖活动的数量，这个数字需要缓冲6小时。由于cache标记需要的是缓冲数据的秒数，我们把6小时转换成21600秒：
<cache:cache time="21600"> <% //查询数据库得到拍卖活动总数 int auctionCount = .... %> 本网站正在进行的拍卖活动有<%=auctionCount%>个! </cache>
可以看到，我们只用少量的代码就构造出了一个带有复杂缓冲系统的主页。这个缓冲系统对页面各个部分分别进行缓冲，而且各个部分的缓冲时间完全符合它们各自的信息变化频繁程度。由于有了缓冲，现在我们可以在主页中放入更多的内容；而在以前没有缓冲的情况下，主页中放入过多的内容会导致页面访问速度变慢，甚至可能给数据库服务器带来过重的负载。
四、导航条
假设在规划网站的时候，我们决定在左边导航条的下方显示购物车内容。我们将显示出用户所拍卖的每一种商品的出价次数和当前报价，以及所有那些当前用户出价最高的商品的清单。
我们利用会话级的缓冲能力在导航条中构造上述功能。把下面的代码放入模板或者包含文件，以便网站中的其他页面引用这个导航条：
<cache:cache key="navbar" scope="session" time="300"> <% //提取并显示当前的出价信息 %> </cache:cache>
在这里我们引入了两个重要的属性，即key和scope。在本文前面的代码中，由于cache标记能够自动为代码块创建唯一的key，所以我们不需要手工设置这个key属性。但在这里，我们想要从网站的其余部分引用这个被缓冲的代码块，因此我们显式定义了该cache标记的key属性。第二， scope属性用来告诉cache标记当前代码块必须以用户为单位缓冲，而不是为所有用户缓冲一次。
在使用会话级缓冲时应该非常小心，应该清楚：虽然我们可以让复杂的导航条减少5倍或10倍的服务器负载，但它将极大地增加每个会话所需要的内存空间。在CPU能力方面增加可能的并发用户数量无疑很理想，但是，一旦在内存支持能力方面让并发用户数量降低到了CPU的限制之下，这个方案就不再理想。
正如本文前面所提到的，我们希望从网站的其余部分引用这个缓冲的代码块。这是因为，当一个用户增加了一个供拍卖的商品、或者出价竞购其他用户拍卖的商品时，我们希望刷新缓冲，使得导航条下一次被读取时具有最新的内容。虽然这些数据可能因为其他用户的活动而改变，但如果用户在网站上执行某个动作之后看到自己的清单仍未改变，他可能会感到非常困惑。
OSCache库提供的flush标记能够刷新缓冲内容。我们可以把下面的代码加入到处理用户动作且可能影响这一区域的页面之中：
<cache:flush key="navbar" scope="session" />
当用户下次访问它时，navbar缓冲块将被刷新。
至此为止，我们这个示例网站的构造工作已经完成且可以开始运行。下面我们来看看OSCache的异常处理能力。即使缓冲的内容已经作废，比如在缓冲块内出现了Java异常，OSCache标记库仍旧允许我们用编程的方法显示这些内容。有了这种异常控制功能，我们可以拆除数据库服务器和Web服务器之间的连接，而网站仍能够继续运行。JSP 1.2规范引入了TryCatchFinally接口，这个接口允许标记本身检测和处理Java异常。因此，标记可以结合这种异常处理代码，使得JSP页面更简单、更富有条理。
OpenSymphony正在计划实现其他的缓冲机制以及一个可管理性更好的主系统，它将使我们能够对缓冲使用的RAM和磁盘空间进行管理。一旦有了这些功能，我们就能够进一步提高网站的响应速度和可靠性。
使用范例:
oscache.properties 文件配置向导
cache.memory
值为true 或 false ，默认为在内存中作缓存，
如设置为false，那cache只能缓存到数据库或硬盘中，那cache还有什么意义：）
cache.capacity
缓存元素个数
cache.persistence.class
持久化缓存类，如此类打开，则必须设置cache.path信息
cache.cluster 相关
为集群设置信息。
如
cache.cluster.multicast.ip为广播IP地址
cache.cluster.properties为集群属性
上面定义将缓存所有.jsp页面，缓存刷新时间为60秒，缓存作用域为Session
注意，CacheFilter只捕获Http头为200的页面请求，即只对无错误请求作缓存，
而不对其他请求（如500,404,400）作缓存处理
【结束语】OSCache能够帮助我们构造出更丰富多彩、具有更高性能的网站。有了OSCache标记库的帮助，现在我们能够用它解决一些影响网站响应能力的问题，比如访问量高峰期、数据库服务器负荷过重等。
个人提示：如果你使用Struts或者其它mvc架构很难享受到oscache tag带来的性能提高，因为每一次请求还是要提交到action--dao-or othere thing去处理，因此，要使用缓存，就需要其它手段，如在spring的拦截器做方法级的缓存.....,如果你所有的的业务处理代码是写在jsp页面中，就可以使用cache tag来缓存前面产生的页面数据，避免做相同的业务操作
用缓冲技术提高JSP应用的性能和稳定性之OSchche应用（3）
Oscache
特点
缓存任何对象，你可以不受限制的缓存部分jsp页面或HTTP请求，任何java对象都可以缓存。
拥有全面的API--OSCache API给你全面的程序来控制所有的OSCache特性。
永久缓存--缓存能随意的写入硬盘，因此允许昂贵的创建（expensive-to-create）数据来保持缓存，甚至能让应用重启。
支持集群--集群缓存数据能被单个的进行参数配置，不需要修改代码。
缓存记录的过期--你可以有最大限度的控制缓存对象的过期，包括可插入式的刷新策略（如果默认性能不需要时）。
上一篇讲到如何配置oschche下面介绍如何应用：
1 建立一个**Bean的缓存类**Cache.
2 import com.opensymphony.oscache.general.*;import com.opensymphony.oscache.base.*;
3 建立一个**DAO类以便操作数据库(也可将上两项的内容直接合并到这里).
4 在**Cache类里生成一个GeneralCacheAdministrator的实例admin用来管理缓存.
GeneralCacheAdministrator admin = new GeneralCacheAdministrator();
5 **Cache中的方法 如.clear(),flush().基本调用的为OSCache的 Java API.
6 在**Cache添加getBeans()和getBean()方法 以便获取缓存中的实例对象.具体实现可参照上面的例子.
7 主要用到的GeneralCacheAdministrator的方法有
public Object getFromCache(String key) throws NeedsRefreshException; -- 从缓存中获取一个key标识的对象.
public Object getFromCache(String key, int refreshPeriod) throws NeedsRefreshException ; -- 从缓存中获取一个key标识的对象. refreshPeriod刷新周期,标识此对象在缓存中保存的时间(单位:秒)
注意:
如果一个NeedsRefreshException出现 必须调用admin.putInCache或admin.cancelUpdate来避免死锁情况发生.
OSCache的使用主要有4种：
1.POJO 缓存
2.HTTP Response 缓存
3.JSP Tag Library 缓存
4.O/R Data Access 缓存
1、POJO 缓存
这种方式的缓存直接调用OSCache的API进行，主要用于处理页面内容会根据参数动态改变，可以将参数设置为key值来保存数据：
首先，声明成员变量：
// OSCache Adminitrator instance
private static GeneralCacheAdministrator cacheAdmin = null;
其次，进行初始化：
public RingArtistAction() {
cacheAdmin = new GeneralCacheAdministrator();
}
将POJO进行缓存：
// Cache data key and refresh period
String key = sex + ":" + place;
int refreshPeriod = Constants.getIntegerValue(Constants.OSCACHE_REFRESH_PERIOD).intValue();
try {
// Get from the cache
artists = (Map) cacheAdmin.getFromCache(key, refreshPeriod);
} catch (NeedsRefreshException nre) {
try {
// Get the value (probably from the database)
int count = getArtistCount(sex, place, errors);
artists = getArtistData(sex, place, count, errors);
// Store in the cache
cacheAdmin.putInCache(key, artists);
} catch (Exception ex) {
// We have the current content if we want fail-over.
artists = (Map) nre.getCacheContent();
// It is essential that cancelUpdate is called if the
// cached content is not rebuilt
cacheAdmin.cancelUpdate(key);
ex.printStackTrace();
}
}
POJO(简单Java对象)缓存。一个POJO缓存是一个系统——它担当一个"面向对象的"分布式的缓存。在这个系统中，一旦一个用户把POJO依附到该缓存上，那么缓冲方面(例如复制和持续性)应该对用户是透明的。一个用户只需简单地在该POJO上操作而不须担心更新该缓存内容或维持对象关系的问题。不存在显式的API调用可用来管理该缓存。
2、HTTP Response 缓存
这种方式的缓存用来处理整个页面的内容固定，不会根据参数动态改变：
首先在web.xml中配置CacheFilter：
<filter>
<filter-name>CacheFilter</filter-name>
<filter-class>com.opensymphony.oscache.web.filter.CacheFilter</filter-class>
<init-param>
<param-name>time</param-name>
<param-value>86400</param-value>
</init-param>
<init-param>
<param-name>scope</param-name>
<param-value>application</param-value>
</init-param>
</filter>
将所有需要缓存的页面加入filter-mapping：
<filter-mapping>
<filter-name>Set Character Encoding</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
注意，只有返回状态为200（HttpServletResponse.SC_OK）的内容才会被缓存
HTTP中缓存的目的是为了在很多情况下减少发送请求，也即直接返回缓存；同时在许多情况下可以不需要发送完整响应。前者减少了网络回路的数量，挺高响应速度，HTTP利用一个“过期（expiration）”机制来为此目的。后者减少了网络应用的带宽，HTTP用“验证（validation）”机制来为此目的。
HTTP定义了3种缓存机制：
l Freshness allows a response to be used without re-checking it on the origin server, and can be controlled by both the server and the client. For example, the Expires response header gives a date when the document becomes stale, and the Cache-Control: max-age directive tells the cache how many seconds the response is fresh for.
l Validation can be used to check whether a cached response is still good after it becomes stale. For example, if the response has a Last-Modified header, a cache can make a conditional request using the If-Modified-Since header to see if it has changed.
l Invalidation is usually a side effect of another request that passes through the cache. For example, if URL associated with a cached response subsequently gets a POST, PUT or DELETE request, the cached response will be invalidated.
HTTP Response缓存如何工作
所有的缓存都用一套规则来帮助他们决定什么时候使用缓存中的副本提供服务（假设有副本可用的情况下）；一些规则在协议中有定义（HTTP协议1.0和1.1），一些规则由缓存的管理员设置（浏览器的用户或者代理服务器的管理员）；
一般说来：遵循以下基本的规则（不必担心，你不必知道所有的细节，细节将随后说明）
1.如果响应头信息：告诉缓存器不要保留缓存，缓存器就不会缓存相应内容；
2.如果请求信息是需要认证或者安全加密的，相应内容也不会被缓存；
3.如果在回应中不存在校验器（ETag或者Last-Modified头信息），缓存服务器会认为缺乏直接的更新度信息，内容将会被认为不可缓存。
4.一个缓存的副本如果含有以下信息：内容将会被认为是足够新的 ◦含有完整的过期时间和寿命控制头信息，并且内容仍在保鲜期内；
◦浏览器已经使用过缓存副本，并且在一个会话中已经检查过内容的新鲜度；
◦缓存代理服务器近期内已经使用过缓存副本，并且内容的最后更新时间在上次使用期之前；
◦够新的副本将直接从缓存中送出，而不会向源服务器发送请求；
5.如果缓存的副本已经太旧了，缓存服务器将向源服务器发出请求校验请求，用于确定是否可以继续使用当前拷贝继续服务；
总之：新鲜度和校验是确定内容是否可用的最重要途径：
如果副本足够新，从缓存中提取就立刻能用了；
而经缓存器校验后发现副本的原件没有变化，系统也会避免将副本内容从源服务器整个重新传输一遍。
3、JSP Tag 缓存
JSP Tag缓存主要用于缓存JSP页面的局部内容：
<cache:cache key="especialcategory" cron="* 5 * * *">
<jsp:include page="/ringcategory.do" flush="true" >
<jsp:param name="ringType" value="1"/>
</jsp:include>
</cache:cache>
页面缓存通常采用oscache来进行实现，oscache提供了一个jsp tag，可通过这个tag来包含需要缓存的内容部分，当然，缓存的这个内容部分需要有对服务器的请求或逻辑计算等的，可想而知，去缓存一段静态html是没有意义的。页面的缓存的使用对于系统的响应速度确实会有很大的提升，在实现页面缓存时最麻烦的主要是缓存的key的定义以及缓存更新的通知，这个自然框架是没法解决的，不过缓存更新的通知其实在框架中可以考虑一种通知模型的，就像事件通知那样。在实际的项目中，可以实现一个这样的通知模型或者就是简单的采用单例方式来标识某个key是否需要更新。
关于jsp cache的几条建议
1.jsp cache最好做在过滤器上,把需要缓冲的页面集中在同一个目录下,每次更改只须更改web.xml就可以完成缓冲设置,这样比较方便.
2.Gzip压缩可以将页面压缩得很小,平均压缩比为1/3,jsp cache的HashMap缓冲压缩后的页面,肯定比没压缩前更节约内存消耗,并且效率更高.
4、O/R Data Access 缓存
数据缓存估计大家都很熟悉，就是对系统的数据进行缓存的方式，典型的就是Hibernate的一级、二级数据缓存。
数据缓存在实现上如果是用hibernate的话更多的是直接使用hibernate的一级、二级以及查询缓存，如果要实现的话可以去参考hibernate的实现机制。
数据缓存的key在一级、二级缓存中采用的都是数据的标识键的值的方式，查询缓存采用的是查询参数、查询语句的方式。
数据缓存的更新则是hibernate在进行存储时直接更新缓存的内容，而对于查询缓存则是采用全部直接清除的方式，这样在下次进行查询时自然会重新去查询，
大家可能会想，为什么页面缓存和处理缓存不采用这样的方式来实现缓存的更新，稍微想想就知道了，在后台发生改变的时候其实是不知道需要移除哪些key的，
所以hibernate为了避免这个麻烦，采用的就是当数据一旦发生改变的时候就清除全部的查询缓存，而不是只去清除相关的缓存，
其实这里可以采用一种订阅式的模型，当然，也增加了框架的复杂度。
ORM缓存最强大的是它的透明化和灵活可配置，你可以使用Ehcache, 也可以选Jboss，还可以用Tangosol。
| 欢迎光临 信息发布软件,b2b软件,广告发布软件 (http://postbbs.com/) | Powered by Discuz! X3.2 |