Campaign: velocità effettiva di consegna in batch inferiore al previsto
Una consegna e-mail in batch può essere inviata più lentamente del previsto anche in assenza di difetti funzionali nell’infrastruttura di invio. In questo modello, la consegna non viene bloccata, ma la velocità di invio ottenuta scende perché il contenuto dell’e-mail è troppo grande per la capacità di invio disponibile per essere elaborato alla velocità effettiva prevista.
Descrizione description
Una consegna è stata segnalata come insoddisfacente rispetto al target orario di invio previsto. La frequenza di invio prevista era di 20 milioni di e-mail all’ora. I test hanno mostrato un massimo di ~13 milioni di e-mail consegnate in un’ora.
La revisione iniziale non mostrava un errore persistente della piattaforma.
La preparazione della consegna ha registrato:
Avviso: la dimensione del contenuto della consegna supera i 200,0 kB (227,2 kB).
Risoluzione resolution
Dall’analisi di follow-up è emerso che il principale fattore che ha contribuito è stata la dimensione del contenuto dell’e-mail, notevolmente superiore agli orientamenti sulle best practice.
Quando la dimensione del contenuto è stata ridotta nei test di follow-up, la velocità effettiva è migliorata materialmente. Ciò ha confermato che il problema era principalmente correlato alle dimensioni dei messaggi e ai costi di elaborazione, non a un’interruzione generale della piattaforma.
Perché la dimensione dell’e-mail influisce sulla velocità di invio?
La dimensione dell’e-mail ha un effetto diretto sulla velocità effettiva perché ogni messaggio deve essere:
- assemblato per il destinatario,
- elaborati per la personalizzazione e il tracciamento,
- preparati per la trasmissione,
- firmati e imballati per la consegna,
- trasferite tramite la rete.
Man mano che il payload HTML cresce, ciascuno di questi passaggi diventa più costoso.
In invii batch di grandi volumi, questo costo viene moltiplicato per milioni di messaggi. Anche se il sistema rimane integro, i messaggi più grandi richiedono una maggiore larghezza di banda CPU e di rete sul livello di invio. Una volta che tali risorse sono sature, il sistema può comunque inviare correttamente, ma la percentuale di messaggi all’ora diminuisce.
Perché?
I motivi più comuni per cui le e-mail più grandi rallentano la consegna sono:
- È necessario trasmettere più byte per destinatario. I messaggi più grandi richiedono un maggiore trasferimento di rete in uscita. Solo questo può essere un fattore limitante.
- È necessaria un’ulteriore elaborazione per messaggio. I corpi HTML più grandi aumentano il lavoro necessario per l’assemblaggio dei contenuti, la personalizzazione, la gestione dei collegamenti di tracciamento e la creazione di pacchetti di messaggi.
- Il livello di invio raggiunge prima i limiti delle risorse. Quando la larghezza di banda di CPU o in uscita è completamente utilizzata, il throughput raggiunge livelli elevati. Ciò non indica necessariamente un malfunzionamento, ma può semplicemente indicare che l’infrastruttura funziona a piena capacità per la dimensione del messaggio corrente.
- La progettazione del modello può aumentare le dimensioni in modo imprevisto. Un markup eccessivo o una personalizzazione eccessivamente complessa possono aumentare le dimensioni del messaggio renderizzato ben oltre quanto è evidente durante l’authoring.
Con una dimensione superiore a 200 kB per ogni messaggio e utilizzando 2 server MID-sourcing con 2 contenitori server ciascuno, è stato osservato che durante l’invio:
CPU 100% sostenuto su tutti e 4 (spazio utente - assembly messaggi / DKIM)
Rete 210 MB/s TX per host (850 MB/s nei 4 contenitori)
Memoria utilizzata al 35%, swap 0, iowait 0%
Velocità raggiunta 17,6 M/h
iowait 0 e memoria 31% significano che nulla è affamato o bloccato. CPU al 100% significa che il livello MID è il collo di bottiglia attivo ed è completamente utilizzato, che è esattamente ciò a cui un test di throughput lo spinge. L’unica cosa che CPU rappresenta al 100% è che non c’è spazio libero per CPU, quindi un ulteriore throughput, o margine, proviene da e-mail più leggere o più core/contenitori MID.
La best practice di Adobe prevede di mantenere un’e-mail di circa 35 kB: https://experienceleague.adobe.com/it/docs/campaign/campaign-v8/send/delivery-best-practices