views:

377

answers:

2

We've been having a problem with a mass mailer component that I wrote for a long time and the exact nature of the difficulty, how to measure it and how to mitigate it have all remained elusive.

It's got to the point where these problems are becoming critical and I need some straight answers so I'm hoping someone here can provide them.

Basically this mass mailer widget just sends out approx 25k emails one email at a time to a mail list. This is our much preferred message because it means each recipient receives a mail addressed to them personally, so we're happy with that loop.

What we're not happy with is that if you just leave the program to process after approx 6k emails we get an error that the "Maximum Session Size" has been reached and it's not going to send any more mails.

We have no real way of knowing at present which mail it got up to, our only method of throttling is based on guess work and involves sending out 1k emails every 90 seconds by manual button press.

I've searched until my head is sore for some indication of how to track the emails as they go out, how to measure the session size or something to just allow the process to be one button press and for the widget to be self-throttling but no one seems to want to talk about it online.

I've had a few suggestions to related queries that suggest completely reworking the widget or even writing a bespoke mass-mailing app.

In the end all we want to do is throttle the outgoing mail so it doesn't cause an error, or, if this is unavoidable allow it to count the mails sent and give us some clue where to pick up, or even gracefully handle the error. Something. Anything.

Does anyone have any down to earth and practical suggestions for tracking .Net 2.0 generated emails out of the originating server?

+1  A: 

Why is the session growing? Are you doing this within a request's lifetime?

I'm assuming you're "tracking" by keeping info about emails sent within the session state. I'd write a tracker that can batch-write tracking information to exterior storage, such as xml files on disk or a sql database.

If the tracking part isn't whats causing issues, but the one-at-a-time email (or the widget sending them) is, you can try batching emails and BCC them rather than sending them out one at a time. Blind Carbon Copies are always personally addressed and don't reveal to the recipient that it was mass mailed. You just have to figure out the limit on the number of emails you can send via BCC.

Third option is to, in your web app, drop what you need to generate these emails into a common storage location and have a windows Service app (or a scheduled task app) that regularly checks for new email jobs and processes them outside of your web app... maybe even outside of your web app's host server. Of course, this kind of thing wouldn't work on shared hosting servers...

Will
As far as the session goes I'm just reporting what the returned error message says. Although you have given me an interesting thought. The third option sounds like a goer.
Probably a simple application that runs as a scheduled task is your best bet.
Will
A: 

We do much the same thing, but we do 500 emails at a time per minute. The first 500 get sent, then the page reloads itself, and the job continues on with the next 500.

This take a little bit of logging and storing information about the current queue of 500, allowing for timeouts, early reloads, etc, but it has been working (emailing probably 10,000 or so emails on any given night) for a couple of years.

Matt Dawdy