![]() |
Scalability |
|||||||||||||||||||||||||||||||||||||||||
|
|
You can move domain subdirectories to other disks, just replace the moved subdirectories with their symbolic links.
You can also move domain directories from the Domains directory and replace them with symbolic links.
In order to estimate how many users you can serve at the same time, you should realize what type of service your clients will use.
This number is not high, but POP3 sessions put a high load on your disk I/O and network I/O subsystems: after authentication, a POP3 session is essentially, a "file downloading" type of activity.
But since the IMAP protocol is "mail access", not "mail downloading" protocol, IMAP users spend much more time being connected to the server. In corporate environments, users can leave their IMAP sessions open for hours, if not days. While such inactive sessions do not put any load on your disk or network I/O subsystems, or CPU, each session still requires an open network connection and a processing thread in the server. Since the IMAP protocol allows users to request search operations on the server, IMAP users can also consume a lot of CPU resources if they use this feature a lot.
This allows the server to use just 100 HTTP connections to serve 3,000 or more open sessions.
When you know the type and number of clients you plan to serve, you can estimate the resources they will need on your Server.
This problem can be seen even on the sites that have just few hundred accounts. This indicates that some of the clients have configured their mailers to check the server too often. If client mailers connect to the server every minute, and the OS TIME_WAIT time is set to 2 minutes, the number of "died" sockets will grow, and eventually, they will consume all OS TCP/IP resources.
It is recommended to set the TIME_WAIT time to 20-30 seconds.
The TIME_WAIT problem is a very common one for Windows NT systems. Unlike most Unix systems, Windows NT does not have a generic setting for the TIME_WAIT interval modification. To modify this setting, you should create an entry in the Windows NT Registry (the information below is taken from the http://www.microsoft.com site:
Description: This parameter determines the length of time that a connection will stay in the TIME_WAIT state when being closed. While a connection is in the TIME_WAIT state, the socket pair cannot be reused. This is also known as the "2MSL" state, as by RFC the value should be twice the maximum segment lifetime on the network. See RFC793 for further details.
When the CommuniGate Pro server starts, it tries to put this limit as high as possible, and then it decreases it a bit, if it sees that the limit set can be equal to the system-wide limit (if the CommuniGate Pro consumes all the "descriptors" available on the server OS, this will most likely result in the OS crash). The resulting limit is recorded in the CommuniGate Pro Log.
To increase the maximum number of file and socket descriptors the CommuniGate Pro Server process can open, see the instructions below.
Each network connection is processed by a server thread. Each thread has its own stack, and the CommuniGate Pro threads have 100Kbyte stacks on most platforms. Most of the stack memory is not used, so they do not require a lot of real memory, but they do add up, resulting in bigger virtual memory demand. Most OSes do not allow the process virtual memory to exceed a certain limit. Usually, that limit is set to the OS swap space plus the real memory size. So, on a system with just 127Mbytes of the swap space and 96Mbytes of real memory, the maximum virtual memory that can be allocated is 220Mbytes. Since the swap space is shared by all processes that run under the server OS, the effective virtual memory limit on such a system will be around 100-150MB - and, most likely, the CommuniGate Pro Server will be able to create 500-1000 processing threads.
On 32-bit computers, 4GB of virtual memory is a theoretical limit, and allocating more than 4GB of disk space for page swapping does not change anything.
During POP3 and IMAP4 access session, one of the account mailboxes is open. If that mailbox is a text file (BSD-type) mailbox, the mailbox file is open. During an incoming SMTP session a temporary file is created for an incoming message, and it is kept open while the message is being received. So, on Unix systems, the total number of open POP, IMAP, and SMTP connections cannot exceed 1/2 of the maximum number of socket/file descriptors per process.
While a WebUser session does not require a network connection (and thus a dedicated socket and a thread), it can keep more than one mailbox open.
On Unix systems, when the Server detects that the number of open network sockets and file descriptors is coming close to the set limit, it starts to reject incoming connections, and reports about this problem via the Log.
The Mac OS X sets a 6MB limit on "additional" virtual memory an application can allocate.
This is not enough for sites with more than 2,000 users, and you should increase that limit by specifying:
ulimit -d 100000
command in the CommuniGate Pro startup file.