3 ms·
Sendy has abysmal performance for large lists though.
by PetahNZ 7y ago
Sendy has abysmal performance for large lists though.
- masukomi 7y agothat's because SES HATES being used. IT's very much a "If you absolutely _must_ send and email from here.. fine. we'll let you, but you _really_ ought to use some other service."
- JoshTriplett 7y agoCan you elaborate a little on that? SES looks reasonable from the outside; what problems does it have that other email services don't?
- robjan 7y agoNot GP but I can give you my experience. SES seems to be a "good enough" solution if you use their API. There are a lot of missing features, such as logging anything other than metadata, which makes it not so useful if you are operating in a regulated industry. The real problems come when you try to use the SMTP gateway. It's quite slow and unreliable and doesn't really work for parallel workloads. The only way to somewhat mitigate it is to deploy a postfix into EC2 and then queue your emails there.
- JoshTriplett 7y ago> The real problems come when you try to use the SMTP gateway. It's quite slow and unreliable and doesn't really work for parallel workloads. Ah, that's helpful to know. I would normally have wanted to use the SMTP gateway as a more portable API, to avoid tying things to Amazon-specific APIs. But it sounds like doing so would add substantial fragility.
- shortj 7y agoI'll never understand why they haven't fixed that. A while ago I ended up writing a little patch that parallelized list sends with Redis backing things and some worker processes. Took me maybe a day of work. If I remember right we were easily getting a few hundred sends a second, could have easily gone faster. Default Sendy was a few a second on the same machine/resources. SES can support tremendous send rates if you get limit lifts from AWS.