This FAQ addresses frequently
asked questions relating to Oracle Application Server Web Cache
10g Release 2 (10.1.2).
General Information
Concepts and Capabilities
Deployment
Compatibility and Interoperability
Miscellaneous
OracleAS Web Cache is the software industry's leading application
acceleration solution. Designed for enterprise grid computing,
OracleAS Web Cache leverages state-of-the-art caching and compression
technologies to optimize application performance and more efficiently
utilize low-cost, existing hardware resources. Built-in workload
management features ensure application reliability and help
maintain quality of service under heavy loads. Furthermore,
the end-user performance monitoring features provide unparalleled
insight into end-user service levels.
The benefits of OracleAS Web Cache can be measured by the
dramatic improvements in the following areas:
- Resource usage – higher throughput and scalability
- User experience – faster response times without sacrificing
personalization
- Availability – intelligent workload management
- Productivity – no need to roll your own cache means faster
time-to-market
- Bottom line – reduced infrastructure load translates into
cost savings
- Intelligence – better visibility into end-user service levels
OracleAS Web Cache 10g Release 2 (10.1.2) offers
enhancements in usability, performance and diagnostics, such
as the following features:
- URL path prefix in site definitions
- Enabling and disabling caching rules
- Performance improvement in SSL termination
- Streamed delivery of compressed content
- Additional Oracle-ECID reporting in Web Cache logs
- Oracle Enterprise Manager Application Server Control support
Refer to Oracle
Application Server Web Cache Administrator's Guide
for further details.
Oracle Technology Network is the main source of all technical
information about Oracle technology. The Web site contains technical
white papers, documentation, sample codes and how-to's, as well as links to Oracle University, which provides online and instructor-lead
courses on Oracle Application Server. We also highly recommend
Oracle
Application Server 10g Essentials written by Robert
Stackowiak, Donald Bales and Rick Greenwald, published
by O'Reilly.
With OracleAS Web Cache, IT organizations no longer face the
trade-off between feature-rich page design and application performance.
OracleAS Web Cache understands the contents of HTTP headers—including cookies—and is capable of making caching and
routing decisions based on administrator- or application-defined
caching rules. This "application awareness" makes it possible
to cache different content for different categories of users,
such as the ability to show full prices to new customers and
discounted prices to returning customers. When required, OracleAS
Web Cache also guarantees the integrity of transactions, such
as shopping cart purchases, by using cookies and session IDs
for persistent, or "sticky", connections to Web servers. And
with in-cache personalization, partial-page caching, and content
assembly features, even highly dynamic Web pages—for example, those
that contain personalized attributes, session-encoded URLs,
and non-cacheable page fragments—can take advantage of OracleAS
Web Cache. ESI-compliant HTTP headers, for instance, enable
developers to set caching, compression, and validity policies
within application code, making the content self-describing
and reducing the number of configuration steps required to deploy
the cache. In short, OracleAS Web Cache enables IT organizations
to dramatically increase application performance without sacrificing
functionality or personalization.
Caching dynamically generated content is not easy, especially
for traditional caching products originally designed to store
static content. Products and services that cache static content
are typically unable to serve dynamic content because they
lack the means to manage the consistency of Web pages vis-à-vis
the data sources used to create them. Naive caching products
also force customers to rely on expensive and complex content
propagation tools to update their caches with new content. Furthermore,
these content propagation tools cannot handle the volume
and frequency of content updates demanded by today's Web application
architectures.
In contrast, OracleAS Web Cache was built from the ground up
to cache volatile Web content. OracleAS Web Cache employs advanced
invalidation mechanisms to maintain consistency with origin
data sources, such as file systems, content management tools,
databases, and content feeds. Using a combination of administrative
commands, database triggers, and programmatic interfaces, site
administrators and application developers can purge cached content
as frequently as the original content changes. Moreover, administrators
and developers can assign refresh priority levels to different
categories of pages, thereby ensuring both accuracy and rapid
response times for applications with frequently changing content.
OracleAS Web Cache also includes patent-pending performance
assurance and surge protection technology to ensure that the
cached data accurately reflects origin server content and that
updates to the cache do not flood origin Web servers.
Partial-page caching refers to the ability to cache portions
of Web pages and reassemble them on the fly for individual users.
With this technology, the cache can store all of the common
elements of a Web page and query the application and database
only for any non-cacheable objects. By uniquely identifying
common elements (for example, stock quotes, weather reports, news,
graphics, headers, footers, etc.) that can be shared among different
Web pages, only one copy of each element needs to be cached,
invalidated, and revalidated, thus saving valuable resources
across all layers of infrastructure. In OracleAS Web Cache,
this partial-page caching and dynamic content assembly functionality
is provided by the Edge Side Includes (ESI) standard.
Edge Side Includes is a standard markup language used to define
Web page templates and fragments for dynamic assembly in intelligent
cache engines such as OracleAS Web Cache. OracleAS Web Cache has
a built-in ESI processor. By designing applications with ESI,
customers can take advantage of the full power of OracleAS Web
Cache's partial-page caching functionality. Partial-page caching
makes more efficient use of IT resources and significantly reduces infrastructure
costs. To find out more about ESI, visit http://www.esi.org/ or the OracleAS
Web Cache page on OTN.
Edge Side Includes for Java provides extensions to Java that
make it easy to program JavaServer Pages (JSPs) using ESI. JSPs
are server-side software modules that produce final user interface
by linking dynamic content and static HTML through tags. JESI
is a specification and custom tag library that JSP developers
can use to automatically generate ESI code. Even though JSP
developers can always use ESI, JESI provides an even easier
way for JSP developers to express the modularity of pages and
the cacheability of those modules, without requiring developers
to learn a new programming syntax. To find out more about JESI,
visit http://www.esi.org/, http://jcp.org/jsr/detail/128.jsp or the
OracleAS
Web Cache page on OTN.
OracleAS
Web Cache can cache Flash files at the default setting. No, streaming media is not supported in the current release of OracleAS Web Cache.
Yes, OracleAS Web Cache can cache PDFs and supports HTTP byterange
requests. That means OracleAS Web Cache accepts a client request
that wishes to retrieve a portion of a PDF.
Yes. Refer to the OracleAS
Web Cache Administrator's Guide for more information.
Yes.
If the pages have the same URL, OracleAS Web Cache relies
on the cookie or header information sent by the browser to identify
the version of the page and serves it accordingly.
OracleAS Web Cache is capable of caching dynamic content,
including ASP .NET pages, however ASP .NET ships with a
set of caching tags that are tightly integrated with the Microsoft Common
Language Runtime (CLR). Use of the Microsoft's caching
tags will cause content to cache in Microsoft's cache not
OracleAS Web Cache.
OracleAS Web Cache offers automatic compression of dynamically
generated content. On average, using the standard GZIP algorithm,
OracleAS Web Cache is able to compress text files such as HTML and
XML by a factor of 10. Because compressed objects are
smaller in size, they require less bandwidth to transmit and
can be delivered faster to browsers. With compression, everyone
benefits: service providers, corporate networks, and content
providers reduce their transmission costs and end users enjoy
more rapid response times. For cacheable content that an administrator
or developer chooses to compress, OracleAS Web Cache stores
both compressed and uncompressed versions in the cache. If an
object retrieved from the origin Web server already contains
a Content-Encoding response
header, which is typically used to denote compression, OracleAS
Web Cache will not compress it. Non-cacheable responses can
also be compressed on the fly if the administrator chooses this
configuration option. All major browsers since 1997 support
GZIP expansion. Browsers that send an Accept-Endcoding request
header containing "gzip" will receive the compressed version
of the content; browsers that do not send this header will receive
the uncompressed version.
Most application Web servers on the market are capable of
serving compressed pages, but few enable caching of compressed
output. With OracleAS Web Cache, compression is a simple "Yes/No" option that an administrator selects when specifying a caching
rule. Because OracleAS Web Cache supports regular expression
for caching rules, compression can be applied to responses using
criteria other than just file extension. Regular expression
makes it very easy to select which pages to compress and which
pages not to compress, as well as whether or not a particular
browser should receive compressed content. And unlike the typical
application Web server, OracleAS Web Cache offers compression and caching for pages that have been dynamically generated.
By caching compressed output, OracleAS Web Cache reduces the
processing burden on the application Web server, which would
otherwise have to re-generate and compress dynamic pages each
time they are requested.
No, not in the current release of OracleAS Web Cache. This
functionality will be added in a future release.
Yes. OracleAS Web Cache supports HTTPS for secure transmission
of content and secure cache administration. OracleAS Web Cache
also supports client-side certificate.
HTTP protocol does not support one port listening for multiple
sites. The restriction is unrelated to OracleAS Web Cache. Refer
to Oracle Application Server Security Guide for more
details.
Yes. This functionality requires use of mod_certheaders in
Oracle HTTP Server.
Yes. OracleAS Web Cache is a reverse proxy cache.
OracleAS Web Cache uniquely combines caching and load balancing
in a single offering. Logically deployed between browser client
and a Web server farm, OracleAS Web Cache intercepts all HTTP
and HTTPS requests sent to the Web site and responds with a
cached page if there is a valid version in the cache. All cache
misses, whether cacheable or non-cacheable, are passed to the
origin Web servers on the back-end. OracleAS Web Cache distributes
these requests according to the relative capacity of each Web
server. Web server capacity is configured by the OracleAS Web
Cache administrator. Just as network load balancers do, OracleAS
Web Cache can determine when a Web server has failed and then
automatically redistribute the load over the remaining servers.
When a Web server failure occurs, the cache periodically checks
to see if the failed Web server has returned to a functional
state and is capable of serving dynamically generated content.
Layer 7 status checking, as this mechanism is called, not only
verifies the health of the Web server, but also that of the
application logic, database, and other repositories used to store
and create content. As soon as the failed server returns to
operation, OracleAS Web Cache will once again include it in
the distribution mix.
Yes. When required, OracleAS Web Cache guarantees the integrity
of transactions, such as shopping cart purchases, by using cookies
and session IDs for persistent, or "sticky", connections to
Web servers.
Yes. You can configure OracleAS Web Cache to distribute requests
over origin Web servers without caching any responses. Of course,
the bigger value in terms of ROI comes when you start caching,
compressing, and assembling dynamically generated content.
Yes. Many customers run a single instance of OracleAS Web Cache
without a 3rd-party network load balancer. For these customers,
the cache's excellent stability combined with its auto-restart
functionality provides adequate system availability. Nevertheless,
Oracle recommends that customers run OracleAS Web Cache "behind" a hardware load balancer in order to avoid a single point of
failure. Customers wishing to avoid the use of an external load
balancer can take advantage of high availability features built
into the host operating system (for example, the virtual IP, load distribution,
and failover functionality of the Network Load Balancer service
for the Microsoft Windows platform).
Yes. The cache maintains a connection pool between itself
and the origin Web servers for faster update transactions and
retrieval of new or changed content.
Yes. Refer to OracleAS Web Cache Administrator's Guide
on the configuration details.
Surge protection and performance assurance represent two sides
of the same coin. OracleAS Web Cache monitors the load on each
origin Web server for which it caches content, providing a crucial
buffer between client browsers and the mid-tier servers that
house the application. A patent-pending capacity heuristic ensures
that site performance remains at peak levels, even during traffic
spikes ("surges") or when content is changing frequently. OracleAS
Web Cache achieves this by guaranteeing that origin Web servers
do not receive more simultaneous requests than they can safely
handle, and by varying the freshness of content served out of
the cache. This degree to which "stale" content may be served
during periods of heavy load is fully configurable at the time
of content invalidation. Furthermore, when content is changing
frequently and request loads are high, the capacity heuristic
uses statistics like age and popularity to determine which objects
to serve fresh and which objects to serve stale.
Yes. OracleAS Web Cache is commonly deployed as the first
tier at the edge of the datacenter in the DMZ with the origin
server usually located behind a firewall. Oracle Application
Server is tested with a number of firewalls. Refer to the certification
matrix for details.
No. OracleAS Web Cache can be deployed either on its own hardware
tier or on the same tier as the origin Web servers. However,
to avoid resource contention in high-volume production deployments,
many customers deploy OracleAS Web Cache on dedicated hardware,
but this is by no means a requirement. Refer to Oracle Application
Server Performance Guide for OracleAS Web Cache tuning.
No. OracleAS Web Cache is not an Apache mod; it runs
as an independent listener "in front" of Apache or any other
HTTP-compliant Web application server, including those available
from Microsoft, IBM, and others. However, OracleAS Web Cache
comes configured and pretuned for accelerating Oracle Application
Server components like Oracle HTTP Server, OracleAS Containers
for J2EE (OC4J), OracleAS Portal, OracleAS Discoverer, and many
more.
Yes. OracleAS Web Cache works with any HTTP-compliant Web
server or application server, making it of benefit to customers
running non-Oracle middleware solutions. These include BEA WebLogic,
IBM WebSphere, SunOne, and Microsoft IIS. Customers can also
take advantage of OracleAS Web Cache's ability to cache dynamically
generated content, regardless of which technology they use to
generate their Web pages. Likewise, most 3rd-party content management
systems and databases are capable of generating ESI-compliant
invalidation messages that can notify OracleAS Web Cache when
content has changed. For more information on how to configure
OracleAS Web Cache to work with 3rd-party Web servers,
read the white paperUsing OracleAS Web Cache with Third-Party
Application Servers available on the OracleAS
Web Cache page on OTN.
Yes. OracleAS Web Cache 10g (10.1.2) is backwardly
compatible with prior releases of Oracle Application Server.
However, some features are only accessible with the latest
version of Oracle Application Server.
No. OracleAS Web Cache operates independently of the database.
Yes. OracleAS Web Cache has been closely integrated with OracleAS
Portal to improve Portal's overall scalability, performance,
and availability. OracleAS Portal ships with a number of predefined
caching and invalidation policies that ensure optimal use of
OracleAS Web Cache. Web Cache controls have been built into
the OracleAS Portal administrative user interface and can also
be specified by content providers through the Portlet Developer
Kit (PDK).
Yes. OracleAS Web Cache is certified for use with OracleAS
Wireless. OracleAS Wireless is integrated with OracleAS Web
Cache to improve page rendering performance and scalability.
It should be noted that OracleAS Web Cache does not understand
WAP and is not used by OracleAS Wireless in the traditional
sense in that the cache does not "front end" the wireless server.
Instead, the cache is used as a repository for post-transformed
content; the wireless runtime determines what content needs
to be inserted into the cache and when to expire content in
the cache. OracleAS Web Cache, in this case, acts as a device
adaptation cache rather than a reverse-proxy cache. Since markup
content is cached using OracleAS Web Cache, the performance
and scalability benefits are due to two factors: 1) reduced
device adaptation costs and 2) significantly reduced adapter
invocation costs. The savings in terms of device adaptation
costs stem form the fact that content that can be shared across
users and sessions is essentially transformed only once (per
logical device) from its Mobile XML format. Secondly, since
the content is not generated every time by an adapter, the total
adapter invocation cost is significantly reduced for a site that
has a large subset of cacheable pages. Refer to the OracleAS
Wireless Getting Started and System Guide for more information.
Yes. By default, mod_osso makes all protected pages non-cacheable.
However, mechanisms are available to override this behavior
for applications that control their own caching policies.
Yes. JDeveloper supports the use of ESI and JESI and currently
ships with the JESI tag library. An easy-to-use ESI Servlet
Filter extension is also available for JDeveloper. The filter
allows developers to create JSPs with ESI and JESI tags (using
the component palette), and test them within the development
environment. Without the extension, JSPs developed with ESI
or JESI will not be rendered properly when previewed in JDeveloper.
Yes. OracleAS Web Cache works transparently with applications
that use WebDAV HTTP extensions for distributed authoring, such
as PUT, COPY, DELETE, LOCK and so forth. Web-based Distributed
Authoring and Versioning, or WebDAV, is a protocol extension to HTTP 1.1 which
enables the Internet to become a transparent read and write
medium where content can be checked out, edited, and checked
in to a URL address. Oracle Application Server supports WebDAV
to perform read/write activity to both local files and to Oracle
Databases. It is pluggable with most popular Web authoring tools
(such as Macromedia and Adobe), and therefore, users can utilize
third-party tools to seamlessly access files and database content.
Yes. Oracle Application Server components work seamlessly
with standalone SSL acceleration devices from F5, Nortel, SonicWall,
and others. (Note that standalone solutions are limited in that
most do not support the use of client-side certificates for
authentication purposes.) OracleAS Web Cache and Oracle HTTP
Server support nCipher's on-board acceleration solutions. Additional
on-board (PCI/SCSI) devices will be supported in future releases.
No. OracleAS Web Cache currently supports HTTP and HTTPS only.
For now, Oracle is taking customer input to determine the priority
for these and other possible feature enhancements.
Oracle has endorsed ICAP (Internet Content Adaptation Protocol)
but does not currently support this specification in OracleAS
Web Cache. Championed by Network Appliance, ICAP's goal is to
provide a standard set of interfaces that HTTP proxies can use
to access value-added services such as content filters or virus
scanning applications—essentially an RPC for proxy caches.
OPES (Open Pluggable Edge Services) is a similar RPC initiative
in the IETF. ICAP and OPES are still in the very early stages
of evolution. Oracle will support these protocols in future
product releases if and when enough customers require them.
No, not in the current release of OracleAS Web Cache.
OracleAS Web Cache is available on all the standard platforms supported by the Oracle Application Server.
Yes. OracleAS Web Cache ships with both PL/SQL and Java invalidation
APIs, as well as a number of other invalidation code samples.
Refer to the product
documentation for more information. Invalidation samples
and tutorials are also available on OTN.
The contains a chapter on
troubleshooting. Customers may also want to check out the Web
Cache and ESI discussion forum on OTN for helpful tips and
answers to questions about OracleAS Web Cache.
Consult either the Oracle
Application Server Performance Tuning Guide or the OracleAS
Web Cache Administrator's Guide, both of which describe
tips and techniques for fine-tuning OracleAS Web Cache, as well
as hardware sizing recommendations.
Back to Top
|
