|
| | | Junior Member
 
Group: Forum Members
Last Login: Yesterday @ 3:12:08 PM
Posts: 10, Visits: 2,031 |
| | When I read this piece of support I am wondering why the ability to change these settings are not accomodated into Iadmin. Why to hack the register? And read.. It has to be a Prime Number, so I had to find a web site which was hopefully correct about the prime numbers :S Question: We have a server that its primary role is sending large amounts of outbound mail and can have over 100,000 messages hit it quickly. Are there any tweaks that we can make to improve performance of IMail? Answer: Perform the following steps:
1.) Increase the queue manager threads from 30 to 200 so the queue manager can spend most of it's time sending mail.
2.) Increase the Hash table size for the Queue manager. The queue manager uses internal lists and maps to keep track of the files. In the default install, it is optimized for having 10,000 messages in the spool directory. Since you may be flooding mail to the server, increase the hash size so the queue manager can perform optimally.
To change the Hash table size you'll need to make a change in the registry.
Open the registry and go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\QUEUEMGR\Parameters. Select the DWORD value QHashSize and select modify. Switch the base to Decimal and then enter a value that is 20% larger than the maximum number of messages you think will be spooled. NOTE: This value must be a PRIME NUMBER.
Document #: IM-20060905-JH12.htm
Revision Date: 09/14/07 |
| |
| | | Time Traveler
Group: Forum Members
Last Login: 2 days ago @ 1:33:46 PM
Posts: 206, Visits: 394 |
| 1. thanks i'm trying this out at 4xxxx i forgot the number off the top of my head. what setting is working best for you?
2. what campaign/mass email software do you utilize?
3. i found today that disabling "dns caching" under i believe the queue manager or smtp, is starting to create dramatic improvements. this might be due to the fact that we have 100k people in the db. the max caching setting is 5000... so my theory is its always modifying the cache which then creates a bottleneck. since we use more than 5000 domains a day (different unique emails for companies) that its a less essential setting then someone with less email. so try that
4. a huge help was from modifying the tcp half opens with a patch program on both the email sender and the email server machines. we changed our setting to 50, up from microsofts 10 (which was created after sp2). i have put this idea and other tweaks at:
http://forums.arialsoftware.com/viewtopic.php?t=534&sid=5462d40d3fa5b3c11ad096579aaeb9bc |
| |
| | | Time Traveler
Group: Forum Members
Last Login: 2 days ago @ 1:33:46 PM
Posts: 206, Visits: 394 |
| today's new method:
today I exported my final query (minus removals/signoffs/suppress/hardbounces)... as an xls (which is what my query uses from the db)... and then dragged the cleaned up file over the original (making sure to match sheet names)... so this new xls sheet was cleaned up... smaller and had the query removals...
now when access is called the campaign reads the query much faster since it doesn't have to suppress anyone. i am seeing a 200-400% improvement. |
| |
|
|