I'm still on 6.3 but I did some testing a while back on 7.0.1 (I believe it was patch 3), with most of the settings described below. I queued 1000 emails at a time and sent them out with various settings to measure throughput. Here are the summary points:
1. Emails without .ARTASK attachments send about 5 times faster than those with .ARTASK attachments. e.g. 1072 per minute without attachments; 205 per minute with attachments. I've also verified a bottleneck with XML logging, which will show how many milliseconds each stage takes. Almost all of it is tied up in adding the attachment, presumably due to having to first create the attachment file on disk. 2. NumberOfSenderThreads always caused duplication of about 1% of the emails no matter how many threads I specified. Using a value of 1 reduced this side effect, but there were still occasionally duplicates. I believe BMC was going to eliminate most of this problem (not all) in patch 5. 3. NumberOfSenderThreads=2 provided slightly better performance than using a value of 4 or even 10. 4. NumberOfSenderThreads increased throughput for attachment emails by only 18% compared to a 60% improvement for emails without attachments. This supports the theory that disk activity, not processing, is the bottleneck of attachment emails. 5. OutgoingMessageQueueSize had no affect on throughput whether I gave it a value of 100, 500, or 2000. 6. OutgoingConnectionRecycleSize had no affect on throughput whether I used a value of 100 or 400. Some other things I should point out about these tests: - All tests performed with 2 SMTP mailboxes. AR System Email Messages entries were spread evenly across these mailboxes using custom filters on the form. I've never seen improvements by adding additional mailboxes, but that could be due to a bottleneck in our SMTP server setup. - All notifications were plain-text custom notifications from home-grown applications - Email Engine was configured to keep all sent messages in AR System Email Messages - Customized indexes on AR System Email forms were added for all tests. I always add these to improve performance of the queries used by the Email Engine. Use SQL Profiler or something similar to find DB calls to those forms which incur a duration of over 100 ms to help pinpoint queries that could benefit from indexes. I can give you a list of the indexes we add if you're interested. It gives a slight boost, but probably not much. - All tests used a 1 minute polling interval. Lowering this will reduce your delay a little bit just because it won't sleep so long between polls, but it won't really improve throughput. - SendEmailSize was not changed from the default in any of these tests. - In separate tests I found MAPI to be almost twice as fast as SMTP, but it's always been prone to Exchange errors so we only use SMTP. Chad Hall (501) 342-2650 -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Elry Sent: Wednesday, February 06, 2008 1:01 PM To: [email protected] Subject: Re: Slow Email Engine Hey Michael... We ran into a similar situation last year - here is what we did: ( 1 ) Check Email Error Logs ----------------------------------------- During the check of the Email Error Logs we found that there were a number of People profiles that had incorrect email addresses. This can create a real backlog in the email messages. After we cleaned this up - everything seemed to run a little faster. ( 2 ) Tweaking the "EmailDaemon.properties" file ------------------------------------------------------------------------ Here is a list of the settings we tweaked: (a) Number Of Sender Threads This setting lets you specify the number of sender threads per outgoing mailbox that the email daemon uses. The optimum number of threads depends on many factors including the number of mailboxes, hardware of the machine, and so on. The default value for this setting is 1. (b) OutgoingMessageQueueSize This setting lets you specify the size of the queue that the email daemon maintains for the outgoing mails. The default size of outgoing message queue size is set to 100. The optimum number of message queue size to be specified depends on the load on the email daemon. (c) OutgoingConnectionRecycleSize This setting lets you define the number of messages to process before closing the connection to the mail server. This action is performed to make sure that memory is properly released. The default setting is 100 messages. (d) Interval This setting lets you define the time interval (in minutes) to use when checking the server for configuration updates (for example, if you have modified records in the Email Mailbox Configuration form) or updates to templates (for example, if you modified templates in the Email Templates form). The default is 30 minutes. For example, to set the interval to 5 minutes, you would use the following syntax: com.remedy.arsys.emaildaemon.<server_name>.Interva l=5 (e) SendEmailSize This setting lets you specify how many outgoing emails to query at a time. The default size of outgoing emails is set to 100. On Feb 6, 1:26 pm, "Bardsley, Michael" <[EMAIL PROTECTED]> wrote: > Yes I did try a restart after the config change. Can anyone else take a > look at there outgoing messages and give me an estimate of how many are > being sent a second? > > Thanks! > > -----Original Message----- > From: Action Request System discussion list(ARSList) > > [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black > Sent: Wednesday, February 06, 2008 8:29 AM > To: [EMAIL PROTECTED] > Subject: Re: Slow Email Engine > > Mike, > > Just some thoughts.... > > I may be wrong... but I think NumberOfSenderTreads only becomes > effective after the Email Engine is stop/started. Did you do that after > making changes to that setting? > > Also... > > Another possible way to get the Email Engine to "process more mail" is > to split the mail into separate Mailbox Configurations. Basically, my > understanding is that the Email Engine processes each mailbox > independent of the others, so if you had two mailboxes (instead of > one) in theory the number of mails processed per second could double. > (Assuming your SMTP server, and your network connection to it is not the > bottleneck.) > > How to do that with OOB notifications.... I am not sure. I would hope > that there is a "template" for all OOB notifications that you could > update the data and drive them "out" through different mailbox's. But I > do not know that it works that way. (Good luck) > > You might also add workflow to the AR System Email Messages form to > "update the mailbox info" and "spread the load" from that form too. > However, that likely would add a fair amount of overhead to that > processing too, but it should work. > > -- > Carey Matthew Black > Remedy Skilled Professional (RSP) > ARS = Action Request System(Remedy) > > Love, then teach > Solution = People + Process + Tools > Fast, Accurate, Cheap.... Pick two. > > On Feb 6, 2008 8:14 AM, Bardsley, Michael <[EMAIL PROTECTED]> > wrote: > > ** > > Does anyone know of any way to speed up the time it takes for the > > email engine to process outgoing messages between AR System Email > > Messages form and the Exchange server? > > > When we went live with ITSM 7.0.2 we decided to go with the out of box > > > email notifications which has caused a large spike in the number of > > outgoing emails our system generates. In our 5.6 system we did not > > generate quite as many outgoing group notifications as are created > > using the out of box notifications in 7. During heavy volume parts of > > > the day our email engine is getting backed up and sends messages out > > at about a rate of 3 to 5 messages a second. If a few hundred > > messages get created over a few minutes period there ends up being a > > delay between the create time in AR System Email Messages and the time > > > they are sent to the customers and users. There is no problem with > > the rate messages get created in the form just a slow up in getting > them sent out. > > > Support recommended that I patch the Email Engine up to Patch 005 > > which seems to have increased the amount of messages sent out by about > > > 1 a second but this was not as much of an improvement as I would have > > liked to have seen. > > > I played with NumberOfSenderTreads= setting in the > > EmailDaemon.Properties file but this seems to have no effect at all. > > I have played with the polling interval but the issue is not the rate > > of times the AR Server connects to the mail server but how many > > messages it can process once the connection is made. > > > We are running ARS 7.0.01 > > > ~Mike Bardsley > > ________________________________________________________________________ > _______ > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum > Sponsor:www.rmsportal.comARSlist: "Where the Answers Are" > > ________________________________________________________________________ _______ > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org > Platinum Sponsor:www.rmsportal.comARSlist: "Where the Answers Are" ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" ************************************************************************* The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank you. ************************************************************************* _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
