Sun Java System Web Server 7.0 Update 4 Performance Tuning, Sizing, and Scaling Guide

Chapter 5 Sizing and Scaling Your Server

This chapter examines the subsystems of your server, and provides recommendations for optimal performance. The chapter includes the following topics:

64-Bit Server

The 64–bit server, available on Solaris SPARC and AMD64 platforms only, is more scalable than the 32–bit version. You can use the 64–bit server if your system has more than 4 GB of RAM. Some of the advantages which the 64–bit server has over the 32–bit server are:


On Solaris and Windows, Web Server transparently takes advantage of multiple CPUs. In general, the effectiveness of multiple CPUs varies with the operating system and the workload. Dynamic content performance improves as more processors are added to the system. Because static content involves mostly IO, and more primary memory means more caching of the content (assuming the server is tuned to take advantage of the memory), more time is spent in IO rather than CPU activity.


As a baseline, Web Server requires 64 MB RAM. Multiple CPUs require at least 64 MB for each CPU. For example, if you have four CPUs, install at least 256 MB RAM for optimal performance. For high numbers of peak concurrent users, also allow extra RAM for the additional threads. After the first 50 concurrent users, add an extra 512 KB for each peak concurrent user.

Drive Space

You need to have enough drive space for your OS, document tree, and log files. In most cases, 2 GB total is sufficient.

Put the OS, swap/paging file, Web Server logs, and document tree each on separate hard drives. If your log files fill up the log drive, your OS does not suffer. Also, you’ll be able to tell whether, for example, the OS paging file is causing drive activity.

Your OS vendor can recommend how much swap or paging space to allocate. Based on testing, Web Server performs best with swap space equal to RAM, plus enough to map the document tree.


For an Internet site, decide how many peak concurrent users you need the server to handle, and multiply that number of users by the average request size on your site. Your average request can include multiple documents. If you are not sure, try using your home page and all of its associated subframes and graphics.

Next decide how long the average user will be willing to wait for a document, at peak utilization. Divide by that number of seconds. The result is the WAN bandwidth your server needs.

For example, to support a peak of 50 users with an average document size of 24 KB, and to transfer each document in an average of 5 seconds, 240 KBs (1920 Kbit/s) are needed. Therefore, this site needs two T1 lines (each 1544 Kbit/s). This amount of bandwidth also allows some overhead for growth.

Your server’s network interface card is intended to support more than the WAN to which it is connected. For example, if you have up to three T1 lines, one 10BaseT interface will be adequate. If you have up to a T3 line (45 Mbit/s), you can use 100BaseT. But if you have more than 50 Mbit/s of WAN bandwidth, consider configuring multiple 100BaseT interfaces, or look at Gigabit Ethernet technology.

For an intranet site, your network is unlikely to be a bottleneck. However, you can use the same calculations above to verify this.