There are several things you can do to speed up emails. We have tuned ours so
that it can send between 300-500 per minute. We reach those levels several
times a day. We can get 1000 per minute if server load is low and the emails do
not contain ARTask attachments. Here are a few things you can do:
1. Use multiple private threads
a. Setup a private RPC queue. Set max threads to the total number of
incoming and outgoing mailboxes you have.
b. Specify this RPC number in emaildaemon.properties like this:
com.remedy.arsys.emaildaemon.yourserver.RPC=390630
2. Configure multiple outgoing mailboxes
a. If you have access to multiple SMTP servers, create one mailbox for
each SMTP server. You won't see much gain from using a single SMTP server and
aliasing it to allow creation of multiple Remedy mailboxes. A one-for-one on
mail servers to mailboxes seems to be a functional limit. But if you have 2
SMTP servers with 2 mailboxes you can double your throughput.
b. If you have an Exchange server, create one for an Outlook profile.
(Consider creating multiple Outlook profiles and MAPI mailboxes if you really
need more throughput). MAPI tends to be much faster than SMTP but is prone to
issues with Exchange connectivity, the Outlook profile, etc.
c. Setup workflow on AR System Email Messages using Set Fields to
specify the outgoing mailbox so that it uses a round robin approach.
3. Increase number of threads per mailbox (7.0.x only)
a. This is a 7.0.x feature I haven't been able to use since I'm on 6.3.
But Support has achieved some outrageous improvements with these settings in
their test lab. If you're on 7.0.x, add these to your emaildaemon.properties
file. (Note: increasing these settings to higher numbers won't yield higher
throughput for some reason)
com.remedy.arsys.emaildaemon.NumberOfSenderThreads=4
com.remedy.arsys.emaildaemon.OutgoingMessagesQueueSize=2000
4. Dedicated Email Engine server
a. Setup a separate server that does nothing but run the Email Engine
service. Search the BMC KB for instructions on changing the registry so that
the Email Engine service is not dependent on the local AR Server service. This
will allow you to run the Email Engine without running AR Server. Configure the
emaildaemon.properties to connect to your actual AR Server. This will really
help if your AR Server gets high CPU usage.
5. Increase the Java heap size
a. Search for this in the BMC KB. Increase the max heap size to 512 MB
or 1 GB and you could see a big improvement if Java is using a lot of memory.
6. Turn off group and user caching
a. Set this line in emaildaemon.properties so the Email Engine won't
cache all of your groups and users when it starts up. It will only cache them
as needed. It rarely actually needs that info and it uses a lot of memory. This
will also make the Email Engine service start much faster.
com.remedy.arsys.emaildaemon.FetchUserGroupInfoOnDemand=true
7. Add additional indexes
a. With SQL analysis we found some email engine queries that could
benefit from more indexes when you have quite a bit of history on your email
engine forms. Back on 5.1.1 these (and a few others BMC finally added as
standard) doubled my outgoing throughput. These include:
AR System Email Association
1. Destination ID (improves performance)
AR System Email Error Logs
1. Email ID (makes display of AR System Email Messages
records faster)
2. Create Date (makes troubleshooting easier)
AR System Email Messages
1. Send Message (improves performance)
2. Date Sent (makes troubleshooting easier)
3. Create Date (makes troubleshooting easier)
8. Reduce the sent item history
a. You can completely eliminate this by setting 'Delete Outgoing
Notification Messages' = "Yes" in each outgoing mailbox, or by setting
com.remedy.arsys.emaildaemon.SaveSentItem=False in your emaildaemon.properties
file. It sounds like you may have already done this.
b. You can retain a few days worth of history by setting up an
escalation to delete records older than a few days from AR System Email
Messages, AR System Email Attachments, and AR System Email Association.
9. Set polling interval below 1 minute
a. If 1 minute is not fast enough for you, and you have a low enough
volume for the server to handle frequent polls, set this in
emaildaemon.properties so it interprets your polling interval as a number of
seconds instead of minutes. You probably don't want to go below 15 seconds on
this or it would never really stop running.
com.remedy.arsys.emaildaemon.MailboxPollingUnitIsMinutes=false
Chad Hall
(501) 342-2650
________________________________________
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED]
On Behalf Of Joe D'Souza
Sent: Wednesday, June 06, 2007 3:23 PM
To: [email protected]
Subject: Re: AREmail and performance questions
I do not think the alert thread has anything to do with the Email engine.. the
alert threads primary function is to poll through the Alert List form, and to
send these Alerts to listening Alert clients. It does the same as what the
arnotifier daemon used to do.
Specifying more than one SMTP server in my opinion will not benefit you in any
way as the email engine contacts the SMTP server only after processing the
email message form and after processing the email message form for pending
emails to be sent..
The only tweak that is worth doing is making sure that processed or sent emails
from the form are periodically deleted from the form or archived into another
form so that the email engine has a smaller number of records to scan through
to qualify ones that have to be sent and then process them..
Do not keep the polling interval too large, nor too low. 1 minute might be too
low, 20 minutes might be too large if you are having about 100 emails that are
created on the email message form per minute.. 2 to 3 minutes might be a good
number for that many emails that get generated per minute..
Whereas if you get just about 10 emails to process per minute you could
probably risk having the polling interval as low as a minute..
So what I think you should be doing is averaging how many emails are created
per minute ready to be sent and then according to that work on a decent polling
interval.. which is neither too small, nor too large..
Joe
-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED]
Behalf Of Sean Garrison
Sent: Wednesday, June 06, 2007 2:44 PM
To: [email protected]
Subject: AREmail and performance questions
**
Hey ARSListers,
Here is my understanding of the aremail engine:
Data gets put into the AR System Email Engine
The remedy e-mail process polls on a specified interval to see if there are any
e-mails to be sent or recieved
Remedy processes the e-mails at whatever chunk size you specify in the
"EmailDaemon.properties" file.
It is my understanding that this is a single thread for processing outgoing
messages.
I am trying to maximize the performance of the e-mail engine ... so here are my
questions:
Does setting the "Alert" thread do anything for the performance of the email
engine or does that only affect "Remedy Alerts"?
Does specifying more than one outgoing e-mail smtp server increase performance
of the e-mail engine?
Any other tweeks that might help in that arena?
Our concern is the timliness in which e-mails are sent out from the system.
Especially if you send a lot at once for a major outage.
Thanks,
Sean
P.S. Please don't respond about alarm point, etc. We are aware of it and are
looking into it ... I just want to know about the current design of the remedy
e-mail engine. __20060125_______________________This posting was submitted with
HTML in it___
*************************************************************************
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 ARSlist:"Where the
Answers Are"
