From the simplenews maintainer , a stub for a discussion occured in some email exchanges, thought I'de start a thread here...


Sending the way you suggest won't scale. For most shared hostings: If they have more than 300 recipients things will fail. There's also a PHP memory limit problem with $accounts.

Check the original background initiation process and spool table states. It will allow you to build a scheduler that supports hundred thousands of recipients.

The cron trigger uses the simplenews_send_node to send the newsletters by feeding it an array of accounts, simplenews_scheduler_get_newsletter_accounts(..) does not do a user_load and just populated an array, so that is safe, and from what I can see simplenews_send_node() just queues the newsletter into the spool.. so I *think* that is safe too..

        $tid = db_result(db_query("SELECT tid from {simplenews_newsletters} WHERE nid = %d", $node->nid));
        $accounts = simplenews_scheduler_get_newsletter_accounts($tid);
        simplenews_send_node($node, $accounts);

Can anyone else comment?

Comments

miro_dietiker’s picture

miro_dietiker
Location Switzerland
CreditAttribution: miro_dietiker commented

Note that hosting providers sometimes limit amount of outgoing mails by infrastructure to avoid SPAM abuse. You really need to check this for your provider.

Additionally you choose in the admin system, how many mails to be sent per cron cycle. This has to be approved by the corresponding php memory limit (Megabytes) and execution timeout (second).
See: memory_limit
http://www.php.net/manual/en/ini.core.php
And execution time
http://www.php.net/manual/en/info.configuration.php#ini.max-execution-time

Afterwards sending more mails means calling cron more times. ;-)

If you want to send faster, you probably need multiple machines running the cron process in parallel. Each of them will send chunks of N mails parallel.

The queue is being created in the database via SQL (INSERT .. SELECT) on sending process - it should scale pretty well.
I see no other important code part that is related to scaling.

Possibly introducing BCC might push us into a real BULK level, but note this will destroy possibility of individual tracking and personalization of mails with e.g. tokens so it's not on our priority list - possibly not even on the list of features expected.

I hope this clarified most architectural subjects.