This document has the following topics:
For information on how to set Java Web Server tuning using the Administration
Tool, see Service Tuning.
Threads
One thread is required per connection. Adding threads consumes more
memory, but can yield better response time for your clients on a server
that concurrently serves multiple connections that are either high latency
or involve access to some high-latency resource (like a servlet accessing
a database on the other side of the country).
Networking Parameters
Keep-alive helps increase server throughput, but one thread is dedicated
to the connection even while the connection is idle. The default parameters
should work well for most cases, but you could try turning down the keep-alive
timeout or adding more threads to get more throughput and better response time.
The server listen queue is set by default to 50. This should be increased
on high-load servers or servers that serve connections with high latencies.
(We have been using 1024 for benchmarking runs.)
The server listen queue can be set from the Administration Tool, by selecting
Web Service, clicking on the Manage button, then choosing Service Tuning.
On the tabbed page labelled General, type the desired number into the
Capacity field.
Logging
Logging consumes CPU resources to assemble the log record and disk resources
to write out the log record. The lower you set the logging level, the better
the server will perform. By default the server has an 8K buffer for the
access log. This means that the access log is written out about every
800 requests. You can increase the buffer size if you have memory to spare
but your disk is overloaded.
By default the access log writes out client IP addresses and not their reverse-DNS-resolved hostnames. Writing out IP addresses is much more efficient than doing a reverse-lookup in a name service such as DNS.
By default the access log writes time stamps in local time. It is more
efficient to write the time stamp in GMT. This will save CPU time and
generate less garbage in the heap.
Disk Management
The server will typically use disks for three reasons: to access the
set of files it is serving, to write out log records, and (via the OS)
to page in/out code segments or its cache. Writing out log records is
rarely a problem for the disk, but the other two activities can strain the
disk. The server will perform better with the paging and file set disks
separated, or if a disk array is used in either place.
Memory and Cache Management
Some VMs (like the JavaSoft VM) limit the size of the heap that a program
can use. By default the JavaSoft VM limits the heap size to 16 MB. You
can set the upper bound of the heap size with the -mx option.
For example, to set the maximum heap size to 32 MB, you could pass
-mx32m to the Java VM at start-up.
The heap limit helps determine when a garbage collection (GC) will take place. You can set the limit high to avoid a GC, but then you could end up paging. Generally, we have found that it is better to take the hit from a GC fairly often and to avoid paging. The other thing to keep in mind about garbage collection is that the entire server stops while it is going. So if you have an occasional, very long GC, the clients will hang for that time. That leads to more variability in service quality than more frequent but smaller GCs.
The server caches files in memory to avoid going to disk. You can set the size of the cache that the server will use for this purpose. You need to coordinate the size of the cache with the size of the heap that you've given the process: the size of the heap must be at least the size of the cache, and it should allow some breathing room for the allocation of other objects. We typically run with the heap size set to be about twice the cache size.
If you see OutOfMemoryErrors written to your console or the error log,
you need to increase the heap size or decrease the cache size!
Security
The security checks that the web server does consume CPU resources. You
>will get better performance if you can turn server security and/or ACL
checking off.
 Top
java-server-feedback@java.sun.com
|
Copyright © 1997
Sun Microsystems, Inc. All Rights Reserved. |