AWS SES слишком медленно отправляет электронные письма нескольким получателям - PullRequest
Новая
       27

AWS SES слишком медленно отправляет электронные письма нескольким получателям

0 голосов
/ 24 января 2012

Я создал модуль «Очередь заданий», который обрабатывает задания и создает электронные письма типа «социальной сети». 2 процесса состоит из:

  1. Создание пользовательских писем (просмотров), например. User A and User B have commented on your post или User B and User C also likes User C's post. Каждый получатель получает разные письма. Сначала я создал новый экземпляр Swiftmailer и добавил содержимое сообщения, тему и получателя. Затем я добавил эти экземпляры в базу данных.

  2. Запускается задание cron для получения и отправки этих писем в более позднее время.

Во время бенчмаркинга я понял, что он отправляет 2 электронных письма в секунду. Поэтому я попытался хранить Swift_Message Экземпляры в базе данных. Не повезло, но все равно долго.

В настоящее время код

  • Создает новый Swift_SmtpTransport.
  • Создает новый экземпляр Swift_Mailer.
    • Повторяет сообщения Swift_Message, полученные из БД
    • Отправляет каждое электронное письмо.

Но это по-прежнему в среднем около 2 писем в секунду. Могу ли я улучшить процесс, чтобы ускорить доставку? Я использую Amazon SES в качестве своего SMTP-транспорта и знаю, что он может обрабатывать как минимум 5 электронных писем в секунду.

Так что, наверное, я что-то не так делаю. Любые мысли приветствуются.

EDIT

Имейте в виду, что сообщения различаются для каждого получателя. Я мог бы попробовать плагин Swift_Decorator, но это будет означать, что мне придется изменить способ генерирования представлений. Я просто ищу другие альтернативы, чтобы ускорить процесс.

1 Ответ

2 голосов
/ 25 января 2012

Я использую Amazon SES в качестве своего SMTP-транспорта

В моем опыте использования SES время ответа API минимум , которое я видел, было вдвое меньше.второй диапазон, в то время как средний колебался около одной секунды.Это не ограничение соединения, TCP / IP, доступной полосы пропускания и т. Д., А их обработка запросов на соединение.Другие на официальных форумах поддержки сообщают то же самое.Транспорт SMTP не работает быстрее.

Единственный способ отправить быстрее - это отправлять параллельно.Это подход, который они рекомендовали на своих официальных форумах поддержки.

SES API разрешает несколько одновременных подключений, пока вы остаетесь в квоте «почты в секунду».Если вы не знаете свою текущую квоту в секунду, проверьте статистику отправки.Я не знаю, что описатели транспорта SMTP превышают это ограничение.

Для параллельной отправки большего объема почты мы изменили наш процессор очереди, чтобы он мог работать параллельно.Чтобы письма никогда не отправлялись дважды, мы добавили в таблицу столбец «PID x grabbed this» и выполнили запрос, аналогичный UPDATE Queue SET selected_pid = ? WHERE target_ts < NOW() AND selected_pid IS NULL LIMIT X.Затем мы будем искать письма, которые мы можем отправить, отправлять их все, и затем повторять попытки, пока у нас не закончатся письма, которые нам нужно будет отправить за этот период.

Мы также изменили код, который заполняеточередь, чтобы гарантировать, что в очереди никогда не будет больше писем, чем мы могли бы отправить.Мы смогли сделать это, потому что мы отправляем почту партиями.Когда у вас есть постоянный поток писем, есть вероятность, что вам не придется перепрыгивать через это кольцо.Просто убедитесь, что ваш отправляющий код знает, как правильно реагировать на различные ошибки превышения квоты.

В качестве альтернативы процессору очереди на основе cron, рассмотрите возможность использования Gearman для настройки набораасинхронных фоновых работников для отправки почты.

...