IBM SG24-6320-00 사용자 설명서

다운로드
페이지 306
6320ch_sum_of_changes.fm
Draft Document for Review July 28, 2004 7:33 pm
34
 
Keeping Commerce Applications Updated WebSphere Commerce 5.1 to 5.6 Migration Guide
multiple users or pages. Fragments should be stable over a long enough period 
of time for meaningful reuse to occur. 
The goal of fragment caching with DynaCache is to maximize fragment 
reusability and cache utilization by breaking a page into smaller and simpler 
page fragments. This makes any caching, even a highly dynamic page, possible. 
The caching should take place as close to the user as possible, taking into 
consideration security and personalized data factors. For example, non-user 
specific data can be place closest to the user (like on an Edge Server), but 
secure information should be placed behind a firewall. Pages need to be 
fragmented out as much as possible so they can be cached at different locations. 
The order for placing this from close to far is: Edge server, IBM HTTP Server, 
WebSphere Application Server, Database Server.
WebSphere Commerce has dynamic cache enabled by default, but the 
cachespec.xml contains no entries for any of the provided business models. 
Instead, sample subsets of cachespec.xml files are provided to enable caching 
of the business models. They also support invalidation using different 
techniques.
WebSphere Commerce comes with a Dynamic Cache Monitor enterprise 
application that displays statistics and contents of the dynamic cache. The 
monitor can be accessed via a Web browser accessing the following URL:
https://<hostname>:8002/cachemonitor
This application is provided as an installable Enterprise Archive (EAR) file and 
can be installed in a server that has dynamic cache enabled. With this 
application, you can monitor caching interactively and invalidate pages.
In summary, almost everything can be cached if the pages are broken down into 
smaller fragments. DynaCache can be viewed as a sophisticated hash table that 
can increase performance and reduce infrastructure costs. Among its many 
features include the ability to off load caching from memory to disk, full page and 
fragment caching, invalidation support (either manual using cache monitor, 
time-out based, event driven, WAS API, or invalidation command) and replication 
across servers and Edge of Network caching support. DynaCache is configured 
through a policy-based XML file called cachespec.xml. Some factors to consider 
on deciding what to cache include reusability, invalidation and variations of the 
JSP fragments. Finally, for best performance, caching should be placed as close 
to the user as possible.