c# - test - Interacción significativa con el servidor IIS SMTP en.Net
test smtp iis (3)
Nuestro negocio envía un boletín a un gran número de suscriptores cada semana. Cuando el negocio era muy joven, antes de unirme, usaban una versión "gratuita" de un correo masivo de correo masivo que tardaba seis horas en enviar correos electrónicos de 5K y no cumplía con todos los controles DNS inversos en Internet.
Actualicé esto a un widget .Net personalizado que se ejecutó en el servidor correcto y podría enviar hasta 20,000 correos electrónicos en media hora con cumplimiento completo de DNS. Desafortunadamente (o afortunadamente, según su punto de vista), nuestra lista de correo ya ha superado esta sencilla herramienta. En particular su falta de regulación adecuada, puede generar más correos electrónicos de los que el servidor puede enviar a la vez. Necesito monitorear qué tan completa es la asignación de almacenamiento de correo saliente disponible del servidor IIS SMTP y acelerar la carga en consecuencia.
Desafortunadamente no puedo encontrar información sobre dónde va un objeto de correo cuando (o incluso si) se convierte en un correo. Puedo implementar un sistema de archivos vigilante si tengo un lugar para mirar, actualmente no lo hago. Si nunca se crea un archivo de correo real, creo que tendré que crear uno para implementar la funcionalidad, pero necesito saber dónde colocarlo. También sería más tranquilizador permitir que el sistema confirme el envío de alguna manera, pero no tengo idea de cómo recuperar datos del sistema que dice que se envió un correo.
Extenso Google ha demostrado vago en estos puntos; entonces me preguntaba si alguien aquí sabía dónde podría obtener una guía para estos problemas, o podría orientarme en la dirección correcta.
Muchas gracias.
EDITAR: Al final, dejé de intentar medir el rendimiento en el servidor IIS SMTP como un mal trabajo. Simplemente no parecía querer jugar. Ahora estoy llevando a cabo mi registro en una ubicación separada y solo lo envío al servidor SMTP a partir de entonces. Todavía no conozco a nadie que realmente se moleste en tratar de controlar las actividades del servidor SMTP de IIS y, por lo tanto, esta pregunta a partir de este momento no recibe respuesta.
Oh bien...
Si su widget .net está hecho a medida, ¿por qué no limitar su salida a un rendimiento (definible)?
Como alternativa, es posible que pueda jugar con algunas configuraciones de registro para el servidor SMTP.
http://blog.rednael.com/CommentView,guid,dc20366c-3629-490a-a8ee-7e8f496ef58b.aspx
Aparentemente también hay algunos contadores WMI (Servidor SMTP / Longitud de cola remota y servidor SMTP / Longitud remota de cola de reintento) que le proporcionarán información útil.
Utilizaría el componente PerformanceCounter para leer el contador de longitud de cola local del servicio SMTP. Eso debería mantenerte en control :-)
Está bien, así que he estado trabajando en este proyecto durante años y pensé que podría compartir mis hallazgos con el mundo.
El servidor IIS SMTP
Todos los correos creados con el servidor IIS SMTP se envían, en primera instancia, al directorio de recogida. Si está enviando un correo, tendrá que operar en el momento de Matrix para verlo allí porque probablemente solo lo haga inmediatamente.
En la salida de un correo individual de la puerta, pasa a través de la carpeta de cola en IIS.
Si desea ver el Contador de rendimiento para supervisar este proceso, debería consultar la "Longitud de la cola remota". (La razón de esto es que la "Longitud de la cola local" supervisa los correos enviados "Localmente" dentro de la red. "Remoto" en este caso se refiere a "Fuera del mundo." La definición específica de "Local" se me escapa cuando enviamos no hay correo local, pero me imagino que significa que está en cola para ir a los buzones de correo contenidos dentro de la instalación específica de IIS en el servidor o cualquier agrupación local de los mismos).
Desde el punto de vista de Exchange, parece ser el equivalente de los correos enviados dentro del Dominio de Exchange y los enviados desde ese dominio al resto del mundo.
De todos modos. La longitud de la cola remota no cuenta toda la historia. También debe consultar la cola de reintento remoto, la cantidad de conexiones de salida actuales y, para la correa y los tiradores, la cantidad real de archivos en el directorio de la cola.
Este es el por qué:
- Cola remota: todos los mensajes que aún no se han enviado, sin embargo, muchas veces se ha intentado. La cantidad de correos actualmente asignados a cualquier conexión abierta no se cuenta ya que están en un estado de "prueba".
- Cola remota de reintento: todos los mensajes que aún no se han enviado que, en algún momento en el pasado, se asignaron a una conexión abierta para la entrega. Obviamente, la entrega debe haber fallado o el mensaje se habría entregado. Los mensajes actualmente asignados a una conexión abierta para un reintento no se cuentan.
- Conexiones de salida actuales: muestra cuando el servidor está intentando enviar correos en cola, se puede asignar más de un mensaje a una conexión de salida. Los mensajes así asignados no se cuentan ni en la cola remota ni en la cola remota de reintento. Físico
- Archivos en el directorio de la cola: Muestra la cantidad de correos aún en el directorio de Queue. Esto disminuirá a medida que los correos se entreguen con éxito.
Ejemplo: Si tiene 0 conexiones salientes y 50 correos electrónicos en el directorio Queue, los archivos Remote Queue, Retry Queue y Physical se leerán a 50. Cuando se activa un indicador de reintento (esta es una configuración en IIS) aumenta el número de conexiones y la cantidad de correos en las colas disminuye. Hasta que se entregue un correo, la cantidad de archivos físicos sigue siendo la misma. Sin embargo, dado que se puede enviar más de un correo en una conexión actual, 1 conexión puede dar como resultado longitudes de cola remota y cola de reintento de 47 o menores. Si, durante el evento de reintento, los correos electrónicos se entregan satisfactoriamente, la cantidad de archivos físicos en el directorio Queue disminuirá. Cuando la conexión se cierra, los contadores de cola deben estabilizarse nuevamente.
Explotación florestal
Es posible con la biblioteca de correo de .Net especificar un directorio de recogida separado del IIS predeterminado. Aquí puede poner correos en cola y obtener un servicio personalizado para mover ocasionalmente los correos al directorio de IIS donde el servicio de IIS asumirá el control y enviará los correos en cola.
Para hacer esto, buscará la propiedad "DeliveryMethod" del objeto SmtpClient que se debe establecer en SmtpDeliveryMethod.Specified PickDirectory.
Para establecer realmente el SpecifiedPickupDirectory debe establecer la propiedad PickupDirectoryLocation de SmtpClient.
Cuando los correos se entregan a esta ubicación, se almacenan como archivos .eml. El nombre de archivo es un GUID. Esto significa que se enviarán múltiples correos electrónicos en un orden esencialmente aleatorio. En teoría, podría escribir un código para abordar esta situación si lo desea. El archivo .eml sigue un formato estándar que se puede leer abriendo .eml en el bloc de notas. Al analizar esto, podrá extraer información para un registro.
Espero que esta visión general de alto nivel de la forma en que funciona el servidor SMTP en IIS ayude a alguien que se encuentre en una posición similar a la que tenía en marzo.