Increasing performance for SMTPRA, POP3A, LDAP3A, IMAP4A, MAILMA and HTTPMA

Document ID: 10157

Synopsis

Explanation of the Threads that the services use and how to diagnose that there is a fault with these services and tweak performance. All the services have a "thread pool" and an incoming

More Information

Increasing performance for SMTPRA, POP3A, LDAP3A, IMAP4A, MAILMA and HTTPMA Explanation of the Threads that the services use and how to diagnose that there is a fault with these services and tweak performance. All the services have a "thread pool" and an incoming connection thread. The incoming connection listens on the relevant port, and when a connection is requested it takes the connection, and sticks it in the "connection pool" and goes back to listening for connections. That's ALL that thread does. Then the threads in the thread pool sit monitoring the "completion port". When any connection in the connection pool has finished sending data, or we have finished sending it data, then a message is posted to the completion port to indicate that the connection needs to be serviced by a thread. So one of the threads that are sitting waiting on the completion port will see this message, and take the connection out of the connection pool, go and do something with the connection until it is again in a state of waiting on I/O either from the file system, or to the remote socket, and then it will put the connection back in the connection pool and the thread will go back to waiting on the completion port. So there is not a one to one relationship between the number of active connections, and the number of threads. This is because one thread can service many more connections, due to the amount of time we have to wait for I/O. The completion port mechanism is unique to Windows, and it is why there is no port of Mailsite to other OS, and why Mailsite is such a good choice for a Win32 mail server. If you would like to read more about completion ports in Windows, then you may find this document of interest: "Windows Sockets 2.0: Write Scalable Winsock Apps Using Completion Ports" http://msdn.microsoft.com/msdnmag/issues/1000/Winsock/default.aspx So the "WorkerThreads" property specifies how many worker threads the mail server should try to keep waiting on the completion port. By default this will be 4. If the mail server detects that there are zero threads waiting on the completion port, it will spawn a new thread. If there are too many threads, then it will close one down. At any one time on a healthy busy server there should be some threads waiting on the completion port, and some threads servicing the connection. Switching between threads is a costly operation, so it is counter productive to whack this WorkerThreads setting for each of the services up to many hundreds of threads, as the server will waste CPU time switching context between threads. The way to set this "WorkerThreads" setting is to leave your server running at the default of 4, and then do -control 130 dumps (c:\Program Files\MailSite\[servicename] -control 130) and look to see how many threads are waiting on the completion port as a proportion of the number of threads the service currently has. This command creates a file (servicename)dump.txt or (servicename)dump.xml which you can view in a text editor. So for example a dump that I recently looked at showed this: Number of threads waiting on a queued completion = 4 Total number of worker threads = 5 This means that there are 5 threads active, and 4 are sitting waiting for more connections. If it looked like this: Number of threads waiting on a queued completion = 2 Total number of worker threads = 5 Then this means that the server is getting busy and we should keep an eye on it to see if we should configure more threads. The server is receiving a lot of incoming connections. It may therefore be advisable to increase WorkerThreads for that service to around "6" which should hopefully give the server a little more leeway. If it ever looks like this: Number of threads waiting on a queued completion = 0 Total number of worker threads = 5 Then this is extremely bad news. This means that there are likely to be connections that are sitting waiting to be serviced that are doing nothing. You should certainly increase the WorkerThreads setting to around 10. As a general rule, try to make sure there are always at least as many threads waiting, as there are doing something. Experiment a little as it will be different due to different loads on different servers. The other per service setting is the "MaxWorkerThreads". The server will not allow there to be more than this number of threads in the connection pool. The default is 4 times the "WorkerThread" count. In the above examples the "MaxWorkerThreads" count is probably set to 5, and hence the service hasn't already spawned a new thread to replace the one removed from the thread pool. Do not set this to several thousands of threads. You will end up just killing the performance of your server due to the resources required to maintain all the threads. If you do a -control 130, and you observe that the total number of worker threads is 4 * your WorkerThreads, and there are STILL no threads waiting on the completion packet then consider buying more hardware, and in the mean time, try increasing the Max Worker Threads beyond the default 4 times limit.

In order to increase SMTPRA performance, follow the steps below:

NOTE: This is for Registry installations only. For customers running MailSite in SQL Connector please follow the directions in KB 10184

WARNING!!
Incorrectly editing the registry can damage the server, please be sure you know what you are doing

  1. Click on the Start button
  2. Select the RUN option
  3. Type regedit, the registry editor will open
  4. Select the HKEY_LOCAL_MACHINE key
  5. Next select the SYSTEM key
  6. Next select Current_control_set
  7. Next select the Services key
  8. Next select the SMTPRA key
  9. Lastly select the parameters key
  10. Add a REG_DWORD entry rename it to: NoKeepalives
  11. Set this entry to decimal and enter the value of 1
  12. Next add a REG_DWORD entry rename it to: WorkerThreads
  13. Set this entry to decimal and enter the value of 20
    can be modified later if performance does not improve
  14. Close the editor
  15. Shutdown and restart the service

These changes will increase SMTPRA performance. If you find that it needs further tuning, simply open the registry editor and increase the values. NoKeepalives however should stay at 1.

 

To increase the performance of the other services follow the steps below:

POP3 follow the example for SMTPRA but in Step 7 edit the key POP3A

LDAP follow the example for SMTPRA but in Step 7 edit the key LDAP3A

IMAP follow the example for SMTPRA but in Step 7 edit the key IMAP4A

MAIL follow the example for SMTPRA but in Step 7 edit the key MAILMA

HTTP follow the example for SMTPRA but in Step 7 edit the key HTTPMA

SMTPDA follow the example for SMTPRA but in Step 7 edit the key SMTPDA. The change for SMTPDA is only applicate in MailSite 7 and later