Sun Java System Instant Messaging 7 2006Q1 Release Notes

Performance, Scalability, and Sizing Considerations

This section describes some information useful for tuning and performance when deploying Instant Messaging in a server pooled configuration and for optimizing garbage collection in the following sections:

This information should be used with the Sun Java System Communications Services 6 2005Q4 Deployment Planning Guide.


Caution – Caution –

In a server pool deployment, you need to setup each Instant Messaging server in the server pool identically.


Tuning Instant Messaging Server Memory

Use the J2SE version 5 for running the Instant Messaging server, because it performs better and does not require command line tuning as it supports ergonomic features. More information on the use of this version of Java can be found in the following documents:

The Instant Messaging server uses the iim.jvm.maxmemorysize parameter in iim.conf to set the maximum size of the JVM heap to allocate. The default value of this parameter is 256 MB, but a large active deployment of Instant Messaging will need more memory. Determining how much memory to allocate for the Instant Messaging servers in the server pool is dependent on how many concurrent active users you need to support. Each Instant Messaging server in the server pool needs 256 MB along with 65 KB for each connected/active user with daily usage like the following:

Additional load per user, use of additional Instant Messaging services like news or file transfer, and use of features such as message filters, archiving, or SSL will consume more memory. You should perform load profiling of typical user activity before deploying Instant Messaging into a production environment. Contact Sun Support Services for more information about load profiling an Instant Messaging deployment.

Thread Pooling and Service Port Configuration

Instant Messaging provides a set of configuration options to tailor the size and behavior of thread pools used to service client to server and server to server requests. These thread pools combined with associated service ports can improve the throughput of an Instant Messaging server.

Option Name 

Description 

Default Value 

iim_server.maxthreads

Maximum number of threads for the default threadpool. 

20 

iim_server.threadpool

List of independent thread pools. 

(Everything uses the default thread pool.) 

iim_server.threadpool.capacity

Capacity(*) of the default threadpool. 

10 * maxthreads 

iim_server.threadpool.aaa.maxthreads

Maximum threads for named threadpool aaa:

maxthreads(aaa)

iim_server.threadpool.aaa.capacity

Capacity of named threadpool aaa.

10 * maxthreads(aaa) 

Table 3 Defined Thread Pools for Instant Messaging

Name 

Use 

s2s-in 

All server to server inbound communications. If the port allows server to server, this thread pool is used. 

s2s-out 

All server to server outbound communications. If the port allows server to server, this thread pool is used. 

s2s 

All server to server communications; the union of s2s-in and s2s-out. 

Defined threadpools can be specified and used with an associated server only service port, as described in Service Port Configuration.

When a threadpool's capacity is exceeded, a message is output to standard error. The Instant Messaging server will not accept any additional requests for the threadpool until the number of requests is lower than the value of the threadpool's capacity. If this condition occurs in a server pooled environment, you may need to:


Example 1 Using the Defined Threadpool to Reserve Five Threads for Server to Server Inbound Communications for Instant Messaging


!s2s thread pool
iim_server.threadpool=s2s-in
iim_server.threadpool.s2s-in.maxthreads=5

Service Port Configuration

There are a number of service port configuration options as described in this section.

Option 

Definition 

Default Value 

iim_server.useport

Open normal ports (allow for StartTLS). 

true 

iim_server.usesslport

Open SSL ports (non-negotiable TLS) 

false 

iim_server.usemuxport

Open multiplexor ports 

true 

iim_server.port

List of normal ports 

5269 

iim_server.sslport

List of SSL ports 

5270 

iim_mux.serverport

List of multiplexor ports 

45222 

iim_server.port.port.sndbuf

Socket send buffer size

none 

iim_server.port.port.rcvbuf

Socket recv buffer size

none 

iim_server.port.port.interface

List of specific network interfaces to bind to 

none (Indicates any) 

iim_server.port.port.protocol

List protocols are permitted on this port (client, server, component, peer)  

all/any 

iim_server.port.port.nodelay

Enables the Nagles algorithm 

false 

Throughput of a service port may be improved by adjusting the size of a port's send of receive buffer sizes.


Example 2 Service Ports Configuration for Instant Messaging


iim_server.port = 5269, 45269, 15222
iim_server.port.5269.protocol = server
iim_server.port.45269.protocol = peer, component
iim_server.port.45269.sndbuf= 512000
iim_server.port.45269.recvbuf= 512000
iim_server.port.15222.protocol = client 

Tuning Garbage Collection for Instant Messaging

(Issue Number: 6279277) Due to differences in the way the 1.4.2 and 1.5 versions of the JRE handle garbage collection, you may experience less than optimal performance using the default garbage collector with version 1.4.2 on the server's host. To fix this, you can either upgrade to version 1.5 of the JRE, or include the following command line option when you invoke the server:


-XX:+UseParallelGC

For more information about JRE garbage collection, see the following: