I've amended the mailbox polling intervals (reduce on one, increased on the other), along with increasing the number of sender threads, outgoing message queue size (to 500), but it has had no impact.
We're still finding that one mailbox is sending several hundred emails at each polling interval (set to 4 minutes), and the other is only sending 3 or 4 emails every minute. I am wondering if there are any restrictions on the mailbox itself, but I have never been involved in exchange or mail relay operations. Regards Dave On 27 April 2016 at 07:30, Dave Barber <daddy.bar...@gmail.com> wrote: > Jason, thats a thought - I'll amend the polling interval on both of them - > longer interval on the internal emails (timing isn't quite so important), > shorter polling interval on the external mailbox. Worth a try, then I'll > look into the email properties as suggested by LJ. > > Ta. > > On 26 April 2016 at 16:41, Jason Miller <jason.mil...@gmail.com> wrote: > >> ** >> I also wonder if some timeout or number of message threshold is being hit >> by the first mailbox and not leaving much processing room for the second >> mailbox? By the time the first mailbox finishes sending there is little or >> no threshold left for the second mailbox. If you know when a blast to >> mailbox 2 is going to happen, as a simple test you could disable the first >> mailbox (restart EE) and see if the blast in mailbox 2 processes quicker. >> >> Jason >> >> On Tue, Apr 26, 2016 at 8:33 AM, LJ LongWing <lj.longw...@gmail.com> >> wrote: >> >>> ** >>> there are many settings you can set in the properties file to determine >>> how many are sent per connection with the server, etc....so, you may need >>> to tweak some of those outgoing settings. >>> >>> On Tue, Apr 26, 2016 at 9:00 AM, Dave Barber <daddy.bar...@gmail.com> >>> wrote: >>> >>>> ** >>>> I should have clarified - the discrepancy we're seeing is between the >>>> create time and the time sent on the email messages form. I have >>>> monitoring in place that counts the number of unsent messages and sends me >>>> an email (via the reliable gateway/mailbox) when there are more than a few >>>> hundred unsent messages. >>>> >>>> Once they've been marked by the email messages form as "sent", they do >>>> actually send fairly quick. Possibly a problem at our end, but as we have >>>> one mailbox that is sending without any performance problems, that is >>>> making me think that the email engine itself is having no real problems. >>>> >>>> I cannot readily determine if the fault is somewhere on the network >>>> between the AR Server and the gateway or the SMTP gateway itself. >>>> >>>> On 26 April 2016 at 13:31, Shellman, David <dave.shell...@te.com> >>>> wrote: >>>> >>>>> ** >>>>> >>>>> LJ, >>>>> >>>>> >>>>> >>>>> I agree. Looking at the email headers will show where the delays >>>>> occur. Over the years I have seen delays within the email system. I have >>>>> also observed where the delay is handing off to the email server. Reading >>>>> the email heads was helpful in figuring it out. >>>>> >>>>> >>>>> >>>>> I also build a small two form system for monitoring email delays. The >>>>> first form was used to send an email that contained a GUID to our various >>>>> outbound email addresses. The email created record in the second form. >>>>> Workflow on the second form used the GUID to update the Status of the >>>>> record on the first form. There were escalation notifications on the >>>>> first >>>>> form that would send us an SMS if the record in the first form was not >>>>> updated in 20 minutes. >>>>> >>>>> >>>>> >>>>> Dave >>>>> >>>>> >>>>> >>>>> *From:* Action Request System discussion list(ARSList) [mailto: >>>>> arslist@ARSLIST.ORG] *On Behalf Of *LJ LongWing >>>>> *Sent:* Tuesday, April 26, 2016 8:22 AM >>>>> *To:* arslist@ARSLIST.ORG >>>>> *Subject:* Re: Email performance/SMTP relays >>>>> >>>>> >>>>> >>>>> ** >>>>> >>>>> Dave, >>>>> >>>>> The most important thing to figure out is where the delay is....do the >>>>> emails sit in your 'outbox' for up to 12 hours, or do they leave your mail >>>>> form in the normal timelines, and then simply take up to 12 hours to be >>>>> delivered? I have found in this type of situation that the delay is >>>>> typically on the other end, not within Remedy. Check that and if you find >>>>> that it reaches your smtp server in 'normal' time, then takes up to 12 >>>>> hours to be delivered...then the admins of that smtp server need to >>>>> investigate where the delay is. >>>>> >>>>> >>>>> >>>>> On Tue, Apr 26, 2016 at 5:18 AM, Dave Barber <daddy.bar...@gmail.com> >>>>> wrote: >>>>> >>>>> ** >>>>> >>>>> All, >>>>> >>>>> Experiencing performance problems on mail sending; some background ... >>>>> >>>>> Server is running ITSM 7.6 Change management on a 7.5 Solaris server, >>>>> Oracle at the back end. General application performance is fine. >>>>> >>>>> The server is making use of 2 outgoing mailboxes. >>>>> >>>>> Mailbox 1 - used for system notifications, such as "This change >>>>> requires your approval", etc. connects to a "legacy" SMTP relay, up to a >>>>> few thousand emails sent each day, runs fine. Emails are picked up/sent >>>>> within a minute or two. >>>>> >>>>> Mailbox 2 - used for a custom notifications system (to notify >>>>> customers of outages), similarly sends a couple of thousand emails per >>>>> day. Has been in active use since February this year. As it is external >>>>> emails it is using a "mass mail" SMTP relay designated for this purpose. >>>>> >>>>> It is this second one that is having problems - emails take anything >>>>> from 3 minutes to 12 (!!) hours to be sent. >>>>> >>>>> As far as I can see the basic configuration/polling is setup the same >>>>> on both (2 minutes). >>>>> >>>>> Any suggestions? Would reducing the polling interval have a positive >>>>> change? Or are there further configuration changes on the email engine >>>>> itself that could improve performance? Or am I just at the mercy of a >>>>> sluggish SMTP relay? >>>>> >>>>> (I've never had to investigate email performance problems!) >>>>> >>>>> Regards >>>>> >>>>> Dave >>>>> >>>>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>>>> >>>>> >>>>> >>>>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>>>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>>>> >>>> >>>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>>> >>> >>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> > > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
