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"
