The cache information section provides statistics on how your file cache is being used. The file cache caches static content so that the server handles requests for static content quickly. The file cache contains information about files and static file content. The file cache also caches information that is used to speed up processing of server-parsed HTML. For servlets and JSPs, other kinds of caching are used.
For sites with scheduled updates to content, consider shutting down the cache while the content is being updated, and starting it again after the update is complete. Although performance slows down, the server operates normally when the cache is off.
For performance reasons, Web Server caches as follows:
For small files, it caches the content in memory (heap).
For large files, it caches the open file descriptors (to avoid opening and closing files).
The following is an example of how the cache statistics are displayed in perfdump:
CacheInfo: ------------------ File Cache Enabled yes File Cache Entries 141/1024 File Cache Hit Ratio 652/664 ( 98.19%) Maximum Age 30 Accelerator Entries 120/1024 Acceleratable Requests 281/328 ( 85.67%) Acceleratable Responses 131/144 ( 90.97%) Accelerator Hit Ratio 247/281 ( 87.90%)
The following table shows the file cache statistics as displayed in the Admin Console:
Table 2–4 File Cache Statistics
Total Cache Hits |
46 |
Total Cache Misses |
52 |
Total Cache Content Hits |
0 |
Number of File Lookup Failures |
9 |
Number of File Information Lookups |
37 |
Number of File Information Lookup Failures |
50 |
Number of Entries |
12 |
Maximum Cache Size |
1024 |
Number of Open File Entries |
0 |
Number of Maximum Open Files Allowed |
1024 |
Heap Size |
36064 |
Maximum Heap Cache Size |
10735636 |
Size of Memory Mapped File Content |
0 |
Maximum Memory Mapped File Size |
0 |
Maximum Age of Entries |
30 |
The number of files that have been cached in the accelerator cache.
You can increase the maximum number of accelerator cache entries by increasing the number of file cache entries as described in File Cache Entries. Note that this number will typically be smaller than the File Cache Entries number because the accelerator cache only caches information about files and not directories. If the number is significantly lower than the File Cache Entries number, you can improve the accelerator cache utilization by following the tuning information described in Acceleratable Requests and Acceleratable Responses.
The number of client requests that were eligible for processing by the accelerator cache. Only simple GET requests are processed by the accelerator cache. The accelerator cache does not process requests that explicitly disable caching, for example, requests sent when a user clicks Reload in the browser and requests that include a query string, that is, requests for URLs that include a ? character.
To maximize the number of acceleratable requests, structure your web sites to use static files when possible and avoid using query strings in requests for static files.
The number of times the response to an acceleratable request was eligible for addition to the accelerator cache.
When the server serves a static file from the file cache, the accelerator cache may be able to cache the response for faster processing on subsequent requests. To maximize performance, you should maximize the number of responses that are acceleratable. In the default configuration, all responses to requests for static files can be cached in the accelerator cache. The following configuration changes may prevent a response from being acceleratable:
ACLs that deny read access
Additional directives in the default object of the obj.conf file, including third party plug-ins
Using <Client> or <If> in the default object of the obj.conf file
Custom access log formats
Java Servlet filters
To maximize the number of responses that are acceleratable, avoid such configurations.
The number of times the response for an acceleratable request was found in the accelerator cache. Web Server can also serve requests from the accelerator cache asynchronously directly from the keep-alive threads thereby bypassing the connection queue altogether. This leads to improved performance for these requests and at the same time reduces contention on the connection queue.
Higher hit ratios result in better performance. To maximize the hit ratio, see the tuning information for Acceleratable Responses.
If the cache is disabled, the rest of this section is not displayed in perdump. In the Admin Console, the File Cache Statistics section shows zeros for the values.
The cache is enabled by default. You can disable it in the Admin Console by deselecting the File Cache Enabled box on the configuration's Performance tab ⇒ Cache sub tab, under File Cache. To disable it using the command-line-interface, use wadm set-file-cache-prop and set the enabled property to false.
The number of current cache entries and the maximum number of cache entries are both displayed in perfdump. In the Admin Console, they are called the Number of Entries and the Maximum Cache Size. A single cache entry represents a single URI.
You can set the maximum number of cached entries in the Admin Console in the Maximum Entries field on the configuration's Performance tab ⇒ Cache tab, under File Cache. In the command-line interface, use wadm set-file-cache-prop and set the max-entries property. The default is 1024. The range of values is 1-1048576.
The hit ratio available through perfdump gives you the number of file cache hits compared to cache lookups. Numbers approaching 100% indicate that the file cache is operating effectively, while numbers approaching 0% could indicate that the file cache is not serving many requests.
To figure this number yourself using the statistics provided through the Admin Console, divide the Total Cache Hits by the sum of the Total Cache Hits and the Total Cache Misses.
This setting is not tunable.
This field displays the maximum age of a valid cache entry. The parameter controls how long cached information is used after a file has been cached. An entry older than the maximum age is replaced by a new entry for the same file.
Set the maximum age based on whether the content is updated (existing files are modified) on a regular schedule. For example, if content is updated four times a day at regular intervals, you could set the maximum age to 21600 seconds (6 hours). Otherwise, consider setting the maximum age to the longest time you are willing to serve the previous version of a content file after the file has been modified. If your web site’s content changes infrequently, you might want to increase this value for improved performance.
Set the maximum age in the Admin Console in the Maximum Age field on the configuration's Performance tab ⇒ Cache tab, under File Cache. In the command-line interface, use wadm set-file-cache-prop and change the max-age property. The default value is 30 seconds. The range of values is 0.001-3600.
The optimal cache heap size depends upon how much system memory is free. A larger heap size means that the Web Server can cache more content and therefore get a better hit ratio. However, the heap size should not be so large that the operating system starts paging cached files.
Set the maximum heap size in the Admin Console in the Maximum Heap Space Size field on the configuration's Performance tab ⇒ Cache tab, under File Cache. In the command-line interface, use wadm set-file-cache-prop and change the max-heap-space property. The default value is 10485760 bytes. The range of values is 0-9223372036854775807. In a 32–bit Web Server, since processes have four GBs of address space for the file cache, the value should be well under four GB.
You can use the parameter nocache for the Service function send-file to specify that files in a certain directory should not be cached. Make this change by editing obj.conf. For example, if you have a set of files that changes too rapidly for caching to be useful, you can put them into a directory and instruct the server not to cache files in that directory by editing obj.conf.
<Object name=default> ... NameTrans fn="pfx2dir" from="/myurl" dir="/export/mydir" name="myname" ... Service method=(GET|HEAD|POST) type=*~magnus-internal/* fn=send-file ... </Object> <Object name="myname"> Service method=(GET|HEAD) type=*~magnus-internal/* fn=send-file nocache="" </Object>
In the above example, the server does not cache static files from /export/mydir/ when requested by the URL prefix /myurl. For more information on editing obj.conf, see Sun Java System Web Server 7.0 Update 2 Administrator’s Configuration File Reference.
You can add an object to obj.conf to dynamically monitor and control the file cache while the server is running.
Add a NameTrans directive to the default object:
NameTrans fn="assign-name" from="/nsfc" name="nsfc"
Add an nsfc object definition:
<Object name="nsfc"> Service fn="service-nsfc-dump" </Object>
This enables the file cache control and monitoring function (nsfc-dump) to be accessed through the URI /nfsc. To use a different URI, change the from parameter in the NameTrans directive.
The following is an example of the information you receive when you access the URI:
Sun Java System File Cache Status (pid 3602) The file cache is enabled. Cache resource utilization Number of cached file entries = 174968 (152 bytes each, 26595136 total bytes) Heap space used for cache = 1882632616/1882632760 bytes Mapped memory used for medium file contents = 0/1 bytes Number of cache lookup hits = 47615653/48089040 ( 99.02 %) Number of hits/misses on cached file info = 23720344/324195 Number of hits/misses on cached file content = 16247503/174985 Number of outdated cache entries deleted = 0 Number of cache entry replacements = 0 Total number of cache entries deleted = 0 Parameter settings ReplaceFiles: false ReplaceInterval: 1 milliseconds HitOrder: false CacheFileContent: true TransmitFile: false MaxAge: 3600 seconds MaxFiles: 600000 files SmallFileSizeLimit: 500000 bytes MediumFileSizeLimit: 1000001 bytes BufferSize: 8192 bytes CopyFiles: false Directory for temporary files: /tmp Hash table size: 1200007 buckets |
You can include a query string when you access the URI. The following values are recognized:
?list: Lists the files in the cache.
?refresh=n: Causes the client to reload the page every n seconds.
?restart: Causes the cache to be shut down and then restarted.
?start: Starts the cache.
?stop: Shuts down the cache.
If you choose the ?list option, the file listing includes the file name, a set of flags, the current number of references to the cache entry, the size of the file, and an internal file ID value. The flags are as follows:
C: File contents are cached.
D: Cache entry is marked for delete.
I: File information (size, modify date, and so on) is cached.
M: File contents are mapped into virtual memory.
O: File descriptor is cached (when TransmitFile is set to true).
P: File has associated private data (should appear on shtml files).
T: Cache entry has a temporary file.
W: Cache entry is locked for write access.