Is Your Email Up To Speed?

In the Driver’s Seat with GreenArrow Software.

Imagine a sports car—a really fast one. How do you know it’s fast? Is it the speedometer? The engine? The collection of speeding tickets wedged in the glove box?

Now imagine your email sending software. Is it fast? Exactly how fast is it? And perhaps more important, why does it matter to your bottom line? Today, I want to show you under the hood of our own GreenArrow and take you for a spin around the track so you can better understand how fast it is. First, let’s define what kind of speed we’re talking about here. This article is not about how fast your email loads in a user’s mail client, or how fast the ISPs accept your mail. Those topics are important, but they are entirely separate from what I want to show you. This article is about the software speed itself—what it can really do for you.

The Need For Speed

Let’s start with an obvious question: Why is email sending speed important?

In a word, money. That’s right! We focus on speed because it can cut your expenses and build revenue. Here are a couple of examples.

Savings

Thanks to reduced hardware requirements and performance optimizations, our users often report reduced costs. Regardless of whether those costs are paid by the customer directly for on-premise software or to their hosting provider—they will be much less.

Revenue

Suppose you’re an email marketer who wants to send a time-sensitive promotion or news item to your list of 8 million subscribers. If the software you’re using limits you to 100,000 messages per hour, it will take 3 days and 8 hours to send them all. For the unlucky subscribers at the end of the list, your email could be irrelevant, inaccurate, or even misleading!

Or worse, suppose you have a spike in sales that creates a backlog of transactional emails (such as receipts or order confirmations). If your messages are delayed, what happens? For starters, customers might begin to think their order was mishandled. They might become unhappy that didn’t get “the deal” or worry that their itinerary is stuck in limbo. Some will call the help desk; others blame themselves and make the same purchase over again, which just adds insult to injury. What was meant to be an online convenience is now an unhappy customer experience (which may impact their next purchase)—all because of slow email.

These are just some examples of why our customers have chosen GreenArrow. The hypothetical, four-day long campaign can be sent in two hours or less with GreenArrow—and at minimal cost. Win-win!

What’s Under the Hood?

We’ve cherry-picked five components (from a much larger list) that make GreenArrow fast:

1) GreenArrow’s RAM Queue

Compared to hard drives, RAM is fast—up to 42 times faster in transfer and 100,000 times faster in latency. In fact, DDR-4-2400 RAM can transfer data at 25.6GBps, while most hard drives are limited to 600MBps or less. Even higher-end SSD drives can’t keep up with the speeds that RAM is capable of.

And yet, for some reason, many email sending applications still rely on hard drives to get the job done. A typical email server does something like the following each time a message gets injected:

1. Write the message to a queue that resides on hard drives.
2. Attempt to deliver the message.
3. Once the message is successfully delivered or bounces, delete it from the queue.

For senders with good deliverability, the majority of their emails are accepted on the first delivery attempt, so those files in the mail server’s queue are often short-lived. David Harris (our CEO) saw an opportunity to improve this process: since most emails only exist in the send queue briefly, why not just store them in RAM instead of writing them to a hard drive and then deleting them?

We call this the RAM Queue, and it’s where messages go when they’re first injected into GreenArrow. Sent messages are only written out to a hard drive if their first delivery attempt is deferred or throttled. As you can imagine, this can reduce the average disk activity per message to a fraction of what it would be otherwise. (To learn more about Email Throttling, check out our post, Email Throttling Basics: What You Need to Know.)

2) Our DNS Cache

DNS (the Domain Name System) is an important part of the email ecosystem because it tells the email sending software exactly where to deliver a given message. If DNS goes down, emails won’t go out; if DNS is slow, then email sending is slow.

GreenArrow addresses this problem by caching DNS results. This cache allows us to reduce the amount of time needed to deliver each message, especially when emails are being sent to the same domain name over and over again.

For example, I’ll bet that a large portion of your subscribers have addresses @gmail.com. By using a DNS cache, GreenArrow sees normal lookup performance the first time it delivers to one of these subscribers, but vastly improved performance for all other subscribers at the same domain.

GreenArrow’s DNS cache also improves reliability by querying IANA’s root name servers directly. These root name servers are distributed throughout the world, and there are hundreds of them. If some of these servers go offline or start responding slowly, GreenArrow automatically queries others and keeps on zipping along.

3) Our Performance Tuning

Another part of how we make GreenArrow fast is by giving it a tune-up before letting it hit the road. Every time we set up a new server, a member of our systems administration team personally reviews it and verifies that it’s properly tuned up and ready to go.

Not only do we tweak some settings in the Linux distributions we use, we also optimize some settings within GreenArrow itself. These changes are usually specific to the available hardware, such as setting the size of the RAM Queue based on the total amount of RAM available.

For our techy readers, here are a few examples:

• We set the size of GreenArrow’s RAM queue. This impacts how much RAM is used and how many messages GreenArrow can hold in this queue.
• We tune GreenArrow’s PostgreSQL database to use a configuration that’s optimal for the server’s hardware and anticipated data set.
• We turn on the noatime option for filesystems so that the operating system doesn’t have to update a filesystem’s metadata each time a file is read. This makes a significant impact, especially for the message queue, since a deferred message could be read multiple times before it’s either delivered or bounces.
• We turn on TRIM when appropriate. TRIM can eliminate most of the performance degradation that SSD drives experience over time.
• We tune a number of the Linux kernel’s parameters, like shmmax and shmall, to enable the kernel to handle more than it would out of the box.
• If a server has multiple forms of storage that run at different speeds (for example, both SSD and non-SSD hard drives), we allocate the storage intelligently. Some of GreenArrow’s components, like its PostgreSQL database and mail queue, have much higher disk IO requirements than others, like its logs.

4) Our Multithreaded Sending

When it comes to performance, multithreading can be an essential technique. Multithreading enables a single application to utilize multiple CPU cores, rather than allowing a single CPU core to become a bottleneck.

Imagine a pit crew. If your crew has 4 members, they’ll need four sets of tools to replace all of your tires at once. If they only have one set, one of them will work while the other three shoot the breeze (or heckle the unlucky one who’s actually working). And this will affect the speed at which the team performs.

That’s why we’ve programmed GreenArrow to enable multiple pit crew members (CPU cores) to split the workload amongst themselves rather than goofing off. Granted, the total CPU resources of your server can still become a bottleneck—your pit crew can only be so big! But under normal circumstances, GreenArrow won’t get bottlenecked even on the speed of individual CPU cores.

5) GreenArrow’s Direct Injection

Finally, there’s GreenArrow’s Direct Injection. In a car, you can increase the performance of the engine by pumping gas straight to where it needs to go (the combustion chamber). Our version of Direct Injection does much the same thing, just without the fire risk and greenhouse emissions.

Before Direct Injection, messages were added to GreenArrow’s RAM queue by sending them to a separate application. But now our software can write messages straight to the RAM queue without creating any new processes. As you can imagine, this makes things more efficient and further reduces the per-message CPU overhead.

Our website currently says GreenArrow can send up to eight million messages per hour, but that estimate is based on how GreenArrow performed before Direct Injection. Now we can blow past that barrier and go faster than we’ve ever dreamed before. We even have individual customers who are sending ten million messages per hour from a single GreenArrow installation! That’s right—we’ve hit Warp 10.

Since this is still a relatively new improvement, it may not be turned on by default for all customers. If you’re already sending with GreenArrow, but you’re not sure if your installation is using Direct Injection, contact our support team, and we’ll turn it on for you.

---

Stuck in a Rut? Take a Spin!

There you have it! I hope this article has helped give you a better sense of how fast our software is, and why speed can be a valuable feature for your larger email lists. Where’s your email going today? How can the right speed improve your next campaign?  If your current software has you stuck-in-a-rut, take a spin by requesting a free demo today!