Your peak volume is the largest concentrated numbers of transactions to your 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 a certain class of managers in a medium-sized enterprise might occur from 9 to 10 in the morning, 12 to 1 in the afternoon, and 5 to 6 in the evening.
Analyzing peak volume involves three basic operations:
Determining when and for how long the peaks occur
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.
Making sure that your Messaging Server deployment can support the peak volume that you have determined.
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:
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:
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.
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.
Specifically, note the number of concurrent, idle, and busy connections for each client access service that you support:
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.
An established IMAP connection where no information is being sent between the mail client and Messaging Server, except the occasional check or noop command.
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.
Count the number of established TCP connections by using the netstat command on UNIX platforms.
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.
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.
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.
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.
How many messages are sent by your users to:
End users on your mail system?
This number of messages is also measured in messages per second during the peak volume.
What is the distribution of messages in different size ranges?
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.
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.
Do you plan on using any SSL crypto accelerator hardware?
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.
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.
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.
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.
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.
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.
What are your response time requirements? What are your throughput requirements?
What is your specific criteria for resource utilization? Can your CPUs be 80 percent busy on average? Or only at peak?
Will you have messaging servers at different geographic locations? Do you expect users’ mail to be located geographically?
Do you have archiving requirements for keeping mail messages for a certain length of time?
Do you have legal requirements to log all messages? Do you need to keep a copy of every message sent and received?
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 messaging operations that your users will perform along with a range of message sizes that your users will send and receive. Messaging users fall into one of five 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 a Messaging Server Load Simulator).
A lightweight POP user base typically consists of residential dial-up users with simple messaging requirements. Each concurrent client connection sends approximately four messages per hour. These users read and delete all of their messages within a single login session. In addition, these users compose and send few messages of their own with just single recipients. Approximately 80 percent of messages are 5 Kbytes or smaller in size, and about 20 percent of messages are 10 Kbytes or larger.
A heavyweight POP user base typically consists of premium broadband users or small business accounts with more sophisticated messaging requirements than the lightweight POP user base. This group uses cable modem or DSL to access its service provider. Each concurrent client connection sends approximately six messages per hour. Messages average about two recipients per message. Sixty-five percent of messages are 5 Kbytes or smaller in size. Thirty percent of messages in this user base are between 5-10 Kbytes. Five percent of messages are larger than 1 Mbyte. Of these users, 85 percent delete all of their messages after reading them. However, 15 percent of users leave messages on the server through several logins before they delete them. Mail builds up in a small portion of those mailboxes. In some cases, the same message can be fetched several times from the server.
A lightweight IMAP user base represents users that enable premium broadband Internet services, including most of the advanced features of their messaging systems like message searching and client filters. This user base is similar to heavyweight POP with regard to message sizes, number of recipients, and number of messages sent and received by each concurrent connection. Lightweight IMAP users typically log in for hours at a time and delete most or all mail before log out. Consequently, mail stacks up in a mailbox during a login session, but user generally do not store more than 20 to 30 messages in their mailboxes. Most inboxes contain less than 10 messages.
A mediumweight IMAP user base represents sophisticated enterprise users with login sessions lasting most of an eight hour business day. These users send, receive, and keep a large amount of mail. Furthermore, these users have unlimited or very large message quotas. Their inboxes contain a large amount of mail that grows during the day, and is fully or partially purged in large spurts. They regularly file messages into folders and search for messages multiple times per hour. Each concurrent client connection sends approximately eight messages per hour. These users send messages with an average of four recipients and have the same message size mix as the Heavyweight POP and Lightweight IMAP user bases.
A mediumweight Messenger Express/Communications Express user base is similar to Mediumweight IMAP. This user base has the same message size mix as Mediumweight IMAP, Lightweight IMAP, and Heavyweight POP. And, the message delivery rates are the same as Mediumweight IMAP users.
It is likely that you will have more than one type of user base in your organization, particularly if you offer more than one client access option. Once you identify your user bases from these categories, you will test them with your usage profile and with a load simulator, described in Using a Messaging Server Load Simulator.