Once you evaluate your hardware and user base with a load simulator, you need to assess your system performance. The topics in this section address methods by which you can improve your overall system performance.
Make sure you have an adequate amount of physical memory on each machine in your deployment. Additional physical memory improves performance and enables the Instant Messaging server to operate at peak volume. With sufficient memory, Instant Messaging can operate efficiently without excessive swapping.
For most deployments, you need at least 256 MB of RAM. The amount of RAM needed depends on the number of concurrent client connections, and whether the server and multiplexor are deployed on the same host. For information about concurrent connections, see Creating Your Instant Messaging Usage Profile. For information on hosting the server and multiplexor on the same host, see Developing Instant Messaging Architectural Strategies.
On Solaris systems, you can set the amount of memory allocated to the server by modifying the iim.jvm.maxmemorysize parameter in the iim.conf file. This parameter specifies the maximum number of megabytes of memory that the Java Virtual Machine (JVM) running the server is allowed to use. The default setting is 256 MB, and the maximum setting is 500 MB. For instructions on modifying this parameter, see the Sun Java System Instant Messaging 7 2005Q1 Administration Guide.
You cannot currently change this value on Windows NT systems.
Disk throughput is the amount of data that your system can transfer from memory to disk and from disk to memory. The rate at which this data can be transferred is critical to the performance of Instant Messaging. To improve efficiency in your system’s disk throughput:
Consider your maintenance operations, and ensure you have enough bandwidth for backup. Backups can also affect network bandwidth, particularly remote backups. Private backup networks can be a more efficient alternative.
Carefully partition the data stores to improve throughput efficiency.
Ensure the user base is distributed across RAID (Redundant Array of Independent Disks) environments in large deployments. Typically, you make this decision as part of the Directory Server deployment planning process.
Stripe data across multiple disk spindles in order to speed up operations that retrieve data from disk.
When planning Instant Messaging server system disk space, be sure to include space for operating environment software, Instant Messaging software, and for any servers not currently in your network that need to be installed to support Instant Messaging (such as LDAP). Be sure to use an external disk array. In addition, user disk space needs to be allocated. Typically, this space is determined by your site’s policy. Typical installations will require:
Approximately 300 MB of free disk space for each server or multiplexor
Approximately 5 K of disk space for each user
Additional space for the Instant Messaging archive
The archive captures instant messages and archives them in a Portal Server Search database. End users can query and retrieve these archived messages using the Search page on the Portal Server desktop.
Use Table 22–1 to determine server and multiplexor disk space sizing numbers whether archiving is enabled or disabled. The figures listed in the table were generated using a 400MHz Ultra SPARC II Processor.
Table 22–1 Instant Messaging Server and Multiplexor Memory Disk Space Sizing for Concurrent Users
|
Server Memory Consumption for Connected/Inactive Users |
Server Memory Consumption for Connected/Active Users |
Multiplexor Memory Consumption for Connected/Inactive Users |
Multiplexor Memory Consumption for Connected/Active Users |
---|---|---|---|---|
Archive Disabled |
8 MB +20 K per User |
120 MB + 20 K per User |
8 MB + 20 K per User |
8MB + 28K per User |
SSO/Portal/Archive enabled |
100MB +25K per User |
120MB +30K per User |
8M+35K per user |
8 MB +40K per user |
Network throughput is the amount of data at a given time that can travel through your network between your client application and server. When a networked server is unable to respond to a client request, the client typically retransmits the request a number of times. Each retransmission introduces additional system overhead and generates more network traffic.
Improving data integrity, system performance, and network congestion reduces the number of retransmissions. Steps to do this involve:
Avoiding bottlenecks to ensure that the network infrastructure can handle the load
Partitioning your network
Not using theoretical maximum values when configuring your network to ensure that sufficient capacity exists for future expansion
Separating traffic flows on different network partitions to reduce collisions and to optimize bandwidth use.
Enable enough CPU for your servers and multiplexing services. In addition, enable enough CPU for any RAID systems that you plan to use. If you intend to use archiving in your deployment, you need to take those space requirements into consideration as well.
Use Table 22–2 to help determine the number of CPUs your installation requires for optimum performance whether archive is enabled or disabled. The figures listed in the table were generated using a 400MHz Ultra SPARC II Processor.
Table 22–2 Instant Messaging CPU Utilization Numbers
|
Server CPU Utilization for Connected/Inactive Users |
Server CPU Utilization for Connected/Active Users |
Multiplexor CPU Utilization for Connected/Inactive Users |
Multiplexor CPU Utilization for Connected/Active Users |
---|---|---|---|---|
Archive Disabled |
Several hundred thousand users per CPU |
30 K users per CPU |
50 K users per CPU |
5 K users per CPU |
Consider the following suggestions and generalizations when planning your multiplexor deployment. The parameters discussed in this section are located in the iim.conf file.
The number of iim_mux.maxthreads should not exceed the number of CPUs on your server.
This helps maximize resource utilization and optimizes processing speed.
The iim_mux.maxsessions value should be high enough to avoid rejecting connections, but it should be reasonable enough so that the multiplexor processes to not get overloaded.
Be sure that your expected number of concurrent client connections is less than the maximum possible by a safe margin.
Do not configure threads or number of concurrent sessions to more than you require. Otherwise, you will unnecessarily consume system resources.
A good starting point is to configure iim_mux.numinstances to the number of CPUs on the system.
See the Sun Java System Instant Messaging 7 2005Q1 Administration Guide for more detailed information about these parameters.