test

Sun Java Communications Suite 5 Deployment Planning Guide

Collecting Instant Messaging Sizing Data

Use this section to identify the data you need to size your Instant Messaging deployment. The following topics are covered in this section:

Determining Peak Volume of Unique Instant Messaging Logins

Your peak volume is the largest concentrated numbers of unique logins to your Instant Messaging system within a given period in a day. The volume can vary from site to site as well as across different classes of users. For example, peak volume among groups might occur during corporate-held core hours which differ between time zones.

Analyzing peak volume involves three basic operations:

  1. Determining when and for how long the peaks occur

  2. Sizing your deployment against peak volume load assumptions

    Once patterns are analyzed, choices can be made to help the system handle the load and provide the services that users demand.

  3. Making sure that your Instant Messaging deployment can support the peak volume that you have determined

Creating Your Instant Messaging Usage Profile

Measuring your load is important for accurate sizing. Your usage profile determines the factors that programs and processes place on your Instant Messaging servers and multiplexors.

This section helps you create your usage profile to measure the amount of load that is placed on your deployment.

Creating a usage profile involves answering the following questions:

  1. What is the total number of users on your system?

    When counting the number of users on your system, account for not only the users who have accounts and can log into the system, but also the users with accounts who are currently not logged into the system. The following table describes the types of users that make up the total.

    Connection  

    Description  

    Inactive User 

    A user with an Instant Messaging account who currently is not logged into the system. Non-connected users consume disk space but no CPU or memory. 

    Connected/Inactive 

    These users are logged in, but are not currently sending or receiving instant messages. 

    Connected/Active 

    Logged into the system and actively sending messages, updating user information such as contact lists, and attending conferences throughout the day. 

    Characterize your configured users using these three general profiles. The total of these users should give you an idea of the total number of concurrent connections you need to support.

    If you have a small deployment, the defaults might be sufficient to meet your site’s needs. So, if you have a very small deployment (for example, less than 300 users), you might not need to go through this process of planning a sizing strategy. Work with your Sun Client Services representative to determine your individual needs.

  2. How many connections are on your system during your peak volume?

    Correctly formulating the maximum number of concurrent users that has to be sustained by the system is key to planning your resource requirements. Although a deployment usually has maximum number of configured users, it is important to plan for the maximum number of concurrent users (connected and more or less active). A conservative estimate for the number of concurrent users can then be determined based on a 1:10 ratio. Thus, for a deployment of 50,000 configured users, the concurrent users would be 5,000.

    Specifically, note the number of concurrent connections, idle, and busy connections.

    Connection  

    Description  

    Concurrent Connection 

    Number of unique TCP connections or sessions that are established on your system at any given time. 

    Idle Connection 

    Connection where no information is being sent between the client and multiplexor or server and multiplexor. 

    Busy Connection 

    A connection that is in progress. An established connection where information is being sent between the client and multiplexor or multiplexor and server. 

    To determine the number of concurrent connections in your deployment, you can count the number of established TCP connections by using the netstat command on Solaris platforms.

    To determine the number of concurrent connections you can support, you need to obtain two values from parameters within the iim.conf file that are used for tuning multiplexor performance:

    1. iim_mux.numinstances - Specifies the number of multiplexor instances.

    2. iim_mux.maxsessions - Specifies the maximum number of clients that one mutliplexor process can handle. The default is 1000.

    Once you have obtained these values, multiply the numinstances number by the maxsessions number. This gives the total number of concurrent connections supported by your deployment. For information on the iim.conf file, see the Sun Java System Instant Messaging 7.2 Administration Guide.

  3. If you have a large deployment, how will you organize your users?

    For example, consider placing active users on one server and inactive users on another.

  4. What is the amount of storage used for each user?

    If you are storing your end user data, such as contact lists, in LDAP, you need to plan for the space required to store this data. If you configure the server to store this data outside LDAP, the server stores it in a flat file. See the Sun Java System Instant Messaging 7.2 Administration Guide for more information.

  5. How many messages enter your Instant Messaging system from the Internet?

    The number of messages should be measured in messages per second during your peak volume.

  6. How many messages are sent by your users to:

    • End users on your system?

    • The Internet?

    This number of messages is also measured in messages per second during the peak volume.

  7. Will you be using SSL? If yes, what percentage of users and what type of users?

    For example, in a particular organization, 20% of connections during peak hours will enable SSL.

Answering these questions provides a preliminary usage profile for your deployment. You can refine your usage profile as your Instant Messaging needs change.

Additional Questions

While the following questions are not applicable to creating your usage profile, they are important to developing your sizing strategy. How you answer these questions might require you to consider additional hardware.

  1. How much redundancy do you want in your deployment?

    For example, do you need to consider high availability.

  2. What backup and restore strategy do you have in place (such as disaster recovery and site failover)? What are the expected times to accomplish recovery tasks?

    Typically you need to back up the server configuration files, database, and any resource files you have customized.

Defining Your Instant Messaging User Base or Site Profile

Once you establish a usage profile, compare it to sample pre-defined user bases that are described in this section. A user base is made up of the types of Instant Messaging operations that your users will perform. Instant Messaging users fall into one of these user bases:

The sample user bases described in this section broadly generalize user behavior. Your particular usage profile might not exactly match the user bases; you will be able to adjust these differences when you run your load simulator (as described in Using an Instant Messaging Load Simulator).

Casual Users

A lightweight user base typically consists of users with simple Instant Messaging requirements. These users rarely initiate chat sessions and rarely receive invitations. They might only use Instant Messaging as a presence tool.

Heavy Users

A heavy user uses significantly more system resources than a casual user. Typical usage for a this type of user may be something like the following: