Sun Java Communications Suite 5 Deployment Planning Guide

Creating Your Messaging Usage Profile

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

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

To create a usage profile, answer the following questions:

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

    When counting the number of users on your system, account for not only the users who have mail accounts and can log in to the mail system, but also the users with mail accounts who are currently not logged onto the system. In particular, note the difference between active and inactive users:



    Active User 

    A user who is logged into mail systems through mail access protocols like POP, IMAP, or HTTP. Depending on the type of access protocol, active users might or might not have connections to the mail server at any given time.

    For example, POP users can have a mail client open, but the POP connection established by the mail client to the server is short in duration and periodic. 

    Active users in this discussion are not the same as mail attributes with active status, such as mailuserstatus or inetuserstatus. For more information on mail attributes, see Sun Java Communications Suite 5 Schema Reference.

    Inactive User 

    A user with a mail account who currently is not using the mail system. 

    If you have a very small deployment (for example, under 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 for your POP, IMAP, and Messenger Express client access services?

    Specifically, note the number of concurrent, idle, and busy connections for each client access service that you support:



    Concurrent Connection 

    Number of unique TCP connections or sessions (HTTP, POP, or IMAP) that are established on your mail system at any given time. 

    An active user can have multiple concurrent IMAP sessions, whereas a user with a POP or Messenger Express client can only have one connection per client. Furthermore, because POP and Messenger Express connections connect to the server, retrieve data, disconnect from the server, display data, get user input, and reconnect to the mail server, it is possible for active users on POP and Messenger Express client access services not to have active connections at a given moment in time.

    Idle Connection 

    An established IMAP connection where no information is being sent between the mail client and Messaging Server, except the occasional check or noop command.

    Busy Connection 

    A connection that is in progress. An example of a busy connection is a mail server that is processing the command a mail client has just sent; the mail server is sending back a response to the mail client. 

    To determine the number of concurrent connections in your deployment, do one of the following:

    1. Count the number of established TCP connections by using the netstat command on UNIX platforms.

    2. Obtain the last login and logout times for Messenger Express or for IMAP users. See the Sun Java System Messaging Server 6.3 Administration Guide for more information.

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

    Some options include but are not limited to:

    • Placing active users and inactive users together on separate machines from one another

      If an inactive user becomes an active user, that user can be moved to the active user machines. This approach could decrease the amount of needed hardware, rather than placing inactive and active users together on a machine.

    • Separating users by Class of Service

      You might separate individual contributors, managers, and executives on machines that offer different mail storage space allocation for each class of service, different privileges, and specialized services.

  4. What is the amount of storage used on each mailbox?

    When you measure the amount of storage per mailbox, you should estimate real usage per mailbox, not the specified quota. Messages in trash or wastebasket folders still take up disk space and quota.

  5. How many messages enter your 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 mail system?

    • The Internet?

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

  7. What is the distribution of messages in different size ranges?

    For example:

    • Less than 5 Kbytes?

    • Between 5 Kbytes - 10 Kbytes?

    • Between 10 Kbytes -100 Kbytes?

    • Between 100 Kbytes - 500 Kbytes?

    • Between 500 Kbytes -10 MB?

    • Greater than 10 MB?

    If the distribution of message sizes is not available, use the average message size on your mail system, however it is not as effective as size ranges.

    The size of messages is particularly important, because it affects the rate of delivery of the MTA, the rate of delivery into the Message Store, the rate of message retrieval, and processing by anti-virus or anti-spam filters.

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

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

  9. Do you plan on using any SSL crypto accelerator hardware?

  10. Will you be using virus scanning or other specialized message processing and will this processing be enabled for all users?

    Depending on your Messaging Server configuration, the MTA will need to scan all messages to match criteria specified in specialized processing, thus increasing load on the system.

  11. For POP users, will you have a policy restricting how often they can access mail? If so, how often?

  12. For IMAP users, will you enforce a standard client or allow users to choose their own?

    Different IMAP clients make different numbers of concurrent connections to the server. Thus, a power user with many open folders might have many concurrent connections.

  13. Will you allow users to share folders? If so, will you allow all users or only some?

Answering these questions provides a preliminary usage profile for your deployment. You can refine your usage profile as your Messaging Server 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, you might consider high availability. Consider how much down time is allowed, and if you need clustering technology.

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

  3. Do you need a DMZ to separate your internal and external networks? Are all users using the internal network? Or do some of them connect by using the Internet?

    You might need MMP proxy servers and separate MTA layers.

  4. What are your response time requirements? What are your throughput requirements?

  5. What is your specific criteria for resource utilization? Can your CPUs be 80 percent busy on average? Or only at peak?

  6. Will you have messaging servers at different geographic locations? Do you expect users’ mail to be located geographically?

  7. Do you have archiving requirements for keeping mail messages for a certain length of time?

  8. Do you have legal requirements to log all messages? Do you need to keep a copy of every message sent and received?