Skip Headers
Oracle® Application Server Performance Guide
10g Release 2 (10.1.2)
B14001-02
  Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
Next
Next
 

7 Optimizing OracleAS Web Cache

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.

7.1 Use Two CPUs for 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.

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.

7.2 Configure Enough Memory for OracleAS Web Cache

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:

  1. 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.

  2. 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.

  3. 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:

    1. Using Application Server Control Console, navigate to the Web Cache Home page.

    2. On the Web Cache Home page, click the Administration tab to display the Administration page.

    3. On the Administration page, click Resource Limits and Timeouts to display the Resource Limits and Timeouts page.

    4. In the Cache Memory (MB) field, enter the result of the formula.

    5. Click OK.

    6. When prompted, restart OracleAS Web Cache.

  4. 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.

7.3 Make Sure You Have Sufficient Network Bandwidth

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.

7.4 Set a Reasonable Number of Network Connections

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:

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:

  1. Using Application Server Control Console, navigate to the Web Cache Home page.

  2. On the Web Cache Home page, click the Administration tab to display the Administration page.

  3. On the Administration page, click Resource Limits and Timeouts to display the Resource Limits and Timeouts page.

  4. In the Maximum Incoming Connections field, enter the new value.

  5. Click OK.

  6. 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.

7.4.1 Connections on UNIX Platforms

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.

7.4.2 Connections on Windows

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.

7.5 Tune Network-Related Parameters

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):

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.)

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.

7.6 Increase Cache Hit Rates

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:

7.7 Check Application Web Server and Web Cache Settings to Optimize Response Time

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:

Then, check the following:

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:

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: