<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 2, 2015 at 10:10 AM, Andrew <span dir="ltr"><<a href="mailto:catalystgroup@unitedgames.co.uk" target="_blank">catalystgroup@unitedgames.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Len and Darren,<br>
Atm I'm using Email::Stuffer to send email from within a perl script, in the<br>
Controller folder of my Catalyst app.<br>
I'm assuming this results in it being queued to be sent by the local SMTP<br>
server.<br>
My VPS server has Cpanel, and uses Exim, which I'm guessing is what the<br>
scripts are using to send the email.<br></blockquote><div><br></div><div>According to the docs <a href="http://search.cpan.org/~rjbs/Email-Stuffer-0.012/lib/Email/Stuffer.pm">http://search.cpan.org/~rjbs/Email-Stuffer-0.012/lib/Email/Stuffer.pm</a></div><div>unless you explicitly set the transport, Email::Stuffer defers to Email::Sender for the default transport, </div><div>which appears to be sendmail, which means you'll be handing it off locally for delivery. </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
As noted, it all works until about 1020 emails in, at which point the<br>
Catalyst app crashes (although this has only happened once - I do not wish<br>
to try again and risk another crash). I am using Email::Stuffer in a for<br>
loop, iterating over an array of 3000 email addresses. For my next step I<br>
will alter my code to only attempt to send to 500 email addresses at any one<br>
time, since below 1000 everything seems to work fine.<br></blockquote><div><br></div><div>If you can consistently to 500, but 1000 consistently crashes you, and you don't want to </div><div>spend the time on forensics, then just go with 500. But be aware that if you're not freeing </div><div>memory, then it's possible to hit the resource usage limits if e.g. you start sending a bigger message.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
You seem to be mentioning using a background process, Darren. Is Exim<br>
already the background process that sends email?<br></blockquote><div><br></div><div>It is a web service trope now that one does not send any email directly as the result of a browser interaction, </div><div>but rather one notes that an email needs to be sent (queues a job request), and a demon or cron job (a queue </div><div>processor) creates ans sends the mail. Thus the web infrastructure can finish serving the web request sooner, </div><div>which is the greatest good at web scale.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If the long term solution is to use mailgun or sendgrid - before I delve<br>
into all their documentation - do you lot have any tips I should consider,<br>
on how to integrate them with a Catalyst app, or is it all pretty straight<br>
forward once I read the documentation?</blockquote><div>I would not explore them unless:</div><div>1) you start sending a lot more mail.</div><div>2) you start ending up in spam control black lists. </div><div><br></div><div>As for tips, my usage of sendmail involves having my local sendmail (I use postfix) hand off to </div><div>sendgrid for delivery. I'd like to make use of their thousand-addresses-at-a-time capabilities, but </div><div>my client doesn't feel the need to optimize their delivery processes yet.</div><div><br></div><div><br></div><div><br></div><div>Len.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="im">
<br>
----- Original Message -----<br>
From: "Darren Duncan" <<a href="mailto:darren@darrenduncan.net">darren@darrenduncan.net</a>><br>
To: "The elegant MVC web framework" <<a href="mailto:catalyst@lists.scsys.co.uk">catalyst@lists.scsys.co.uk</a>><br>
Sent: Monday, November 30, 2015 11:41 PM<br>
Subject: Re: [Catalyst] Sending 3000 emails.<br>
<br>
<br>
</span><div class=""><div class="h5">On 2015-11-30 9:29 AM, Andrew wrote:<br>
> ...given that my attempt to send 3000 emails with nothing but my own VPS<br>
server,<br>
> and Cpan's Email::Stuffer, only sent around 1000, before the<br>
> plack/fastcgi/catalyst app crashed.... could I have been running into a<br>
similar<br>
> limitation? I'm now thinking of altering my code to split the attempts to<br>
send<br>
> email into six batches of 500 emails, as a short term fix, until I've had<br>
time<br>
> to research which transactional email partner to use, and how their APIs<br>
work,<br>
> or integrate with Catalyst apps.<br>
<br>
If you are trying to send the emails directly from the process serving your<br>
web<br>
API, then this is absolutely the wrong approach, and you should give up<br>
immediately on trying to do that. Your API process should just queue the<br>
messages to be sent by a separate background process, and then return<br>
immediately such as with a message "3000 messages queued to be sent soon,<br>
click<br>
here to check queue progress" or such. Sending in-process may be reasonable<br>
for<br>
a single email, eg email a copy of the form the user just submitted, but<br>
that's<br>
it. -- Darren Duncan<br>
<br>
<br>
_______________________________________________<br>
List: <a href="mailto:Catalyst@lists.scsys.co.uk">Catalyst@lists.scsys.co.uk</a><br>
Listinfo: <a href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst" rel="noreferrer" target="_blank">http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst</a><br>
Searchable archive: <a href="http://www.mail-archive.com/catalyst@lists.scsys.co.uk/" rel="noreferrer" target="_blank">http://www.mail-archive.com/catalyst@lists.scsys.co.uk/</a><br>
Dev site: <a href="http://dev.catalyst.perl.org/" rel="noreferrer" target="_blank">http://dev.catalyst.perl.org/</a><br>
<br>
<br>
_______________________________________________<br>
List: <a href="mailto:Catalyst@lists.scsys.co.uk">Catalyst@lists.scsys.co.uk</a><br>
Listinfo: <a href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst" rel="noreferrer" target="_blank">http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst</a><br>
Searchable archive: <a href="http://www.mail-archive.com/catalyst@lists.scsys.co.uk/" rel="noreferrer" target="_blank">http://www.mail-archive.com/catalyst@lists.scsys.co.uk/</a><br>
Dev site: <a href="http://dev.catalyst.perl.org/" rel="noreferrer" target="_blank">http://dev.catalyst.perl.org/</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Len Jaffe - Information Technology Smoke Jumper - <a href="mailto:lenjaffe@jaffesystems.com" target="_blank">lenjaffe@jaffesystems.com</a> </div><div>614-404-4214 <a href="https://www.twitter.com/lenJaffe" target="_blank">@LenJaffe</a> <a href="http://www.lenjaffe.com/" target="_blank">www.lenjaffe.com</a><br></div><div>Host of <a href="http://www.meetup.com/techlifecolumbus/" target="_blank">Code Jam Columbus</a> - <a href="https://www.twitter.com/CodeJamCMH" target="_blank">@CodeJamCMH</a></div><div><div>Curator of <a href="http://www.lenjaffe.com/AdventPlanet/" target="_blank">Advent Planet</a> - An Aggregation of Online Advent Calendars.<div><br></div></div></div></div></div></div></div></div></div>
</div></div>