velocidade de envio de e-mail - como melhorar

velocidade de envio de e-mail - como melhorar

Estou mantendo um servidor para enviar correspondências por e-mail (sem spam, é claro). A velocidade atual desta máquina é de aprox. 2.000 e-mails por hora.

(editar: na verdade, fiz um mailing de teste hoje, removendo a limitação e enviando um mailing para 2.500 assinantes recentes + ativos. Demorou aprox. 1 hora e 45 minutos para enviar isto pelo correio.)

Meu chefe destacou que não está satisfeito com isso, pois viu empresas como Mail Chimp e similares onde você pode enviar milhares de e-mails em alguns segundos/minutos. E eles desaparecem, é claro, conforme você recebe respostas imediatas, aberturas, etc.

Minha pergunta é: o que exatamente é necessário para atingir essa velocidade de envio? Quero dizer, é claro que você pode adicionar hardware e construir um sistema cada vez mais complexo de servidores que enviam seus e-mails, etc. E é claro que também é uma questão de ter uma lista limpa (sem hosts desconhecidos, etc. já que todos eles consomem os recursos do servidor)

Mas, além disso, tenho certeza de que deve haver outras maneiras de melhorar isso. Alguém pode dar uma visão geral sobre isso?

EDITAR

Conforme solicitado nos comentários, aqui estão mais alguns detalhes sobre qual hardware está sendo usado, bem como o comportamento de envio:

Tipo de servidor

Operating system: CentOS Linux 5.11
Kernel and CPU: Linux 2.6.18-400.1.1.el5 on i686
Processor: Intel Core2 Duo CPU E7500 @ 2.93GHz, 2 cores
CPU load averages: 1.07 (1 min) 1.18 (5 mins) 0.65 (15 mins)
CPU usage: 4% user, 1% kernel, 56% IO, 38% idle
Real memory: 1.49 GB used, 1.94 GB total
Virtual memory: 1.13 GB used, 3.91 GB total
Local disk space: 55.10 GB used, 219.71 GB total

MTA

Postfix version 2.3.3

Tamanho médio dos e-mails

Of the recent mailings, the largest one I found was just below 20k.
On average I can say it's probably between 8k and 10k per message.

largura de banda disponível

30Mbit/s symmetrical

Velocidade do disco

hdparm -t /dev/sda

    /dev/sda:
     Timing buffered disk reads:  336 MB in  3.01 seconds = 111.64 MB/sec

dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync

    16384+0 records in
    16384+0 records out
    1073741824 bytes (1.1 GB) copied, 23.9512 seconds, 44.8 MB/s

Medições de várias métricas

CPU load - see above

disk time - ???

RAM usage - see above

bandwidth usage - below data from "iftop -n" over a time period of ca. 5 minutes while sending mail.

    TX:      cum:  3.43MB   peak:  1.16Mb    rates:   5.36Kb  99.5Kb   137Kb
    RX:            1.01MB           120Kb             2.06Kb  38.0Kb  32.3Kb
    TOTAL:         4.44MB          1.28Mb             7.42Kb   137Kb   169Kb

Alguns dados do maillog:

in case this is of value, here are a couple of lines from the maillog:

Mar  4 14:00:32 mailserver postfix/smtp[25768]: 6C419107802A: to=<[email protected]>, relay=mx.example.com[123.123.123.123]:25, delay=1.6, delays=0.05/0/0.14/1.4, dsn=2.0.0, status=sent (250 OK id=1YT8ud-0004fe-Rn)
Mar  4 14:00:32 mailserver postfix/qmgr[2806]: 6C419107802A: removed
Mar  4 14:00:32 mailserver amavis[26392]: (26392-01-46) lookup (score_sender), 1 matches for "[email protected]", results: "."=>[Amavis::Lookup::RE=ARRAY(0xaa7f358),HASH(0xac5f891)]
Mar  4 14:00:32 mailserver amavis[26392]: (26392-01-46) lookup_re("[email protected]"), no matches
Mar  4 14:00:32 mailserver amavis[26392]: (26392-01-46) query_keys: [email protected], myself@, mailserver.com, .mailserver.com, .com, .
Mar  4 14:00:32 mailserver amavis[26392]: (26392-01-46) lookup_hash([email protected]), no matches
Mar  4 14:00:32 mailserver amavis[26392]: (26392-01-46) lookup (score_sender<[email protected]>) => undef, "[email protected]" does not match
Mar  4 14:00:32 mailserver amavis[26392]: (26392-01-46) SpamControl: calling spam scanner
Mar  4 14:00:32 mailserver amavis[26392]: (26392-01-46) spam_scan: DSPAM not available, skipping it
Mar  4 14:00:32 mailserver amavis[26392]: (26392-01-46) timer set to 320 s for SA (was 480 s)
Mar  4 14:00:32 mailserver amavis[26392]: (26392-01-46) calling SA parse, SA version 3.2.5
Mar  4 14:00:33 mailserver amavis[26392]: (26392-01-46) CALLING SA check
Mar  4 14:00:33 mailserver postfix/smtp[25767]: A5341207802D: to=<[email protected]>, relay=mx.example.com[123.123.123.123]:25, delay=1.7, delays=0.15/0/0.14/1.4, dsn=2.0.0, status=sent (250 OK id=1YT8ue-0005BY-5x)
Mar  4 14:00:33 mailserver postfix/qmgr[2806]: A5341107802D: removed
Mar  4 14:00:34 mailserver postfix/smtp[25764]: C30371078144: to=<[email protected]>, relay=mx.example.com[123.123.123.123]:25, delay=1.8, delays=0.05/0/0.13/1.6, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued on mx.example.com as 1425474034-NECyl5JAc9-0Xx8wjwN)

Responder1

Executando eu mesmo uma lista de discussão em um servidor postfix, espero ver 2.000 mensagens sendo processadas pelo menos uma vez (ou seja, elas podem ser adiadas) antes que você possa terminar de preparar uma xícara de café.

Seu sistema parece estar executando verificações de spam e vírus emextrovertidocorrespondência. Embora seja uma boa ideia verificar os e-mails recebidos, provavelmente não é uma boa ideia verificar os e-mails enviados, especialmente se a origem desse e-mail já estiver bem controlada. Podemos ver que isso está adicionando vários segundos à entrega de cada mensagem e que também está aumentando drasticamente a E/S do seu disco.

Eu reconfiguraria o Postfix para parar de verificar os e-mails enviados. Se você precisar verificar os e-mails enviados normalmente, por exemplo, para as pessoas em seu escritório que enviam e-mails de seus computadores, configure um servidor de e-mail dedicado especificamente para lidar com o tráfego de listas de e-mails de saída.

Responder2

Seu problema é a velocidade de E/S, conforme visto pelo alto tempo de espera da CPU. Isso pode ser devido a dois fatores:

  1. o gerenciamento de filas postfix é rico em fsync() e impõe uma carga pesada em termos de IOPS.
    Experimente isto:remonte o sistema de arquivos que hospeda a fila do postfix (normalmente o sistema de arquivos raiz) com a opção de montagem "-o nobarrier". AVISO: isso deve ser considerado apenas um teste, pois a desativação das barreiras de E/S pode levar à perda de dados em caso de queda de energia e/ou falha do sistema operacional.
  2. parece que você também está executando amavis + e spamassassin para e-mails enviados. Embora isso possa ser uma coisa boa (dependendo do ambiente e de seus requisitos), o spamassassin pode reduzir consideravelmente o rendimento do seu e-mail.
    Experimente isto:em amavisd.conf, defina $sa_local_tests_only = 1para excluir todos os testes dependentes da rede e $sa_mail_body_size_limit = 32*1024para reduzir a parte do corpo a ser verificada pelo spamassassin.

Experimente as sugestões acima, uma de cada vez, e cada vez compare seu sistema. Depois conte-nos os resultados.

Responder3

Olá, você não precisa de postfix !!!!

Você precisa escrever um aplicativo multithread para enviar e-mails de (C++, C# .NetCore ou Java)

  • Salve e-mails de boletins informativos no banco de dados mysql

  • Obtenha a lista de registros MX para cada endereço de e-mail do seu banco de dados

  • Envie e-mails para o servidor SMTP (nomes de host) desta lista (na porta 25 - sempre).

Então você pode executar aplicativos e enviar de um ou vários endereços IP de um servidor VPS.

Ou você pode tentar enviar e-mails de vários endereços IP do postfix !!!

Você pode usar o cliente smtp de email C# ou Java

informação relacionada