Improve Azure Email sending performance
Describe the bug
Sending an email through Azure Email Communication Services locks the foreground thread for the duration of sending the email, which usually takes 5-6 seconds (sometimes considerably more).
Orchard Core version
Since 2.0.0, when this feature was added in #15254.
To Reproduce
- Configuration Azure Email (instead of SMTP).
- Use the Email Test functionality on the Admin or set up a simple workflow that sends an email.
Observe that communication with AECS takes several seconds.
Expected behavior
While we cannot influence the behavior of AECS, we might find a way to trigger sending the email in a fire-and-forget fashion.
Logs and screenshots
See my previous comments on the PR: https://github.com/OrchardCMS/OrchardCore/pull/14749#issuecomment-1864735956 and https://github.com/OrchardCMS/OrchardCore/pull/14749#issuecomment-1866264091.
We don't want to send e-mails in a fire and forget fashion, because then we won't know if sending fails (both for logging and showing it to the user, if it happened due to a user interaction).
Let me know if you need a help on this
That makes sense, although I'd imagine that in a non-business-critical scenario someone would opt to send it fast (and not block the page load) rather than reliably, if there's a choice.
Background/batch processing (in parallel) would be ideal, although in a user-triggered workflow some user interaction might still depend on sending the email, so it has to wait for it. On the other hand, if sending the email is the last step in the workflow execution, then it doesn't have to block the main thread (that's what I meant by fire-and-forget). Could be achieved by two different email activities and it's up to the user to choose.
I won't have time to work in this in the foreseeable future (before Harvest) for sure, so Hisham if you're interested, don't hold back!
locks the foreground thread for the duration of sending the email
But it's the "foreground" thread only on the test page, right? An improvement could be to use an ajax call with a "waiting" notification (gif, text, ...) and check if it's done. But nothing server side to change IMO.
We triaged this issue and set the milestone according to the priority we think is appropriate (see the docs on how we triage and prioritize issues).
This indicates when the core team may start working on it. However, if you'd like to contribute, we'd warmly welcome you to do that anytime. See our guide on contributions here.