desenv-web-rp.com

Volume de email SMTP

O aplicativo da minha empresa possui um sistema de e-mail em massa, todo personalizado, usado por nossos clientes para enviar e-mails com base em opt-ins. Ao fazer o monitoramento de desempenho durante alguns envios de lotes de e-mail particularmente grandes, percebemos que parece haver uma barreira artificial causada por nosso mecanismo de envio atual (phpMailer). Por um breve período, redirecionamos nosso e-mail por um serviço SMTP de terceiros, mas percebi que eles não estavam enviando mais rápido do que nós. Agora que o ônus do envio está de volta, estamos testando minuciosamente em antecipação a vários grandes clientes futuros.

Supondo que melhorássemos a taxa de envio para o nosso protocolo de mala direta (estamos considerando mudar completamente para o SwiftMailer), eu estava pensando se nosso servidor SMTP também poderia eventualmente se tornar um gargalo. Que tipo de taxa de transferência você consegue no seu servidor SMTP? Que considerações sobre o envio de SMTP (como autenticação, empacotamento etc.) posso ter que reconsiderar ao fazer ajustes no desempenho?

5
bpeterson76

Desde que você esteja usando um servidor SMTP sem bloqueio (caso ele atinja um servidor DNS/SMTP ruim), é uma questão de quantos domínios diferentes os emails são destinados e qual é a largura de banda (grosso modo, porque o exceções à regra aparecem nos extremos). Eu suspeitaria do último (largura de banda) devido a resultados semelhantes com um servidor externo.

Qualquer empacotamento/criptografia em hardware moderno leva uma fração do tempo necessário para enviar um email para um servidor lento. Se você hospedar seus próprios servidores DNS, verifique se estes retornam resultados rápidos, pois o servidor SMTP receptor provavelmente desejará verificar novamente seus registros (diminuindo ainda mais a velocidade). Ter dois servidores de correio (com largura de banda suficiente) é normalmente muito mais rápido (devido ao bloqueio em um servidor de recebimento lento) do que gastar a mesma quantia em um servidor único com melhor especificação.

hacks desagradáveis ​​para vitórias rápidas

  1. Classifique os endereços de email por nome de domínio. Se você criar uma nova tabela de banco de dados suspensa na tabela em que armazena o endereço de email, ela poderá conter a chave estrangeira, a parte do usuário e a parte do domínio. Uma execução para fazer a divisão nos dados existentes e algumas alterações no CRUD para atualizar os registros conseguirão isso. Ao classificar o nome do domínio, você permitirá que o servidor remetente reutilize sua conexão com o servidor de email remoto (cuidado para não bloquear o SPAM).

  2. Onde o código é difícil de alterar e você deseja alternar os servidores de correio, basta alterar a função para que ele aceite uma referência (prefixe-o com um & no PHP) e use uma variável $ _GLOBAL que é alterada a cada x segundos por um agendador que chama uma página PHP oculta.

  3. Use um cache DNS local e consulte os registros MX necessários antes da execução (ou pelo menos inicie um script para executar em paralelo). A maioria dos caches manterá registros por 24 horas (normalmente gravados como 3600 segundos). Pode reduzir a latência inicial da conexão em cerca de 100ms. Se você possui vários servidores SMTP e o receptor possui vários registros MX, você pode falsificar os resultados. Portanto, seu primeiro servidor de envio vê:

    • Prioridade 10 do registro MX 1
    • Prioridade 20 do registro MX 2
    • Prioridade 30 do registro MX 3
    • Prioridade 40 do registro MX 4

    e seu segundo servidor de envio vê

    • Prioridade 40 do Registro MX 1
    • Prioridade 10 do registro MX 2
    • Prioridade 20 do registro MX 3
    • Prioridade 30 do registro MX 4

    etc. Dessa forma, você pode aumentar o comportamento paralelo, mas corroe quaisquer ganhos do ponto 1.

Se você puder executar um rastreamento de pacotes para identificar os gargalos, ajudará a encontrar as vitórias rápidas necessárias.

3
Metalshark

Por mais que eu goste de PHP, é aí que está o seu gargalo no seu sistema. PHP simplesmente não possui a eficiência de outros idiomas quando se trata de processamento de texto.
https://stackoverflow.com/questions/603163/is-Perl-a-good-option-for-heavy-text-processing

Perl será uma escolha melhor para processar e enviar e-mails. Alguns anos atrás, eu escrevi um programa Perl simples que enviava e-mails personalizados para nossos opt-ins. Consegui enviar cerca de 80.000 emails em 6 horas usando o Perl para criar o email e enviá-lo ao programa local do Sendmail. Este foi em um servidor privado virtual bastante padrão com 2 GB de RAM.

Você está enviando os trabalhos para o processo local do Sendmail ou o PHPMailer está usando SMTP? O programa local do Sendmail será mais rápido, pois PHP não precisa abrir nenhum soquete de rede para enviar o email.

Então, em resumo, você deve:

  1. Use Perl em vez de PHP (eu também odeio Perl, mas é uma melhor ferramenta de processamento de texto)
  2. Envie o trabalho para o programa local do Sendmail (que pode ser configurado para encaminhar os trabalhos para servidores SMTP externos, se necessário)
  3. Use um servidor SMTP externo se o local ficar sobrecarregado.
3
Shane Stillwell