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 Communications Suite 5 Deployment Planning Guide.
In a server pool deployment, you need to setup each Instant Messaging server in the server pool identically.
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:
Two presence updates
Five chats with durations of 10 minutes
One multiuser conference with a duration of 15 minutes
One logout and login
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.
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) |
4 |
iim_server.threadpool.aaa.capacity |
Capacity of named threadpool aaa. |
10 * maxthreads(aaa) |
Table 4–4 Defined Thread Pools for Sun Java Communications Suite
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 . You edit thread and port configurations in iim.conf. You need to restart the server after making changes to thread and port configurations.
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:
Increase the threadpool's capacity
Specify a defined threadpool
Adjust the number of maxthreads for the threadpool
Use a server-only service port
Increase memory may be required
More efficiently distribute users across the server pool
!s2s thread pool iim_server.threadpool=s2s-in iim_server.threadpool.s2s-in.maxthreads=5 |
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.
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 |
(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: