Help Articles

You are viewing our old help center. Information in this section may be outdated.
Click here to go to our new help center.

Tips For Improving Sending Speed

The speed at which our Email Marketing software sends emails is dependent on your server’s available resources and configuration, along with many other contributing factors. Our software is a PHP script, with a MySQL backend, and as such, it can only perform as quickly as possible within the restraints of your PHP and MySQL settings. Furthermore, email sending speed specifically is also reliant on your MTA (mail server) and MTA configuration. Because the software is installed on your own web server, you are in control of the environment, and so you are in control of performance as well.

Below are just some of the many factors that influence email sending speed:

  • Server hardware (available RAM, processing speed, etc)
  • Operating system (Linux is typically faster than Windows in general)
  • Message size and content (attachments and conditional content will slow sending down considerably)
  • The server’s network configuration and speed (this is especially important if your MySQL database is on a separate machine, or if you are using an external SMTP server to send emails)
  • Amount of memory allocated to MySQL
  • MTA and MTA settings
  • Other processes running on the web server and/or MySQL server

Though sending emails as quickly as possible should never be your top priority (as it could have negative consequences, especially in regards to deliverability), we do have some helpful tips for tweaking server configuration to improve sending speed outlined below.

Optimizing MySQL and Your MTA Configuration

The first step to improving overall performance (including sending speed, searching speed, page loading times, etc), is to optimize MySQL. We usually recommend that you allocate half of your server’s total RAM to MySQL, for optimal performance. This is done by changing the innodb_buffer_pool_size setting in your MySQL configuration file. For example, if your server has 8 GB of RAM total, set the innodb_buffer_pool_size variable to “4G” in your MySQL configuration file (my.cnf), and then restart your MySQL server for the change to take effect. We also recommend setting innodb_flush_log_at_trx_commit to 0.

Our software will try to use InnoDB as the MySQL table engine by default, but your server may have InnoDB support disabled. If that is the case, you may be using MyISAM as the table engine, and you will need to contact your server administrator about other settings that can be changed/increased in your MySQL configuration file to improve performance (or ask if you can have InnoDB enabled on your server).

In addition to optimizing MySQL, your particular MTA (mail transfer agent, or “mail server”) may have configuration settings that can be tweaked as well. This can vary widely from server to server, and so it is difficult for us to provide specific suggestions for everyone, but we do have suggestions for optimizing Qmail and also Sendmail in our How To Optimize Your Server, Mail Server, and Software article. This article also provides more detailed instructions on optimizing MySQL, as well as some common hardware suggestions, and so reading through this entire article is strongly advised.

Determine Where The Performance Bottleneck Is Occurring

If you have already worked closely with your server admin to optimize MySQL and your MTA, and you are still not achieving the sending speed you’re hoping for, the next thing to do would be to take a closer look at the sending process, and try to determine which step of the process is the slowest.

The campaign process has two steps: Preparing Subscribers, and Sending. The Preparing Subscribers stage simply figures out which subscribers should receive the campaign, and moves them in to a separate temporary table in your database. All of this occurs before sending actually begins.

Optimizing the Preparing Subscribers Stage

If you find that the Preparing Subscribers stage takes a very long time, here are some tips to speed it up:

  • Allocate more memory to MySQL, as described above.
  • If you have already allocated as much RAM to MySQL as you can spare, consider adding more memory to your server, and allocating even more RAM to MySQL.
  • Are you using a segment to send this campaign? If the segment is especially complicated, it could take the software longer than usual to determine which subscribers should receive the campaign and transfer them to the temporary table. Try simplifying your segment, to use less complicated conditions. Or, try creating a separate list containing only these subscribers, and send to that list without a segment to see if the speed improves.
  • Do you have a large amount of email addresses or patterns on your Exclusion list? (The Exclusion List can be found by going to the Subscribers tab and clicking Excluded Subscribers on the right.) The more emails/patterns you have, the longer it will take for our software to determine which subscribers should receive the campaign, and which should not. If you can, try simply deleting the subscribers directly from your list(s), rather than adding them to the Exclusion List. Try to come up with a way to manage your subscribers that does not rely on adding large amount of email addresses to the Exclusion List, as that will cause the Preparing Subscribers stage to run more slowly.
  • Do you have a large number of lists, with many of the same subscribers on them? If so, see if there is any way you can reduce the number of lists in your system. Also, consider deleting old lists that you no longer send to. Having a large number of lists will cause the em_subscriber_list table in your database to become very large, and it can take our software a long time to search through it when it needs to prepare subscribers for your campaign. (Note: deleting list will also delete all campaigns and reports for that list.)

These tips above will help speed up the Preparing Subscribers stage, as well as boost performance of the software overall.

Optimizing the Sending Stage

If you find that the Sending stage in particular is running very slowly, you’ll need to take a closer look at what you’re sending, what is happening on your webserver during sending, and what is happening on your mail server as well. The Sending stage is broken down into separate steps. The best way to figure out which step of the Sending process is causing the performance bottleneck is by enabling campaign sending logs.

Please refer to our article titled Troubleshooting The Campaign Sending Process to read about how to enable our software’s sending logs. If you turn this  option  on, every campaign that you send will create a text file in your software’s /cache folder on your server. This text file will outline every single step of the sending process, and it will show you exactly what happens with every single email that is sent. With every step of the sending process, a time stamp will be recorded, and you can compare time stamps between steps to see which step of the sending process is taking the longest amount of time.

Below is an excerpt from a campaign log that was generated by our software:

[[2012-06-13 10:10:05 0.017130]] Found 0 RSS blocks in HTML message.
[[2012-06-13 10:10:05 0.019986]] Found 0 RSS blocks in text message.
[[2012-06-13 10:10:05 0.009185]] Initializing decorator's multi-message storage slot (cache var) 
for this message (#29)
[[2012-06-13 10:10:05 9.5E-500]] Initializing decorator's multi-message storage slot (parts var) 
for this message (#29)
[[2012-06-13 10:10:05 0.000413]] PreDecorator will NOT be reverted.
[[2012-06-13 10:10:05 0.000132]] Initializing decorator's multi-message storage slot (cache var) 
for this message (#29)
[[2012-06-13 10:10:05 9.2E-500]] Decorator: Personalize message content...
[[2012-06-13 10:10:05 0.005977]] Decorator WILL BE reverted.
[[2012-06-13 10:10:05 0.001501]] SENDING AN EMAIL TO (0=1296@7):
[[2012-06-13 10:10:05 0.000356]] >> MAIL FROM: <>
[[2012-06-13 10:10:05 0.058139]] << 250 2.1.0 <>... Sender ok
[[2012-06-13 10:10:05 0.000244]] >> RCPT TO: <>
[[2012-06-13 10:10:05 0.043325]] << 250 2.1.5 <>... Recipient ok
[[2012-06-13 10:10:05 0.000323]] >> DATA
[[2012-06-13 10:10:05 0.037609]] << 354 Enter mail, end with "." on a line by itself
[[2012-06-13 10:10:05 0.060610]] >> <MESSAGE DATA>
[[2012-06-13 10:10:05 0.000207]] >>
[[2012-06-13 10:10:05 0.174500]] << 250 2.0.0 q5DFA2mf022196 Message accepted for delivery
[[2012-06-13 10:10:05 0.000218]] SENT TO SUBSCRIBER (0=1296@7)
[[2012-06-13 10:10:05 5.2E-500]] Saving the sending result...
[[2012-06-13 10:10:05 5.2E-500]] Updating the campaign...
[[2012-06-13 10:10:05 0.004878]] Campaign updated.
[[2012-06-13 10:10:05 0.003238]] Subscriber updated.
[[2012-06-13 10:10:05 0.001575]] Mailer updated.
[[2012-06-13 10:10:05 0.003367]] Subscriber processed.

This excerpt shows everything that happens when an email is sent to a single subscriber. As you can see, our sending engine has to run through a variety of checks and processes for each and every email that is sent. In the above example, you can see that the most time consuming step of the process is transferring the message to the mail server and waiting for a response (colored in red). This would imply that either the connection between the mail server and web server needs to be improved, or the mail server performance needs to be optimized. If the mail server was an external SMTP server (which in this example, it was), then changing your server configuration so that it uses a mail server on the same physical machine as the web server (instead of using an external SMTP server located elsewhere) could improve sending speed as well.

This is merely one example. In general, if the last few steps of the process are slow (the “campaign updated” and “subscriber updated” steps, for example) are slow, it could indicate that you need to reduce the size of your database, or optimize/upgrade your database server. If the decorator/personalization steps are slow, it could indicate that you need to optimize or upgrade your database server and possibly your web server also (as those steps require a lot of PHP processing time as well). Be sure to work closely with your server admin to analyze the logs and compare them to what is occurring on your web server, mail server, and database server, to determine how best to improve sending speed moving forward.


Sending speed is determined by many factors, but what it ultimately depends on is server configuration, hardware, and resources. Though we cannot offer exact server recommendations for every individual clients (as everyone has independent needs), we hope that this article has proven to be a valid and helpful resource for on-site Active Campaign Email Marketing users who are interested in increasing their sending speed. Should you have any further questions or concerns, please do not hesitate to contact our support department for assistance.