Sending mail upon submission slows form down

StackOverflow https://stackoverflow.com/questions/19529059

Pergunta

So I have a typical web form and I've noticed a long delay when submitting the form before I reach the next screen. After playing around I've uncovered that it is the MailMessage portion that is causing the delay. I would like someone to look at this and give me some suggestions on how I can improve this to speed up my submission.

Code Behind

protected void Submit_Click(object sender, EventArgs e)
    {
         blah blah blah...

        StringBuilder sb = new StringBuilder();
        sb.Append("<html><body>");
        sb.Append("Success!!");
        sb.Append("</body></html>");
        MailMessage msg = new MailMessage();
        SmtpClient server = new SmtpClient("");
        msg.To.Add(toaddress);
        msg.From = new MailAddress(fromaddress, fromname);
        msg.Subject = "New Submission";
        msg.Body = sb.ToString();
        msg.IsBodyHtml = true;
        server.Send(msg);

        messageLabel.Text = "Your submission has been sent!";
        messageLabel.Visible = true;
   }

Is there anything that can be done to speed things up a bit? My biggest issue is people not thinking they clicked Submit and they hit it again. I know I could grey out the Submit button after they click on it but I was hoping for some speed improvements I wasn't previously aware of.

Foi útil?

Solução

I'm often involved in deployments with large-scale mail out requirements. You're right - email does indeed slow down the app considerably, which is why we never send an email directly from the application itself.

We also rarely use multi-threading in large-scale apps - there just aren't enough threads to go round.

We always opt for one of two options, both scale well:

  1. Message Queue, such as MSMQ. Write out the email to a message queue and then have one or more 'servers' pick up the outbound mail. Can add servers infinitely. Enterprise-scalability.

  2. Database. Write your email out to a database and then move on. Write a separate app or service which picks up the email and processes. Again, can scale really well but usually not quite as well as a message queue.

Both approaches also have one very useful benefit: Transactions. You can wrap both options in a TransactionScope meaning that, should anything else go wrong in the process, you can rollback before the email actually gets sent.

Only 100% committed transactions end up getting translated in to outbound email.

There's nothing worse that sending a customer an email along the lines "Thanks, your order has been dispatched" and then finding out later in the processing pipeline that infact you're out of stock!

Hope this helps.

Outras dicas

Perform the mail submission on a separate thread while rendering the result to the user. If the message submission fails write the email out to local disk so you have something to look at if the process dies.

Store a reference to the message-send result in Application state or a static field somewhere so the user can see if the message send was successful later on.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top