Skip to main content
CiviCRM

Return to Answer

Add more information about how to actually speed up the send rate
Source Link
John
John
  • 1.9k
  • 9
  • 29

There are a couple of points to this.

1 - SMTP is chatty, it is a fairly slow protocol. To combat this, run several mailing jobs in parallel. This can be achieved by calling the process_mailing cron job multiple more frequently. Ensure that the 'cron job limit' is equal to the maximum number mailing jobs you would want to be active at any one time. This is useful if you have a sending limit on your SMTP server of x per second.

2 - The issue with 10 emails sent 'on the same second' and then a delay: MailingJob.php processes 10 emails at once, and then writes the transactions to the database all at once. So it looks like the emails were all sent on the same second. The '10' is defined in BULK_MAIL_INSERT_COUNT in CRM_Mailing_Config. Ideally the actual time of sending would be recorded in the database, rather than the time of writing.

To speed up mailings we now call the process_mailing job independently every 5 minutes, and limit the number of emails that are sent on a cron run. This means we have several cron jobs running sending emails at once for large mailings, which greatly improves our send rate.

There are a couple of points to this.

1 - SMTP is chatty, it is a fairly slow protocol. To combat this, run several mailing jobs in parallel. This can be achieved by calling the process_mailing cron job multiple more frequently. Ensure that the 'cron job limit' is equal to the maximum number mailing jobs you would want to be active at any one time. This is useful if you have a sending limit on your SMTP server of x per second.

2 - The issue with 10 emails sent 'on the same second' and then a delay: MailingJob.php processes 10 emails at once, and then writes the transactions to the database all at once. So it looks like the emails were all sent on the same second. The '10' is defined in BULK_MAIL_INSERT_COUNT in CRM_Mailing_Config. Ideally the actual time of sending would be recorded in the database, rather than the time of writing.

There are a couple of points to this.

1 - SMTP is chatty, it is a fairly slow protocol. To combat this, run several mailing jobs in parallel. This can be achieved by calling the process_mailing cron job multiple more frequently. Ensure that the 'cron job limit' is equal to the maximum number mailing jobs you would want to be active at any one time. This is useful if you have a sending limit on your SMTP server of x per second.

2 - The issue with 10 emails sent 'on the same second' and then a delay: MailingJob.php processes 10 emails at once, and then writes the transactions to the database all at once. So it looks like the emails were all sent on the same second. The '10' is defined in BULK_MAIL_INSERT_COUNT in CRM_Mailing_Config. Ideally the actual time of sending would be recorded in the database, rather than the time of writing.

To speed up mailings we now call the process_mailing job independently every 5 minutes, and limit the number of emails that are sent on a cron run. This means we have several cron jobs running sending emails at once for large mailings, which greatly improves our send rate.

Source Link
John
John
  • 1.9k
  • 9
  • 29

There are a couple of points to this.

1 - SMTP is chatty, it is a fairly slow protocol. To combat this, run several mailing jobs in parallel. This can be achieved by calling the process_mailing cron job multiple more frequently. Ensure that the 'cron job limit' is equal to the maximum number mailing jobs you would want to be active at any one time. This is useful if you have a sending limit on your SMTP server of x per second.

2 - The issue with 10 emails sent 'on the same second' and then a delay: MailingJob.php processes 10 emails at once, and then writes the transactions to the database all at once. So it looks like the emails were all sent on the same second. The '10' is defined in BULK_MAIL_INSERT_COUNT in CRM_Mailing_Config. Ideally the actual time of sending would be recorded in the database, rather than the time of writing.