it-swarm-es.com

Volumen de correo electrónico SMTP

La aplicación de mi empresa tiene un sistema de correo electrónico masivo, todo personalizado, utilizado por nuestros clientes para enviar correos electrónicos basados ​​en inscripciones. Mientras realizamos la supervisión del rendimiento durante algunos envíos por lotes de correo electrónico particularmente grandes, notamos que parece haber una barrera artificial causada por nuestro mecanismo de envío actual (phpMailer). Por un breve tiempo redirigimos nuestro correo a través de un servicio SMTP de terceros, pero nos dimos cuenta de que no enviaban más rápido que nosotros. Ahora que la responsabilidad del envío ha vuelto a nosotros, estamos realizando pruebas exhaustivas en previsión de una serie de grandes clientes futuros.

Suponiendo que mejoramos la velocidad de envío para nuestro protocolo de envío de correo (estamos considerando cambiarnos por completo a SwiftMailer) estaba contemplando si nuestro servidor SMTP también podría convertirse en un cuello de botella. ¿Qué tipo de rendimiento puede lograr desde su servidor SMTP? ¿Qué consideraciones sobre el envío SMTP (como autenticación, empaquetado, etc.) podría tener que reconsiderar al realizar ajustes de rendimiento?

5
bpeterson76

Siempre que utilice un servidor SMTP sin bloqueo (en caso de que golpee un servidor DNS/SMTP defectuoso), se trata de cuántos dominios diferentes están destinados los correos electrónicos y cuál es el ancho de banda (más o menos porque las excepciones a la regla aparecen en los extremos). Sospecharía que esto último (ancho de banda) debido a que ve resultados similares con un servidor externo.

Cualquier empaque/encriptación en hardware moderno toma una fracción del tiempo necesario para enviar un correo electrónico a un servidor lento. Si aloja sus propios servidores DNS, asegúrese de que estos devuelvan resultados rápidos, ya que el servidor SMTP receptor probablemente querrá volver a verificar sus registros (ralentizando aún más las cosas). Tener dos servidores de correo (con suficiente ancho de banda) es normalmente mucho más rápido (debido al bloqueo en un servidor de recepción lenta) que gastar la misma cantidad de dinero en un servidor único mejor especificado.

Trucos desagradables para victorias rápidas

  1. Ordenar las direcciones de correo electrónico por nombre de dominio. Si crea una nueva tabla de base de datos que cuelga de la tabla donde almacena la dirección de correo electrónico, puede contener la clave externa, la parte del usuario y la parte del dominio. Una ejecución para dividir los datos existentes y algunos cambios en el CRUD para actualizar los registros lograrán esto. Al ordenar el nombre de dominio, permitirá que el servidor remitente reutilice su conexión con el servidor de correo remoto (tenga cuidado de no bloquear el SPAM).

  2. Cuando el código es difícil de cambiar y desea alternar los servidores de correo, puede alterar la función para que acepte una referencia (prefijarla con un & en PHP) y luego puede usar una variable $ _GLOBAL que se cambia cada x segundos por un programador que llama a una página oculta PHP.

  3. Utilice un caché de DNS local y consulte los registros MX necesarios antes de la ejecución (o al menos inicie un script para ejecutarlo en paralelo). La mayoría de los cachés mantendrán registros durante 24 horas (normalmente escritos como 3600 segundos). Puede reducir la latencia de conexión inicial en unos 100 ms. Si tiene varios servidores SMTP y el receptor tiene varios registros MX, puede falsificar los resultados. Entonces su primer servidor de envío ve:

    • Registro MX 1 Prioridad 10
    • Registro MX 2 Prioridad 20
    • Registro MX 3 Prioridad 30
    • Registro MX 4 Prioridad 40

    y su segundo servidor de envío ve

    • Registro MX 1 Prioridad 40
    • Registro MX 2 Prioridad 10
    • Registro MX 3 Prioridad 20
    • Registro MX 4 Prioridad 30

    etc. De esta manera puede aumentar el comportamiento paralelo, pero erosiona cualquier ganancia desde el punto 1.

Si puede ejecutar un rastreo de paquetes para identificar los cuellos de botella, ayudará a encontrar las ganancias rápidas necesarias.

3
Metalshark

Por mucho que amo PHP, ahí es donde está el cuello de botella en su sistema. PHP simplemente no tiene la eficiencia de otros idiomas cuando se trata de procesamiento de texto.
https://stackoverflow.com/questions/603163/is-Perl-a-good-option-for-heavy-text-processing

Perl será una mejor opción para procesar y enviar correos electrónicos. Hace unos años, había escrito un programa simple de Perl que enviaría correos electrónicos personalizados a nuestras opciones. Pude enviar alrededor de 80,000 correos electrónicos en 6 horas usando Perl para crear el correo electrónico y enviarlos al programa local Sendmail. Esto estaba en un servidor privado virtual bastante estándar con 2 GB de RAM.

¿Está enviando los trabajos al proceso local de Sendmail o PHPMailer está utilizando SMTP? El programa local Sendmail será más rápido ya que PHP no tiene que abrir ningún conector de red para enviar el correo electrónico.

En resumen, deberías:

  1. Use Perl en lugar de PHP (también odio a Perl, pero es una mejor herramienta de procesamiento de texto)
  2. Envíe el trabajo al programa Sendmail local (que puede configurarse para reenviar los trabajos a servidores SMTP externos si es necesario)
  3. Use un servidor SMTP externo si el local se sobrecarga.
3
Shane Stillwell