Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java System Communications Services 6 2005Q1 Deployment Planning Guide 

Chapter 22
Planning an Instant Messaging Sizing Strategy

This chapter introduces the concepts, context, and rationale of sizing your Instant Messaging deployment.

This chapter contains the following sections:


Instant Messaging Sizing Strategy Overview

When you design your deployment, you must decide how to configure your Instant Messaging server to provide optimum performance, scalability, and reliability.

Sizing is an important part of the design effort. The sizing process enables you to identify what hardware and software resources are needed so that you can deliver your desired level of service or response time according to the estimated workload that your Instant Messaging server users generate. Sizing is an iterative effort.

Because each deployment has its own set of unique features, this chapter will not provide detailed Instant Messaging sizing information for your specific site. Also, this chapter will not provide sizing information for servers with which Instant Messaging interoperates, such as LDAP, SMTP, and so on. Rather, this chapter explains what you need to consider when you architect your sizing plan. In addition, you’ll find general guidelines for Instant Messaging components you can modify to suit your site’s needs. Work with your Sun technical representative for your deployment hardware and software needs.


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
  3. Once patterns are analyzed, choices can be made to help the system handle the load and provide the services that users demand.

  4. 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?
  2. 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.

    Table 22-1  Instant Messaging Active Versus Inactive User 

    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.

  3. How many connections are on your system during your peak volume?
  4. 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.

    Table 22-2  Instant Messaging Client 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.
    3. 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 Administration Guide:

      http://docs.sun.com/doc/819-0430

  5. If you have a large deployment, how will you organize your users?
  6. For example, consider placing active users on one server and inactive users on another.

  7. What is the amount of storage used for each user?
  8. If you are not 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 Administration Guide for more information:

    http://docs.sun.com/doc/819-0430

  9. How many messages enter your Instant Messaging system from the Internet?
  10. The number of messages should be measured in messages per second during your peak volume.

  11. 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.

  12. Will you be using SSL? If yes, what percentage of users and what type of users?
  13. 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?
  2. For example, do you need to consider high availability.

  3. 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?
  4. 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:


Using an Instant Messaging Load Simulator

To measure the performance of your Instant Messaging architecture, use your user bases (described in Defining Your Instant Messaging User Base or Site Profile) and your usage profile (described in Creating Your Instant Messaging Usage Profile) as inputs into a load simulator.

A load simulator creates a peak volume environment and calibrates the amount of load placed on your servers. You can determine if you need to alter your hardware, throughput, or deployment architecture to meet your expected response time, without overloading your system. Using a load simulator involves five basic steps:

  1. Defining the user base that you want to test (for example, casual users)
  2. If necessary, adjust individual parameters to best match your usage profile.

  3. Defining the hardware that will be tested
  4. Running the load simulator and measuring the maximum number of concurrent connections on the tested hardware with the user base
  5. Publishing your results and comparing those results with production deployments
  6. Repeating this process using different user bases and hardware until you get the response time that is within an acceptable range for your organization under peak load conditions

  7. Note

    Contact Sun Client Services for recommended load simulators and support.



Understanding Instant Messaging System Performance Guidelines

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.

Instant Messaging Memory Utilization

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 Administration Guide:

You cannot currently change this value on Windows NT systems.

Instant Messaging Disk Throughput

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:

Instant Messaging Disk Capacity

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:

Use the following table 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-3  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

Instant Messaging Network Throughput

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:

Instant Messaging CPU Resources

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 the following table 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-4  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

Instant Messaging Multiplexor Configuration Best Practices

Consider the following suggestions and generalizations when planning your multiplexor deployment. The parameters discussed in this section are located in the iim.conf file.

See the Sun Java System Instant Messaging Administration Guide for more detailed information about these parameters:


Developing Instant Messaging Architectural Strategies

Once you have identified your system performance needs, the next step in sizing your Instant Messaging deployment is to size specific components based on your architectural decisions.

The topics in this section point out sizing considerations when you deploy two-tiered and one-tiered architectures. Using load balancers with Instant Messaging is also discussed.

Two-tiered Instant Messaging Architecture

A two-tiered architecture splits the Instant Messaging server deployment into two layers: an access layer and a data layer. In a simplified two-tiered deployment, you might add one or more multiplexors and servers to the access layer. The multiplexor acts as a proxy for users, and the relays messages to the Instant Messaging server. The data layer holds the Instant Messaging server database and Directory servers. Figure 22-1 shows a simplified two-tiered Instant Messaging architecture.

Figure 22-1  Simplified Two-tiered Instant Messaging Architecture

This diagram shows a simplified two-tiered Instant Messaging architecture.

Two-tiered architectures have advantages over one-tiered architectures that can impact your sizing decisions. Two-tiered architectures:

Sizing Your Multiplexing Services

When you size your multiplexor, the calculation is based on your system load, particularly the number of concurrent connections the multiplexor needs to handle.

In addition, you must:

  1. Add CPU or a hardware accelerator for SSL if appropriate.
  2. Add memory to the machine if the multiplexor is being configured on it.
  3. Account for denial of service.
  4. Add capacity for load balancing and redundancy, if appropriate.
  5. One or more of each type of machine should still handle peak load without a substantial impact to throughput or response time when you plan for redundancy in your deployment.

One-tiered Instant Messaging Architecture

In a one-tiered architecture, there is no separation between access and data layers. The Instant Messaging server, multiplexor, and sometimes the Directory server are installed in one layer. The following figure illustrates the idea.

Figure 22-2  Simplified One-tiered Instant Messaging Architecture

This diagram shows a simplified one-tiered deployment for Instant Messaging server, a Directory Server, a multiplexor, and end users.

One-tiered architectures have lower up-front hardware costs than two-tiered architectures. However, if you choose a one-tiered architecture, you need to allow for significant maintenance windows.

To size a one-tiered architecture:

  1. Add CPU for SSL, if necessary.
  2. Account for denial of service attacks.
  3. Add more disks for the increased number of client connections.
  4. Add more disks for each multiplexor.

For specific instructions on sizing Instant Messaging components in one-tiered or two-tiered architectures, contact your Sun Client Services representative.

Using Load Balancers With Instant Messaging

Instant Messaging supports the use of load balancers located in front of the Instant Messaging multiplexors. However, you cannot currently use load balancers between the Instant Messaging multiplexors and the Instant Messaging server.

When deploying Instant Messaging as part of a Portal Server/Secure Remote Access deployment, you can locate load balancers between the Secure Remote Access gateway and the Instant Messaging multiplexors.


Note

If you just need security for the client connection, and not HTTP tunneling, consider using SSL instead of Secure Remote Access. You can configure a secure Instant Messaging client connection by enabling SSL on the multiplexors and locating them outside the firewall.



Example Instant Messaging Resource Requirements

This section provides example resource distributions and recommended sizing information for the following two Instant Messaging deployment types:

Small Deployment Sample Resource Requirements Numbers

For a small Instant Messaging deployment with the server and multiplexor on a single server having 10,000 users with the following profile:

The memory requirements are: one or two CPUs with 300-500 MB RAM each.

Large Deployment Sample Resource Requirements Numbers

For a large Instant Messaging deployment having 1,000,000 users with the following profile:

The server memory requirements are 4 GB RAM on two CPUs. The multiplexor requirement is 4 GB RAM on 16 CPUs.



Previous      Contents      Index      Next     


Part No: 819-0063-10.   Copyright 2005 Sun Microsystems, Inc. All rights reserved.