|
Oracle® Application Server Performance Guide
10g Release 2 (10.1.2) B14001-02 |
|
 Previous |
 Next |
|
Oracle® Application Server Performance Guide
10g Release 2 (10.1.2) B14001-02 |
|
|
Previous |
Next |
This chapter provides guidelines for improving the performance of Oracle Application Server Web Cache (OracleAS Web Cache).
This chapter contains the following topics:
|
See Also: Oracle Application Server Web Cache Administrator's Guide for more information about using OracleAS Web Cache. |
OracleAS Web Cache can make best use of one or two CPUs. Because OracleAS 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.
Note that OracleAS Web Cache is limited by the available addressable memory. Additional memory can increase performance and scalability. See "Configure Enough Memory for OracleAS Web Cache" for information about the amount of memory needed.
OracleAS Web Cache has two processes: one for the admin server and one for the cache server.
The admin server process is used for configuring and monitoring OracleAS Web Cache. This process consumes very little CPU time. However, when viewing the statistics in pages in Oracle Enterprise Manager 10g Application Server Control Console and OracleAS Web Cache Manager, the admin 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.
On UNIX, the cache server process uses two threads: one to manage incoming connections and one to process requests. Because of this, two CPUs dedicated to OracleAS Web Cache are optimal.
On Windows, the cache server process can take advantage of up to four CPUs because it creates additional threads for I/O processing. However, two CPUs are sufficient for most deployments.
For a cost-effective way to run OracleAS Web Cache, run it on a fast two-CPU computer with lots of memory. See the Oracle Application Server Web Cache Administrator's Guide for information about various deployment scenarios.
For a Web site with more than one OracleAS 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 OracleAS 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 OracleAS 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 OracleAS Web Cache is optimal, you can also derive a significant performance benefit from OracleAS Web Cache running on the same node as the rest of the application Web server.
To avoid swapping objects in and out of the cache, it is crucial to configure enough memory for the cache. Generally, the amount of memory (maximum cache size) for OracleAS Web Cache should be set to at least 256 MB.
To be more precise in determining the maximum amount of memory required, you can take the following steps:
Determine what objects you want to cache, how many are smaller than 2 kilobytes (KB), and how many are larger than 2 KB. Determine the average size of the objects that are larger than 2 KB. Determine the expected peak load—the maximum number of objects to be processed concurrently.
One way to do this is to look at existing Web server logs for one day to see what objects are popular. From the list of URLs in the log, decide which ones you want to cache. Retrieve the objects and get the size of each object.
Calculate the amount of memory needed. The way you calculate it may differ depending on the version of OracleAS Web Cache.
The amount of memory that OracleAS Web Cache uses to store an object depends on the object size:
If an object is smaller than 2 KB, OracleAS Web Cache uses a buffer of 2 KB to store the HTTP body.
If an object is 2 KB or larger, OracleAS Web Cache uses buffers of 8 KB to store the HTTP body. For example, if an object is 42 KB, OracleAS Web Cache uses six 8 KB buffers to store the HTTP body.
Regardless of the size of the body, OracleAS Web Cache uses 8 KB to store the HTTP response header.
Use the following formula to determine an estimate of the maximum memory needed:
( X * ( 2KB + 8KB ) ) + ( Y * (( [m/8] * 8KB ) + 8KB )) + basemem
In the formula:
X is the number of objects smaller than 2 KB.
2KB is the buffer size for the HTTP body for objects smaller than 2 KB.
8KB is the buffer size for the HTTP response header.
Y is the number of objects that are 2 KB or larger.
[m/8] is the ceiling of m (the average size, in kilobytes, of objects 2 KB or larger) divided by 8. A ceiling is the closest integer that is greater than or equal to the number.
8KB is the buffer size for the HTTP body for objects that are 2 KB or larger.
8KB is the buffer size for the HTTP response header.
basemem is the base amount of memory needed by OracleAS Web Cache to process requests. This amount includes memory for internal functions such as lookup keys, connections to the application Web server to process cache misses, and timestamps. The amount needed depends on the number of concurrent requests and on whether or not the requests include Edge Side Includes (ESI). ESI is a markup language to enable partial-page caching of HTML fragments.
For non-ESI requests, each concurrent request needs approximately 32 KB of memory. For example, to support 1000 concurrent requests, you need about 32 MB of memory.
For ESI requests, each concurrent request needs roughly the following amount of memory:
32KB + (number of ESI fragments * [8KB to 16KB])
Because objects with more ESI fragments require more metadata for each fragment, use the higher number (16) for objects with 10 or more fragments. For example, for an object with 10 ESI fragments, use the following calculation:
32KB + (10 * [16KB]) = 192KB
That is, you need about 192 KB of memory for one 10-fragment object. To support 1000 concurrent requests, you need roughly 192 MB of memory.
For example, assume that you want to cache 5000 objects that are smaller than 2 KB and 2000 objects that are 2 KB or larger and that the larger objects have an average size of 54 KB. The objects do not use ESI. You expect to process 500 objects concurrently. Use the formula to compute the maximum memory:
(5000 * (2KB + 8KB) ) + ( 2000 * (( [54/8] * 8KB ) + 8KB )) + (500 * 32KB)
Using the formula, you need:
50,000 KB for the smaller objects.
128,000 KB for the larger objects. For the HTTP body, you need 56 KB (seven 8 KB buffers) for each object, given the average size of 54 KB. For the HTTP response header, you need 8 KB for each object.
Approximately 16,000 KB for the base amount of memory needed to process 500 concurrent requests.
This results in an estimate of 194,000 KB of memory needed.
|
Note: Even though you specify that certain objects should be cached, not all of the objects are cached at the same time. Only those objects that have been requested and are valid are stored in the cache. As a result, only a certain percentage of the objects are stored in the cache at any given time. You may not need the maximum memory derived from the preceding formula. |
Configure OracleAS Web Cache, specifying the result of the formula as the maximum cache size. Remember that the result is only an estimate.
To specify the maximum cache size, take the following steps:
Using Application Server Control Console, navigate to the Web Cache Home page.
On the Web Cache Home page, click the Administration tab to display the Administration page.
On the Administration page, click Resource Limits and Timeouts to display the Resource Limits and Timeouts page.
In the Cache Memory (MB) field, enter the result of the formula.
Click OK.
When prompted, restart OracleAS Web Cache.
Using a simulated load or an actual load, monitor the cache to see how much memory it really uses in practice.
The cache is empty when OracleAS Web Cache starts. For monitoring to be valid, make sure that the cache is fully populated. That is, make sure that the cache has received enough requests so that a representative number of objects are cached.
The OracleAS Web Cache Home page in Application Server Control Console provides information about the current memory use and the maximum memory use. Note the following metrics:
Cache Size shows the current logical size of the cache, which is the size of the valid objects in the cache. For example, if the cache contains two objects, one 3 KB and one 50 KB, the Size of Objects in Cache is 53 KB, the total of the two sizes.
Cache Size Limit indicates the maximum cache size as specified in the Resource Limits and Timeouts page.
The Web Cache Statistics page in OracleAS Web Cache Manager (Monitoring > Web Cache Statistics) provides equivalent information in the Cache Overview table. In addition, it includes two additional statistics:
Current Allocated Memory displays the physical size of the cache, which is the amount of data memory allocated by OracleAS Web Cache for cache storage and operation. This number is always smaller than the process size shown by operating system statistics because the OracleAS 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, OracleAS Web Cache begins to use allocated but unused memory, and may begin garbage collection to free more memory. During garbage collection, OracleAS Web Cache removes the less popular and less valid objects from the cache in favor of the more popular and more valid objects 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 objects in and out of the cache. Use the Resource Limits and Timeouts page of the Application Server Control Console (Web Cache Home page > Administration tab > Properties > Web Cache > Resource Limits and Timeouts) to increase the maximum cache size.
When you use OracleAS Web Cache, make sure that each node has sufficient network bandwidth to accommodate the throughput load. Otherwise, the network may be saturated but OracleAS Web Cache has additional capacity. For example, if an application generates more than 100 megabits of data per second, 10/100 Megabit Ethernet will likely 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 starvations. Additionally, consider using two separate network cards: one for incoming client requests and one for requests from the cache to the application Web server.
If system monitoring shows that the network is under utilized and throughput is less than expected, check whether or not the CPUs are saturated.
It is important to specify a reasonable number for the maximum connection limit for the OracleAS 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 will 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 an object and the average number of requests per object.
Network bandwidth. The amount of data that can be transferred at any one time is limited by the network bandwidth. See "Make Sure You Have Sufficient Network Bandwidth" for further information.
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 an object is processed. Use a network monitoring utility, such as ttcp, to determine how quickly your system processes an object.
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 Cluster Members and Properties page of the Application Server Control Console (Web Cache Home page > Administration tab > Cluster Properties > Members and Properties).
Use various tools, such as those available with the operating system and with OracleAS 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 an object is processed. The Web Cache Performance page of the Application Server Control Console (Web Cache Home page > Performance tab) provides statistics on hits and misses.
To set the maximum number of incoming connections, take the following steps:
To specify the maximum cache size, take the following steps:
Using Application Server Control Console, navigate to the Web Cache Home page.
On the Web Cache Home page, click the Administration tab to display the Administration page.
On the Administration page, click Resource Limits and Timeouts to display the Resource Limits and Timeouts page.
In the Maximum Incoming Connections field, enter the new value.
Click OK.
When prompted, restart OracleAS Web Cache.
Do not set the value to an arbitrary high value. OracleAS Web Cache sets aside some resources for each connection, which could adversely affect performance. For many UNIX systems, 5000 connections is usually a reasonable number.
On most UNIX platforms, each client connection requires a separate file descriptor. The OracleAS Web Cache server attempts to reserve the maximum number of file descriptors when it starts. If the webcached executable is run as root, you can increase this number. For example, for the 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 OracleAS Web Cache server logs an error message and fails to start.
|
See Also: Oracle Application Server Web Cache Administrator's Guide for more information on how OracleAS Web Cache calculates the maximum number of file descriptors to be used for client connections. |
On Windows, the number of file handles as well as socket handles is limited only by available kernel resources, more precisely, by the size of paged and non-paged pools. However, the number of active TCP/IP connections is restricted by the number of TCP ports the system can open.
|
See Also: Oracle Application Server Web Cache Administrator's Guide for more information on OracleAS Web Cache and TCP limits. |
Besides the number of network connections, other network-related parameters for OracleAS 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 OracleAS Web Cache, the application Web server, and operating system parameters that affect connections, as explained in this section.
For OracleAS Web Cache, check the values of the following settings from the Resource Limits and Timeouts page of the Application Server Control Console (Web Cache Home page > Administration tab > Properties > Web Cache > Resource Limits and Timeouts):
Keep Alive Timeout: The amount of time a network connection is left open after OracleAS Web Cache sends a response to a browser. Keep-Alive allows an HTTP client to send multiple requests to OracleAS 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 process the response from OracleAS Web Cache using the same connection.
If the network between the browser and OracleAS Web Cache is slow, consider increasing the timeout, perhaps up to 30 seconds.
If you receive the following error, either increase the maximum incoming connections for OracleAS 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, OracleAS Web Cache closes the connection as soon as the request is completed, to free up resources.
Origin Server Timeout: The amount of time for the application Web server to generate a response to OracleAS Web Cache. If the application Web server or proxy server is unable to generate a response within that time, OracleAS Web Cache sends a network error page to the browser.
Usually, this value should be equal to the response time of the slowest object served by the application Web Server. If the value is too low, long-running requests will timeout before the response is complete. If the value is too high and the application Web server hangs for some reason, it will take longer for OracleAS Web Cache to failover to another application Web server.
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 OracleAS 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 need 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 this value is reached, no additional processes will 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 Origin Servers page of the Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Origin Servers).
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 Solaris Operating System, for example, check the tcp_time_wait_interval setting, using the following command:
ndd -get /dev/tcp tcp_time_wait_interval
On Windows 2000, for example, check the value of the TcpTimeWaitDelay parameter 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 will generate a huge number of connections.
A cache hit is a Web browser request that can be satisfied from objects stored in the cache. A cache miss is a Web browser request that cannot be satisfied from objects 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.
OracleAS Web Cache can cache different versions of an object with the same URL, based on request cookies or headers. To use this feature, applications may need to implement some simple change, such as creating a cookie or header that differentiates the objects.
On the opposite end of the spectrum, some applications contain some insignificant URL parameters, which can lead to different URLs representing essentially the same content. If the objects are cached under their full URLs, the cache hit/miss ratio becomes very low. You can configure OracleAS Web Cache to ignore the non-differentiating URL parameter values, so that a single object is cached for different URLs, greatly increasing cache hit rates.
Sometimes the content for a set of objects is nearly identical, but not exactly identical. For example, pages may contain hyperlinks composed of the same URL parameters with different session-specific values, or they may include some personalized strings in the page text, such as welcome greetings or shopping cart totals. You can configure OracleAS Web Cache to store a single copy of the object with placeholders for the embedded URL parameters or the personalized strings, and to dynamically substitute the correct values for the placeholders when serving the object to clients.
For more information on multiple-version objects, sessions, ignoring URL parameter values, and simple personalization, see Chapter 2, "Caching Concepts," the Oracle Application Server Web Cache Administrator's Guide.
Use redirection to cache entry objects.
For some popular site entry objects, such as "/", that typically require session establishment, session establishment effectively makes the object non-cacheable to all new users without a session. To cache these objects while preserving session establishment, you can either:
Create a blank page that provides session establishment for all initial requests and redirects to the actual popular object. Subsequent redirected requests to the popular object will specify the session, enabling the popular object to be served from the cache.
Use a JavaScript that sets a session cookie for the popular objects.
For more information on configuring caching rules for objects requiring session establishment, see Chapter 12, "Creating Caching Rules," of the Oracle Application Server Web Cache Administrator's Guide.
Use partial page caching where possible.
Many Web objects, 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, OracleAS 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 as long as 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 OracleAS Web Cache settings.
First, check the following:
Caching rules: Make sure that you are caching the appropriate objects. Are there popular objects that you should cache but are not caching? Use the Popular Requests page in Application Server Control Console (Web Cache Home > Performance > All Sites > Popular Requests) to see a list of the most popular requests and to check that those objects are being cached. Also, see "Increase Cache Hit Rates" for information on increasing the ratio of cache hits to cache misses.
Priority rankings of the caching rules: Give frequently accessed non-cacheable objects a higher priority than cacheable objects. Give frequently accessed cacheable objects the lowest priority. Note that parsing of caching rules may be expensive if a large number of rules are defined.
Compression: If the network is a bottleneck for the client, compressing objects as they are cached will relieve some of the congestion on the network because compressed objects 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 Origin Servers page of the Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Origin Servers).
See "Tune Network-Related Parameters" for more information.
The application Web server capacity as set using the Origin Servers page of the Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Origin Servers). See Chapter 8, "Setup and Configuration," in the Oracle Application Server Web Cache Administrator's Guide 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 OracleAS Web Cache settings in the Application Server Control Console:
The number of cache connections. Check Maximum Incoming Connections in the Resource Limits and Timeouts page (Web Cache Home page > Administration tab > Properties > Web Cache > Resource Limits and Timeouts). See "Set a Reasonable Number of Network Connections" for more information.
The memory size for the cache. Check Cache Memory Limit in the Resource Limits and Timeouts page (Web Cache Home page > Administration tab > Properties > Web Cache > Resource Limits and Timeouts). See Configure Enough Memory for OracleAS Web Cache for more information.
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 Cluster Members and Properties page (Web Cache Home page > Administration tab > Cluster Properties > Members and Properties). See Chapter 10, "Configuring Cache Clusters," in the Oracle Application Server Web Cache Administrator's Guide for information about setting capacity for cache cluster members.
If the settings for the application Web server and OracleAS Web Cache are set correctly, but the response times are still higher than expected, check system resources, especially:
Network bandwidth. See "Make Sure You Have Sufficient Network Bandwidth" for more information.
CPU usage. See "Use Two CPUs for OracleAS Web Cache" for more information.
