I got some errors about sending mails too quick in 15 minutes when sending mails.
It seems there is a speed limit of sending mails.
But how many mails can be sent in 15 minutes?
Is this a standard or private rule based on vendor?
It depends on both your mail service provider, and also the target system. For example gmail will let you send 500/1000 (or more) emails per day, per account depending on your agreement with them.
Related
I have an SaaS application where each paying customer may have thousands of members they may want to send emails to every now and then.
For now, simple BCC sending via AWS SES have done the trick, but now I am looking at sending personalized emails so I must be able to send the emails one by one.
SES does not have any queue system as per my knowledge, you must make an API call per email. In short, it takes forever to send a batch (my limit is 14 per second), and the user cannot close the page while it is executing (even AJAX calls stop executing if you leave the page, am I right?).
I was thinking of building a system where I store the emails in a database table and then either:
1) Use a CRON that executes every 5 seconds or so, grab a few emails and send them.
2) Execute an AJAX script each 5 seconds that grabs the emails for said logged in customer in a batch ONLY and send them out, but again, if the customer logs out while it executes chances are that specific a batch is interrupted (the remaining ones would still keep sending the next time the customer logs in).
Does any have any better ideas? Or, which of the two above would be preferred?
You should use templates and the SendBulkTemplatedEmail endpoint that AWS introduced a few months ago: https://aws.amazon.com/blogs/ses/introducing-email-templates-and-bulk-sending/.
That way you can send up to 50 personalized emails with a single SES API call. So 700 with 14 calls.
You shouldn't consider queuing them up in a user's browser and sending them by making a series of AJAX requests though. You should only send one Ajax request to start a job. In most server-side languages (any I can think of) you can respond to an HTTP request and still continue doing processing after responding. You can also implement a progress checker in a multitude of ways.
Use a cronjob that sends to the SES SMTP server. This way you can personalize the emails and also control how many emails to send. Your cronjob can sleep in between each batch of emails.
You can use celery to run background job. A user submits a request on a webpage which starts a background job through celery. The background job take care of sending emails. Once sending emails is completed, inform the user by email.
http://www.celeryproject.org/
In Exchange 2013 is there a way to restrict the amount of emails sent per day? I want to make sure nobody is sending spam mail to 1000s of recipients at the time.
Thanks in advance
I guess I have to answer my own question.
Create a throttling policy and set RecipientRateLimit or MessageRateLimit. One does per 24 hours and the other does like per minute.
We are working on a system were we will need to send push notifications to thousands of phones. We have set this up using Amazon SNS. We will be sending individual messages to each phone so we are sending direct to SNS Endpoint ARNs rather that Topic ARNs.
We are currently wondering about the performance of this system. I've not been able to find anything on the net talking about how many messages can be sent to SNS. For example, if I need to send 25,000 messages to 25,000 SNS end points, how fast can I send them? Seconds, minutes, hours?
I know there is a lot of things that can impact this, but I'm trying to find some indicative numbers so we can work out how simple or complex we might need to make the software doing the sending and hopefully avoid over-engineering our solutions.
Thanks for any info.
Okies. Don't worry. I've run a test where I wrapped a loop around the send function and sent myself 25,000 push notifications. Had to shut my phone down, but the end result was around 13 sends per second or approximately 30 minutes to send 25,000. Not bad given the variables of network latency etc and enough to indicate to use the sorts of architectures we will need to add to the software.
I'm using PHPMailer to send customized emails. The PHP script sends the email and then records the time each email is sent in a text file. On 12/18/14 the speed for sending was an average of 441 emails per minute, which is about the speed since I started using Mandrill a few days before that. But on 12/19/14 it was significantly slower at 25 emails per minute and has been that slow every day since then as well. What could be causing this?
Are you sending your emails via SMTP? I also use Mandrill with PHPMailer and saw how the sending speed using SMPT was significantly slower.
You can read all about it here Mandrill Blog: Making SMTP fast
I'm working on an application that sends and receives SMS messages to and from its users. (Don't worry - it's not spam - every user of the app expects to send and receive these messages).
One key aspect of the app... If a user sends a message to the app, the app then sends that message out to every person on that user's "team". So, the app will be sending a receiving a pretty significant number of messages (I'm hoping for a few thousand users, and 5,000-10,000 SMS messages per day).
I've been experimenting with a number of options:
SMS to email
Connecting a mobile phone to my server
Contracting an SMS gateway
Option 1 is great, since it's free, but it's unreliable (apparently mobile providers queue these messages after SMS messages they can charge for, so they're frequently received late or lost)
Option 2 is also cheap, but the mobile phone can't keep up with the number of messages I'll be sending. Also, the mobile phone provider will consider this volume of messages excessive.
Option 3 is perfect, except that SMS gateway providers charge PER MESSAGE (usually $0.02-$0.06 per), which creates an impossible scaling problem. (Reminds me of the old business adage... "Sure we're losing money on every transaction, but we'll make it up in volume...")
So, long story short - how on EARTH did Twitter pull this off? They've been doing a similar thing (allowing users to exchange SMS messages with the app) since the beginning. Even if they negotiated an INCREDIBLE discount (say, $0.001 per message), they'd be paying an ENORMOUS cost to send the hundreds of millions of messages they handle.
Does anyone have any idea how they did this?
After a bit of Googling, it looks like Twitter has simply been signing deals with cell phone companies in various countries. For example (Twitter blog post link spam incoming):
Australia: http://blog.twitter.com/2009/12/sms-tweets-for-telstra-australia.html
Indonesia: http://blog.twitter.com/2009/11/sms-for-axis-indonesia.html
New Zealand: http://blog.twitter.com/2009/05/hello-new-zealand.html
UK: http://blog.twitter.com/2009/03/full-sms-service-for-vodafone-uk.html
Some more details about SMS in general here.