MrGlass
MrGlass

Reputation: 9262

Limit swiftmailer emails per second in symfony2

I am setting up SES to work with SMTP2. One of the limitations of SES accounts (atleast by default) is a 5 email per second limit.

I want to setup a spooler, as described in this article. I can use cron to trigger it every minute, which is fine for my purposes. My worry, though, is that a large number of emails will become queued in this spooler and my server will try to send them all at once.

The article lists a method for limiting the total emails sent each execution, as well as a wayt o limit the execution time. Neither fits my use case though: limiting emails sent per second.

Is there any way to limit the rate emails are sent from the spooler?

Upvotes: 3

Views: 2878

Answers (2)

Mario Radomanana
Mario Radomanana

Reputation: 1708

Now, you can use the configuration antiflood with swiftmailer (cf. http://symfony.com/doc/current/reference/configuration/swiftmailer.html#antiflood)

Example

swiftmailer:
    transport: "%mailer_transport%"
    host:      "%mailer_host%"
    username:  "%mailer_user%"
    password:  "%mailer_password%"
    spool:
        type: file
        path: '%kernel.root_dir%/spool'
    antiflood:
        threshold:            1
        sleep:                1

This will send 1 email per second

Upvotes: 2

jmather
jmather

Reputation: 169

Better Solution

Using the Throttler plugin is /fairly/ straightforward.

I'm going to use YML because that's more sane for me:

You have to define a set of custom services. There may be a /slightly/ better way to do this, but it should work.

First, define your throttler service:

services:
  my.throttler:
    class: Swift_Plugins_ThrottlerPlugin
    arguments: [300, 2]

Now define your own instance of the mailer:

services:
  my.mailer:
    class: Swift_Mailer
    arguments: [@swiftmailer.transport]
    calls:
      - [ registerPlugin, [ @my.throttler ] ]

That should set you up to use the service my.mailer to send throttled email at 5/second.

Original Answer

You're going to have to extend the default queue handler to make it work on a more advanced resolution.

Swift_Transport_SpoolTransport is where you're going to want to begin to look.

The other option would be to build a command to run through a daemon service that ran the default spool with the arguments --time-limit=1 --message-limit=5. That would re-run every time it failed.

Extending the SpoolTransport is clearly the saner option, though second resolution is going to be more intensive to track in general.

Upvotes: 4

Related Questions