| Oracle® Fusion Middleware Performance and Tuning Guide 11g Release 1 (11.1.1) Part Number E10108-06 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Performance and Tuning Guide 11g Release 1 (11.1.1) Part Number E10108-06 |
|
|
PDF · Mobi · ePub |
This chapter provides guidelines for improving the performance of Oracle Web Cache.
Oracle Web Cache is a content-aware server accelerator, or a reverse proxy, for the Web tier.
Oracle Web Cache is the primary caching mechanism provided with Oracle Fusion Middleware. Caching improves the performance, scalability, and availability of Web sites that run on Oracle Fusion Middleware by storing frequently accessed URLs in memory. It can also improve the performance, scalability, and availability of Web sites that run on any Web server or application server, such as Oracle HTTP Server and Oracle WebLogic Server.
For more information, see the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.
Oracle Web Cache performs best with one very powerful CPU or two CPUs. Because Oracle Web Cache is an in-memory cache, it is rarely limited by CPU cycles. Additional CPUs do not increase performance significantly. However, the speed of the processors is critical-use the fastest CPUs you can afford. Use more CPUs if Web Cache is sharing the system with other Oracle application server components or other applications.
Note that Oracle Web Cache is limited by the available addressable memory. Additional memory can increase performance and scalability. For information about the amount of memory needed, see Section 10.2.2, "Memory Configuration".
Oracle Web Cache has two processes: one for the administration server and one for the cache server.
The administration server process is used for configuring and monitoring Oracle Web Cache. This process consumes very little CPU time. However, when viewing the statistics pages in Oracle Web Cache Manager, the administration server process must query the cache server process to obtain the relevant metrics. Accessing the statistics pages frequently, or setting a high refresh rate on a statistics page can affect cache server performance.
The cache server process uses three threads: one to manage the front-end activities, a second to manage the back-end activities, and a third to process requests.
For a cost-effective way to use Oracle Web Cache, run it on a fast two-CPU dedicated computer with lots of memory. See the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache for information about various deployment scenarios.
For a Web site with more than one Oracle Web Cache instance, consider installing each instance on a separate two-CPU node, either as part of a cache cluster or as a standalone instance. When Oracle Web Cache instances are on separate nodes, you are less likely to encounter operating system limitations, particularly in network throughput. For example, two caches on two separate two-CPU nodes are less likely to encounter operating system limitations than two caches on one four-CPU node.
Of course, if other resources are competing with Oracle Web Cache for CPU usage, you should take the requirements of those resources into account when determining the number of CPUs needed. Although a separate node for Oracle Web Cache is optimal, you can also derive a significant performance benefit from Oracle Web Cache running on the same node as the rest of the application Web server.
To avoid swapping documents in and out of the cache, configure enough memory for the cache. Generally, the amount of memory (maximum cache size) for Oracle Web Cache should be set to at least 512 MB. Your application's memory requirements can vary based upon factors such document size, number of documents, the number of HTTP headers returned, and whether ESI is present. To get a close approximation on the maximum amount of memory required, you may apply the formula provided below. If your application uses ESI then all templates and document fragments must be accounted for when figuring the TotalDocs and the AvgDocSize.
Estimated Cache size in bytes = 1.25 *(TotalDocs * ((AvgDocSize/8192+1) *8192+ 16384))
0.25 accounts for the run time memory usage. The Web Cache action limit is set to 5% below than the maximum Web Cache size by default. Web Cache also allocates 5% of the total cache size to optimize access misses that cannot be cached.
TotalDocs refers to the total number of documents you intend to place in Web Cache.
The AvgDocSize is self-explained.
Remember to convert the estimated cache size is returned in bytes by the formula.
The memory formula presented above was verified against actual memory usage measurements and it showed very close results as can be seen in the table below:
| Number of Cached | Doc Size In | Measured Cache | Formula Generated Results |
|---|---|---|---|
|
Docs |
Bytes |
Size in MB |
Size in MB |
|
3300.00 |
102400 |
499.61 |
499.51 |
|
5525.00 |
51200 |
499.27 |
499.08 |
|
11050.00 |
51200 |
998.54 |
998.17 |
|
6600.00 |
102400 |
999.22 |
999.02 |
|
13200.00 |
102400 |
1998.44 |
1998.05 |
|
22100.00 |
51200 |
1997.07 |
1996.34 |
|
3300.00 |
102400 |
499.61 |
499.51 |
The cache is empty when Oracle Web Cache starts. For monitoring to be valid, ensure that the cache is fully populated. That is, ensure that the cache has received enough requests so that a representative number of documents are cached.
The Oracle Web Cache Statistics page (Monitoring > Web Cache Statistics) provides information about the current memory use, the maximum memory use and the total documents currently resident in Oracle Web Cache. Note the following metrics in the Cache Overview table:
Size of Documents in Cache shows the current logical size of the cache, which is the size of the valid documents in the cache. For example, if the cache contains two documents, one 3 KB and one 50 KB, the Size of Documents in Cache is 53 KB, the total of the two sizes.
Configured Maximum Cache Size indicates the maximum cache size as specified in the Resource Limits page.
Current Allocated Memory displays the physical size of the cache, which is the amount of data memory allocated by Oracle Web Cache for cache storage and operation. This number is always smaller than the process size shown by operating system statistics because the Oracle Web Cache process, like any user process, consumes memory in other ways, such as instruction storage, stack data, thread, and library data.
Current Action Limit is 95% of the Configured Maximum Cache Size. This number is usually larger than the Current Allocated Memory.
If the Current Allocated Memory is greater than the Current Action Limit, Oracle Web Cache begins to use allocated but unused memory, and may begin garbage collection to free more memory. During garbage collection, Oracle Web Cache removes the less popular and less valid documents from the cache in favor of the more popular and more valid documents to obtain space for new HTTP responses without exceeding the maximum cache size.
If the Current Allocated Memory is close to or greater than the Current Action Limit, increase the maximum cache size to avoid swapping documents in and out of the cache. For more information, see "Specifying Properties for an Oracle Web Cache System Component" in Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.
When you use Oracle Web Cache, ensure that each system has sufficient network bandwidth to accommodate the throughput load. Otherwise, the network may be saturated but Oracle Web Cache has additional capacity. For example, if an application generates 100 megabits of data or more per second, 10/100 Megabit Ethernet can be saturated.
If the network is saturated, consider using Gigabit Ethernet rather than 10/100 Megabit Ethernet. Gigabit Ethernet provides the most efficient deployment scenario to avoid network collisions, retransmissions, and bandwidth starvation. Additionally, consider using two separate network cards: one for incoming client requests and one for requests from the cache to the application Web server.
Use network-monitoring utilities that show network bandwidth usage. If the network is under utilized and throughput is less than expected, check whether the CPUs are saturated.
It is important to specify a reasonable number for the maximum connection limit for the Oracle Web Cache server. If you set a number that is too high, performance can be affected, resulting in slower response time. If you set a number that is too low, fewer requests can be satisfied. Strike a balance between response time and the number of requests processed concurrently.
To help determine a reasonable number, consider the following factors:
The maximum number of clients that you intend to serve concurrently at any given time.
The average size of a document and the average number of requests per document.
Network bandwidth. The amount of data that can be transferred at any one time is limited by the network bandwidth.
The percentage of cache misses. Cache misses are forwarded to the application Web server. Those requests consume additional network bandwidth, resulting in longer response times; especially if a large percentage of requests are cache misses.
How quickly a document is processed. Use a network monitoring utility, such as ttcp or LoadRunner to determine how quickly your system processes a document.
The cache cluster member capacity, if you have a cache cluster environment. The capacity reflects the number of incoming connections from other cache cluster members. Set the cluster member capacity using the Clustering page (Properties > Clustering) of Oracle Web Cache Manager.
WARNING:
Do not set the values listed above to an arbitrarily high value. Oracle Web Cache sets aside some resources such as memory for each connection. Altering these values can adversely affect performance.
Use various tools, such as those available with the operating system and with Oracle Web Cache, to help determine the maximum number of connections. For example, the netstat-a command enables you to determine the number of established connections; the ttcp utility enables you to determine how fast a document is processed. The Oracle Web Cache Manager provides statistics on hits and misses.
For detailed instructions on how to set the maximum number of incoming connections, see "Specifying Properties for an Oracle Web Cache System Component" in Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.
Besides the number of network connections, other network-related parameters for Oracle Web Cache, the application Web server, and the operating system can affect response time. In most situations, the default settings are sufficient.
If response time is slow, you should tune Oracle Web Cache, the application Web server, and operating system parameters that affect connections, as explained in this section.
For Oracle Web Cache, check the values of the following settings:
Keep-Alive Timeout
The amount of time a network connection is left open after Oracle Web Cache sends a response to a browser. Keep-Alive enables an HTTP client to send multiple requests to Oracle Web Cache using the same network connection. By default, the connection is left open for five seconds, which is typically enough time for the browser to send subsequent requests to Oracle Web Cache using the same connection.
If the network between the browser and Oracle Web Cache is slow, consider increasing the timeout, experiment with 10 seconds then 20 seconds and perhaps up to 30 seconds.
If you receive the following error, either increase the maximum incoming connections for Oracle Web Cache or lower the Keep-Alive Timeout:
11313: The cache server reached the maximum number of allowed incoming connections. Listening is temporarily suspended.
With a heavy load, such as during stress-testing, if clients continuously send one request and then disconnect, set the Keep-Alive Timeout to 0. With this value, Oracle Web Cache closes the connection as soon as the request is completed, to free up resources.
Set the Keep-Alive Timeout value in the Network Timeouts page (Properties > Network Timeouts).
Origin Server Timeout
The amount of time for the application Web server to generate a response to Oracle Web Cache. If the application Web server or proxy server is unable to generate a response within that time, Oracle Web Cache sends a network apology page to the browser.
Usually, this value should be equal to the response time of the slowest document served by the application Web Server. If the value is too low, long-running requests can timeout before the response is complete. If the value is too high and the application Web server hangs for some reason, it can take longer for Oracle Web Cache to failover to another application Web server.
Set this value in the Network Timeouts page (Properties > Network Timeouts).
For the application Web server, check the values of the following settings in the application Web server's configuration file (httpd.conf). (These particular parameter names are specific to the Oracle HTTP Server.)
KeepAlive
Whether to allow persistent connections. Persistent connections allow a client to send multiple sequential requests through the same connection.
Make sure KeepAlive is enabled. This can improve performance because the connection is set up only once and is kept open for subsequent requests from the same client.
KeepAliveTimeout: The time a connection is left open to wait for the next request from the same client. If requests are primarily from Oracle Web Cache, you can set this value fairly high. A reasonable value is 30 seconds.
MaxKeepAliveRequests: The maximum number of requests to allow during a persistent connection. Set to 0 to allow an unlimited number of requests.
MaxClients: The maximum number of clients that can connect to the application Web server simultaneously.
If KeepAlive is enabled for the application Web server, you may require more concurrent httpd server processes, and you may have to set the MaxClients directive to a higher value.
If client requests have a short response time, you may be able to improve performance by setting MaxClients to a lower value. However, when the MaxClients value is reached, no additional processes can be created, causing other requests to fail. The MaxClients limit on the application Web server should be greater than or equal to the application Web server capacity as set through the Oracle Web Cache Manager.
For the operating system, check the TCP time-wait setting. This setting controls the amount of time that the operating system holds a port, not allowing new connections to use the same port.
On the Linux operating system, validate the value of /proc/sys/net/ipv4/tcp_fin_timeout. On the Solaris Operating System, check the tcp_time_wait_interval setting, using the following command:
ndd -get /dev/tcp tcp_time_wait_interval.
On Windows, check the value of TcpTimeWaitDelay in the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
This setting is usually only an issue during stress testing, if you continuously open more TCP/IP connections from one client computer. In this situation, lower the TCP time-wait setting. In real world deployments, this is rarely an issue because it is unlikely that a single client can generate a huge number of connections.
On most UNIX platforms, each client connection requires a separate file descriptor. The Oracle Web Cache server attempts to reserve the maximum number of file descriptors when it starts. If you have root privileges, you can increase this number. For example, for the LINUX Operating System you can increase the maximum number of file descriptors by modifying Oracle Web Cache users file descriptors limits in /etc/security/limits.conf.
For example to allow the user "WC_USER" to have 4092 connections, in the /etc/security/limits.conf file add the following entries:
WC_User soft nofile 4092 WC_User hard nofile 4092
Ensure that there are adequate file descriptors available to any process on the host by increasing the fs.file-max parameter in the /etc/sysctl.conf file.
On Solaris Operating System you can increase the maximum number of file descriptors by setting the rlim_fd_max parameter. If webcached is not run as root, the Oracle Web Cache server logs an error message and fails to start.
On Windows, only available kernel resources limit the number of file handles as well as socket handles - the size of paged and non-paged pools. However, the number of TCP ports the system can open restricts the number of active TCP/IP connections.
For more information on establishing connections, see "Set Resource Limits and Network Thresholds" in Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.
A cache hit is a web browser request that can be satisfied from documents stored in the cache. A cache miss is a web browser request that cannot be satisfied from documents stored in the cache and must be forwarded to the application web server.
If the ratio of cache hits to cache misses is low, consider the following ways to raise the cache hit rate:
Use cookies and URL parameters to increase cache hit rates.
Oracle Web Cache can cache different versions of a document with the same URL, based on request cookies or headers. To use this feature, applications may need to implement simple changes, such as creating a cookie or header that differentiates the documents.
Some applications contain insignificant URL parameters, which can lead to different URLs representing the same content. If the documents are cached under their full URLs, the cache hit/miss ratio becomes very low. You can configure Oracle Web Cache to ignore the non-differentiating URL parameter values, so that a single document is cached for different URLs, greatly increasing cache hit rates.
Sometimes the content for a set of documents is nearly identical. For example, the documents may contain hyperlinks composed of the same URL parameters with different session-specific values, or they may include some personalized strings in the document text, such as welcome greetings or shopping cart totals. You can configure Oracle Web Cache to store a single copy of the document with placeholders for the embedded URL parameters or the personalized strings, and to dynamically substitute the correct values for the placeholders when serving the document to clients.
For more information on multiple version documents, sessions, ignoring URL parameter values, and simple personalization, see "Getting Started with Administering Oracle Web Cache" in Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.
Use redirection to cache entry documents.
For some popular site entry documents, such as "/", that typically require session establishment, session establishment effectively makes the document non-cacheable to all new users without a session. To cache these documents while preserving session establishment, you can either:
Create a blank document that provides session establishment for all initial requests and redirects to the actual popular document. Subsequent redirected requests to the popular document can specify the session, enabling the popular document to be served from the cache.
Use a JavaScript that sets a session cookie for the popular documents.
Note:
For more information on configuring caching rules for documents requiring session establishment, see "Caching and Compressing Content" in Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.
Use partial page caching where possible.
Many Web documents, such as pages generated by OracleAS Portal, are composed of fragments with unique caching properties. For these pages, full-page caching is not feasible. However, Oracle Web Cache provides partial page caching using Edge Side Includes (ESI). With ESI, you can divide each Web page into a template and multiple fragments that can, in turn, be further divided into templates and lower level fragments. Each fragment or template is stored and managed independently; a full page is assembled from the underlying fragments upon request. Fragments can be shared among different templates, so that common fragments are not duplicated to waste cache space. Sharing can also greatly reduce the number of updates required when fragments expire.
Depending on the application, updating a fragment can be cheaper than updating a full page. In addition, each template or fragment can have its own unique caching policies such as expiration, validation, and invalidation, so that each fragment in a full Web page can be cached if possible, even when some fragments are not cached or are cached for a much shorter period of time.
Use ESI variables for improved cache hit/miss ratio for personalized pages.
Personalized information often appears in Web pages, making them unique for each user. For example, many Web pages contain tens or hundreds of hyperlinks embedding application session IDs. To resolve this, create your ESI pages with variables. Because variables can resolve to different pieces of request information or response information, the uniqueness of templates and fragments can be significantly reduced. This, in turn, results in better cache hit/miss ratios.
If you have not configured the application Web server or the cache correctly, response time may be slower than anticipated. This section summarizes much of the information presented in this chapter.
If the application Web server is responding more slowly than expected or if the application Web server is not responding to requests from the cache because it has reached its capacity, check the application Web server and Oracle Web Cache settings.
First, check the following:
Caching rules: Ensure that you are caching the appropriate objects. Are there popular objects that you should cache but are not caching? Use the Popular Requests page (Monitoring > Popular Requests) to see a list of the most popular requests and to check that those objects are being cached.
Priority rankings of the caching rules: Give frequently accessed non-cacheable documents a higher priority than cacheable documents. Give frequently accessed cacheable documents the lowest priority. Note that parsing of caching rules may be resource-intensive if a large number of rules are defined.
Compression: If the network is a bottleneck for the client, compressing documents as they are cached can relieve some of the congestion on the network because compressed documents are smaller.
Then, check the following:
The application Web server configuration, particularly the MaxClients, KeepAlive, KeepAliveTimeout, and MaxKeepAliveRequests settings.
The MaxClients limit on the application Web server should be greater than or equal to the application Web server capacity as set through the Oracle Web Cache Manager.
The application Web server capacity as set using the Origin Servers page (Origin Servers, Sites, and Load Balancing > Origin Servers) of the Oracle Web Cache Manager. See the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache for information about setting application Web server capacity.
Then, if the application Web server is still busier than anticipated, it may mean that the cache cannot process the requests and is routing more requests to the application Web server. Check the following Oracle Web Cache settings in the Oracle Web Cache Manager:
The number of cache connections. Check Maximum Incoming Connections in the Resource Limits page (Properties > Resource Limits).
The memory size for the cache. Check Maximum Cache Size in the Resource Limits page (Properties > Resource Limits).
The cache cluster capacity. In a cache cluster, if cluster capacity is too low, a cache may not receive a response for owned content from a peer cache in the specified interval. As a result, the request is sent to the application Web server. Check Capacity in the Clustering page (Properties > Clustering). See the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache for more information.
If the settings for the application Web server and Oracle Web Cache are set correctly, but the response times are still higher than expected, check system resources, especially:
Network bandwidth
CPU usage
Consider the following configuration options for optimizing Oracle Web Cache performance with Oracle ADF Rich Client Applications:
After you configure the Maximum Cache Size setting in the Resource Limits page of Oracle Web Cache Manager, use a simulated load or an actual load to monitor the cache to see how much memory is actually used. Verify that any additional memory usage does not result in the host swapping memory to disk, as this may impact performance.
Personalization and compression rules for all sites include the following:
Images should be cached but not compressed
CSS files should be both cached and compressed for all request types
JS files should be both cached and compressed for all request types
HTML files should be both cached and compressed
SWF files should be cached but not compressed
Add a rule to compress but not cache .jspx files for all GET and POSTS
Add a rule to compress but not cache \.jspx.*$ files for all GET and POSTS
Add a rule to compress but not cache adw\.jspx for all request types
Add a rule not to compress and not cache profiling.js for all request types
For more detail on setting cache and compression rules, see "Caching and Compressing Content," in Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.
|
 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
