Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance problem with Outbound: large emails with lots of recipients cause major problems #2325

Closed
baudehlo opened this issue Jan 23, 2018 · 3 comments
Labels

Comments

@baudehlo
Copy link
Collaborator

smf pointed this out on irc.

It’s a weakness of the current outbound code that the email is split by domain into individual queue files. If the mail is large and to a mailing list (eg 1MB email with 100 recipients) you do a LOT of I/O.

This can actually cause a catastrophic failure: the mail starts to get written, the queue_outbound hook times out and the sender gets a temp fail. But the outbound work has started so you get huge duplicates.

Options:

  • write the mail once and use locking to update the todo part to remove “done” recipients.
  • write a separate todo file like qmail does (qmail writes 3 files - we should research what they are)
  • use a local storage db (level db?) instead which can take care of the nitty gritty details. Wild duck uses Mongo but I don’t want to go that far.

Furthermore we need to deal with that timeout sanely by nuking the outbound files (remote end could timeout so we need to cope there too).

@baudehlo
Copy link
Collaborator Author

@smfreegard What do you think of https://github.com/haraka/Haraka/tree/outbound_timeout for just addressing the very last point?

@msimerson
Copy link
Member

I like Mongo but I wouldn’t use it just for hr todo data, it’s really heavy for such a purpose. We already have [optional] dependencies on SQLite and redis and either would be abundantly adequate for todo locking.

@msimerson
Copy link
Member

Moved to the Outbound Improvements page

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants