asp.net ThreadPool - long running operation

My application is a asp.net 3.5 running on iis 6 (windows 2003) This application is serving 1000's of users daily (100-500 users online).

I want to send an email newsletter to customers weekly.

Around 200,000 emails every time.

This is the code I'm using:

 ThreadPool.QueueUserWorkItem(new WaitCallback(AsyncProcessMailerQueue), null);

 private static void AsyncProcessMailerQueue(object data)
 {
    for (int i=0;i<users.count ; i++)
    {
      MailMessage message = new MailMessage();
      .......
      SmtpClient smtpClient = new SmtpClient();
      smtpClient.Send(message);
    }
 }

When testing this locally (on my dev machine) I see the application is working a lot slower.

1. Is there a better way to write this code?
2. Should I use ThreadPool.QueueUserWorkItem or 开发者_JAVA技巧create a new thread using Thread t = new Thread(new ThreadStart(DoWork)); ?
3. Will it be better to create a totally separate application for the purpose of sending the newsletters. will that help if ill run this application on the same machine?

I've seen other posts here talking about ThreadPool vs Thread but its seem no one is sure which is better.

---

In order of preference:

1. Create another application. Windows service would be a good choice
2. Use Thread t = new Thread(new ThreadStart(DoWork));
3. Your current implementation

---

Moving out of asp.net would be a good choice. This could be a simple command line app you run from a command prompt. Why do you need a service or it to be hosted as a URL?

---

Yes I think you should move this out of your web app, as you're taking up threads from the thread pool that are needed to serve your requests (sounds like you get a good amount of traffic).

You're also sending the emails syncronously which means the thread is being used for a lot longer than it need be - if you continue using this ThreadPool approach I would suggest queuing them to the IIS SMTP service (look at System.Net.Mail.SmtpClient.DeliveryMethod) which just writes a file to a queue folder, which is monitored by the IIS SMTP service.

But really you should consider moving this to a windows service.