asp.net ThreadPool - operación de larga duración

Question

Mi aplicación es una asp.net 3.5 que se ejecuta en iis 6 (Windows 2003) Esta aplicación atiende a 1000 usuarios a diario (100-500 usuarios en línea).

Deseo enviar un boletín por correo electrónico a los clientes semanalmente.

Alrededor de 200,000 correos electrónicos cada vez.

Este es el código que estoy usando:

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); 
    } 
} 

Al probar este local (en mi máquina dev) Veo la aplicación está funcionando mucho más lento.

1. ¿Existe alguna forma mejor de escribir este código?
2. ¿Debo usar ThreadPool.QueueUserWorkItem o crear un nuevo hilo con hilo t = nuevo Thread (nuevo ThreadStart (DoWork)); ?
3. ¿Será mejor crear una aplicación totalmente separada con el propósito de enviar los boletines informativos? ¿Eso ayudará si ejecuta esta aplicación en la misma máquina?

He visto otros mensajes aquí hablando de ThreadPool vs Thread pero parece que nadie está seguro de cuál es mejor.

Answer 1

En orden de preferencia:

1. crear otra aplicación. servicio de Windows sería una buena opción
2. Uso Thread t = new Thread(new ThreadStart(DoWork));
3. Su implementación actual

Answer 2

Salir de asp.net sería una buena opción. Esta podría ser una aplicación de línea de comando simple que ejecuta desde un símbolo del sistema. ¿Por qué necesita un servicio o está alojado como una URL?

Answer 3

Sí, creo que deberías eliminar esto de tu aplicación web, ya que estás recogiendo subprocesos del grupo de subprocesos que se necesitan para atender tus solicitudes (parece que recibes una buena cantidad de tráfico).

También está enviando los correos electrónicos de forma sincrónica, lo que significa que el hilo se está utilizando por mucho más tiempo de lo necesario. Si continúa utilizando este enfoque ThreadPool, sugeriría ponerlos en cola al servicio IIS SMTP (mire System. Net.Mail.SmtpClient.DeliveryMethod) que simplemente escribe un archivo en una carpeta de cola, que es monitoreada por el servicio IIS SMTP.

Pero realmente deberías considerar mover esto a un servicio de Windows.