asp.net ThreadPool - funzionamento di lunga durata

Question

La mia applicazione è un asp.net 3.5 in esecuzione su iis 6 (windows 2003) Questa applicazione serve migliaia di utenti al giorno (100-500 utenti in linea).

Desidero inviare una newsletter settimanale ai clienti.

Circa 200.000 email ogni volta.

Questo è il codice che sto utilizzando:

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

Durante il test di questo locale (sulla mia macchina dev) Vedo l'applicazione sta lavorando molto più lento.

1. C'è un modo migliore per scrivere questo codice?
2. meglio utilizzare ThreadPool.QueueUserWorkItem o creare un nuovo thread utilizzando t = filettatura new Thread (nuovo ThreadStart (DoWork)); ?
3. Sarà meglio creare un'applicazione completamente separata ai fini dell'invio delle newsletter. questo aiuterà se mal eseguito questa applicazione sulla stessa macchina?

Ho visto altri post qui parlare di ThreadPool vs Thread ma sembra che nessuno sia sicuro di quale sia il migliore.

Answer 1

In ordine di preferenza:

1. Creare un'altra applicazione. servizio di Windows sarebbe una buona scelta
2. Usa Thread t = new Thread(new ThreadStart(DoWork));
3. Il tuo attuale implementazione

Answer 2

Spostamento di asp.net sarebbe una buona scelta. Potrebbe trattarsi di una semplice app da riga di comando che viene eseguita da un prompt dei comandi. Perché hai bisogno di un servizio o di essere ospitato come URL?

Answer 3

Sì, penso che dovresti spostarlo dall'app web, dato che stai raccogliendo thread dal pool di thread necessari per soddisfare le tue richieste (sembra che tu abbia una buona quantità di traffico).

Si inviano anche le e-mail in modo sincrono, il che significa che il thread viene utilizzato per molto più tempo del necessario. Se si continua ad utilizzare questo approccio ThreadPool, suggerirei di metterli in coda al servizio SMTP di IIS (guardare Sistema. Net.Mail.SmtpClient.DeliveryMethod) che scrive solo un file in una cartella della coda, che viene monitorata dal servizio SMTP IIS.

Ma in realtà dovresti considerare di passare a un servizio di Windows.