Sending 400+ mails w/attachment before 30 sec. script time-out? 1

[dkdude]

Hi,

I need to send out some 400 newsletters - mixed content, including attachments up to 500k. Just did a test and it takes about 1 second per mail.

Making BCC list .... hmmm, I'd rather not. Some servers regards "long" BCCs as spam and put's the mail in the bulk folder. That must not happen.

PHP time-out is set to 30 seconds and my provider won't change it. And PHP runs in safe mode. That can't be changed either.

Any ideas how to accomplish it? Without having to split the recipient list and do it over multiple scripts?

Thanks a bunch

 

[jpadie]

add

set_time_limit(0);

at the start of your mail block.

 

[dkdude]

jpadie,

That's all? How simple, man

And it will work even in safemode?

 

[dkdude]

I just tried this

<?php
set_time_limit(0);
$start = time();
$elapsed = 0;
while($elapsed<60) {
  $stop = time();
  $elapsed = $stop-$start;
}
echo "60 seconds wasted ...";
?>

... and I get a "Zero sized Reply" error (from Squid). Any ideas?

Thanks again

 

[jpadie]

safemode does not affect time limits. it is possible that your host has disabled the set_time_limit() function though. that is a separate exercise to safemode.

best advice is to give it a whirl.

 

[zeland]

If I understand correctly, whether your mail has 1 recipient or 400, only 1 copy of the mail is sent to your MTA (mail server). It is then the MTAs job to crack the mail to multiple recipients.

--== Anything can go wrong. It's just a matter of how far wrong it will go till people think its right. ==--

 

[jpadie]

i've never used squid.

your code works just fine on my servers, though.

 

[dkdude]

Thank you both ;-)

Zeland -I think the problem is that calling mail() will open a SMTP connection, send the content and then close the connection again. And the way my script is set up, that would happen 400 times - hence the dalay.

Some clients will assume a mail with more than x (as little as 15-20) TOs, CCs or BCCs are somekind of spam and will reject the attachment. A friend works in the biggest bank here and their system acts like that.

Hotmail and Yahoo will assume the same thing (if the sender is not in your addressbook) and deliver the mail to the bulk folder. I use Yahoo and I never look in the bulk folder -I just purge it.

I did some Googling and I think the Zendframework is the path to solving my problem. Have a look for yourself if you like:

http://framework.zend.com/manual/en/zend.mail.multiple-emails.html

;-)

 

[jpadie]

sounds like a sledgehammer to crack a nut.

400 emails does not sound like it should take more than 30 seconds to execute. remember that time spent doing things like opening sockets and external file operations do not count towards your "time-limit".

are you actually getting a timeout response? if not then perhaps squid is cacheing more than it should.

try phpmailer from sourceforge. that may provide more feedback than just the mail() function.

 

[thedaver]

Have you considered injecting the 400 messages into your local MTA - installing a local MTA if needed - and letting it process your mail as part of its regular operation?

D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[dkdude]

You're right jpadie -and it feels like I'm slammin my fingers with it ;-)

I'm never seeing the timeout message (from inside this LAN). And yes, it takes forever. Last night I had to sent out 400 newsletters and I had to do it 12 at a time to be sure to make it within the 30 sec... what a crappy job, huh?

Installing my own MTA is not an option. It may be for my own purpose, but for my customers it won't be an option.

They must be able to create the newsletter, setup the pdf and the html messages, all online via the admin gui, and then just send it out to however many subscribers they have on their mailing list.

Please keep posting ideas - I'm in dire need of a functional solution to avoid wasting my precious time on sending newslettes ;-)

 

[thedaver]

How about building a SQL server queue of mail + attachment instructions and running a cron job for a local php binary to process each entry (or 5-10 of them) from the queue.

All your interface would need to do is to queue the work, then a local process can spew it out "offline".

BTW, Are you trying to hand-off the mail to the customer's own MTA or are you trying to directly mail to the recipient using a local SMTP engine?

I would NOT advocate the latter since you'll have timeouts there too.

Make the Customer's own MTA do all the heavy lifting, just stuff their queue with the outbound traffic and leave their admin to monitor mail delivery, timeouts, queue size, etc.

D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[zeland]

I think what thedaver means is to install a relay only MTA on your web application server. Get your web app to send that copy of the email with as many recipients as you like in 1 pass to the local MTA, then let the local MTA to crack open that single mail to all its individual recipients. If you've got a LAMP setup, installing a MTA should be a snap.

--== Anything can go wrong. It's just a matter of how far wrong it will go till people think its right. ==--

 

[dkdude]

Thanks, thedaver

Yeah, I thought about cron jobs -it the best way. But my provider won't let me do cron jobs <=> cheap b******s

The MTA will be the hosting provider's -not the customer's own (so far I only have small business customers with little or no real IT infrastructure).

Perhaps I should go look for another "proper" provider for my own site and then let that act as proxy for my customers...

Darn, man! Was hoping for an easy way out :-(

 

[jpadie]

look ... unless these are truly huge newsletters and there are no big connectivity bottlenecks, 400 mails in 30 seconds should be a walk in the park. if the provider's smtp server is fubar'd then have a look at phpmailer which implements its own smtp class. it's (very) easy to implement too.

lastly, there are some PEAR solutions to mail queuing that can handle the thing for you.

and absolutely lastly ... you don't need the provider to enable cron jobs in order for you to be able to use them. a couple of workarounds:

1. try using system() to inject a cron job even if the provider won't set oneup for you. unless the provider has locked down the system really tightly, this might well work out of the box.

2. write your cron job in two parts. one part is a server-side script that keeps a stateful track of where it has got to in the job. the other part is a cron job on a local windows or linux box that just calls the server side script (i.e. opens a web page) at regular intervals.

 

[dkdude]

Thanks jpadie - lot's of good info in your reply ;-)

I agree - It should be a walk in the park. However, the newsletters were about 350k (with pdf attachment) and I timed the script :: approx one second per mail!!

phpmailer and the PEAR thingy sounds like an option. I will try them out.

About injecting a cron job : IF I want to test it on my provider's (*nix) server -am I right assuming that I should know (and have access to) the path to the php binary in order to make this work? I don't. They won't.

Guess this means I have to set it up on my own box. I was hoping I could avoid that. But seems the the way out.

But I'll definately have a go with phpmailer and PEAR!

Thanks again for your excellent advice - have a star ;-)

 

[jpadie]

to get the path of the binary just check out phpinfo()

<?php
phpinfo();
?>