ThreadPools for speeding up a site

I've tried to figure out whether using ThreadPools in an ASP.NET site is good or not. There's a lot of discussion about this but difficult to find an authorative source.

I'm building a site where the user fills out a form and p开发者_如何学编程resses the send button, this triggers a mail to be sent. My problem is that my mail vendor's API is quite slow (100ms to 12s) and this is not good for responsiveness of the app.

Is this a good idea?:

ThreadPool.QueueUserWorkItem(e =>
    EmailFactory.BuildBuyerEmailValidationEmail(client).Send()
);

The form is used about 100-200 times a day.

I'd like to avoid creating a queue as this would increase application complexity.

Another option would be to setup a web service (such as WCF) that handles all of your email routing. You could then configure the service method to be a one way call so that when the user clicks the button it fires the request to webservice and instantly returns to the page since it doesn't wait for the web service to process. IMO I would avoid trying to directly work with threads in IIS and have it manage threading in the way it wants.

This looks totally fine to me. The thread pool contains 250 threads per processor, so even if this form would be submitted 50 times a minute, it would not be any problem, because then only about ten threads would be working in parallel

Why not use the Message Queue to accomplish this? Basically, you will put the request into the queue and this can be processed at a later time - the site remains nice and responsive, and you've got a mechanism which is intended to guarantee processing.

There are two possible problems: 1) IIS can kill background thread during app domain reload (ThreadPool thread) 2) Under high pressure actual work in ThreadPool can be scheduled much later than normally (when maximum thread count is reached, the item is persisted in in-memory queue until there is available thread)

But it seems ThreadPool perfectly suits your case (sending emails) - you do not need perfect reliability.