Delivery of bulk email to user inboxs
I would like to find a way to expedite the delivery of bulk emergency email messages.
It currently takes more than 2 hours to deliver email to all 58,000 accounts on our campus.
Is there a way to send a bulk email that gives priority for it's placement in user inboxs?
Can we make the server just concentrate resources to the delivery of that message only?
The bulk mail list is defined in the SunOne Directroy Server.
We are SunOne Java Messaging server and Directory server 5.2
TIA
[528 byte] By [
Lastpecana] at [2007-11-27 1:23:28]
# 1
Hi,
> currently takes more than 2 hours to deliver email
> to all 58,000 accounts on our campus.
> s there a way to send a bulk email that gives
> priority for it's placement in user inboxs?
Yes. Give the bulk email a priority header:
Priority: urgent
This should* cause the job_controller to prioritise the delivery of this email above that of other emails.
*this is based on messaging server 6.2, you didn't specify what you are running.
> Can we make the server just concentrate resources to
> the delivery of that message only?
A better approach would be to work out why the 58,000 recipients take that long. If the bottleneck is I/O delivery to the individual mailbox for example, concentrating on just this message may not help that much.
What is the system load like _before_ delivering the bulk email?
> The bulk mail list is defined in the SunOne Directroy
> Server.
Defined how. Is it a dynamic filter-based mailing list or a list containing thousands of individually defined recipients, or a list containing a whole bunch of sub-lists or a combination of all three?
> We are SunOne Java Messaging server and Directory
> server 5.2
Tuning of directory server may also help - depending on how long this takes.
Also are you running in a front-end mail-relay/back-end mail-store configuration or just have a single mail-store configuration?
Regards,
Shane.
# 2
Shane,
Thanks for the reply,
We are currently running Messaging server 5.2, because it is licensed under SunGard Luminis software. We hope they will certify Luminis for 6.x soon.
I wil give the priority header a try.
We do see marked increase in I/o when these messages are sent. We have three partitions, two 300G and one 900G. The later is averaging 50% busy and peaking in the 90% range. This was of course our first partition and we added from there. A bulk mail sent to campus this morning at 9:40 am seemed to corrilate to an io rate jump on the box from ~1000 io's/sec to 1500 io's/sec. Looking at the pattern of io rates for the last week shows the system starts to climb from below 1000 to just below 1500 peak, from 9 to 6. The disks are SAN attached 10k raid 5. The server v480 with 32G of which only 5G ever gets used.
These lists are lists containing thousands of individually defined recipients.
We are running in a front-end mail-relay/back-end mail-store configuration. 2 inbound and 2 outbound relays round robin plus the mailstore.
Thanks again,
John
# 3
Hi,
> We are currently running Messaging server 5.2,
> because it is licensed under SunGard Luminis
> software. We hope they will certify Luminis for 6.x
> soon.
That is unfortunate as Sun EOSL's 5.2 in May 2007 and 6.X offers a number of features that could be useful, the main one of which in your case would be LMTP delivery which reduces LDAP looksup's (no LDAP resolution on backend) and I/O (no delivery queue on backend).
> I wil give the priority header a try.
It will be interesting to see how much if any difference this makes -- good as an indicator for other readers of this forum who want to prioritise delivery.
> We do see marked increase in I/o when these messages
> are sent. We have three partitions, two 300G and one
> 900G. The later is averaging 50% busy and peaking in
> the 90% range.
This sounds pretty busy. Given that delivery is very much I/O restricted this is most-likely your bottleneck. Are there any other applications using these same partitions (e.g. directory server, messaging server queue, messaging server store database?) or are they using exclusively as message storage?
What file-system are you using (UFS/vxfs?) and are you using something liek VxVM for disk encapsulation?
What do you have set for the following:
store.dbcachesize
store.dbtmpdir
> This was of course our first
> partition and we added from there. A bulk mail sent
> to campus this morning at 9:40 am seemed to corrilate
> to an io rate jump on the box from ~1000 io's/sec to
> 1500 io's/sec.
Do you supply IMAP/POP/HTTP access for your students?
> Looking at the pattern of io rates
> for the last week shows the system starts to climb
> from below 1000 to just below 1500 peak, from 9 to
> 6. The disks are SAN attached 10k raid 5. The
> server v480 with 32G of which only 5G ever gets
> used.
This is the same configuration I had for ~30,000 student accounts. Our email deliveries tended to be faster (bulk-email delivery). But we only supplied webmail access which makes a difference.
> These lists are lists containing thousands of
> individually defined recipients.
There is the LDAP_USE_ASYNC option which can be used to improve the speed at which lists such as these are resolved - unfortunately you need to run 6.X to use it :( The appropriate value to set is documented in the 6.3 messaging server reference guide (table 4-21 LDAP_USE_ASYNC bit values).
> We are running in a front-end mail-relay/back-end
> mail-store configuration. 2 inbound and 2 outbound
> relays round robin plus the mailstore.
Which systems are running your directory servers? Have they been tuned to return results fast?
Regards,
Shane.
