Extremely sluggish mail sends
UPDATE (June 2): I've resolved this for my setup by rolling back — full details in the comments below. Leaving the original post for context, since it seems others hit the same thing.
After upgrading to 3.0 / 3.1, sending large campaigns became extremely slow on my setup. A campaign to ~30,000 subscribers was taking days to finish, where before it took well under an hour.
My configuration: FluentSMTP, server-side cron correctly set, ample memory, and no changes whatsoever to the configuration — only the plugin version changed.
I did quite a bit of testing to rule things out (server, memory, SMTP, cron) before posting, and I'd be glad to share what I found. Has anyone else run into this after the 3.x upgrade, and found a path forward?
Update — sharing how I resolved this, in case it helps anyone in the same situation.
I rolled back to 2.9.86, and the difference was night and day. Same server, same SMTP, same Elastic Email account, same config — only the plugin version changed.
The same ~25,000-subscriber campaign that had been crawling for hours/days on 3.1.0 completed in 39 minutes on 2.9.86 (measured directly, first email to last).
On the multi-threading point (which I know is the usual recommendation): I did have it enabled on 3.1.0. The issue on my Kubernetes-based host was that the 3.x multi-threading would burst briefly, then the background workers got reaped and it stalled — rows cycling between processing and pending. That's what pushed me to manual CLI workers, and even those only reached ~40/min in bursts. On 2.9.86 the same built-in multi-threading just runs cleanly through Action Scheduler, no manual workers needed.
I also noticed hundreds of cURL error 28 (connection timeout) entries at high send rates on 3.1 — which would fit with a fresh HTTPS connection being opened per email rather than reused. Much less of that on 2.9.86.
I want to be fair to the team — clearly enormous work has gone into 3.x, and I'm sure it runs well on many setups. But for a production workload like mine, 2.9.86 is currently the more reliable choice. Happy to share my full diagnostics (SQL, send-rate measurements, server load, cron logs) if it would help engineering find what changed.
Shahjahan Jewel — thank you for the doc and the quick reply earlier; I hope these concrete numbers from a real rollback are useful for narrowing it down.