on 28/08/02 9:17 AM, Pupeno ([EMAIL PROTECTED]) wrote:
> I know a lot has been discussed in this topic, but I still don't find any > solution. > What I want to do is send a lot of mails triggered from a web page using > php. > I've found diferent solutions but all of them has some problem: > 1) using set_time_limit() to allow the script to run longer while sending > e-mails, my prefered solution but I won't let someone waiting a lot of time > with a loading browser because they'll stop, reload, and at best, just not > like it. So, I would like to launch a background process changing the > set_time_limit() in that process (if needed), the problem is that I wasn't > able to run a background process in PHP, were you ? I know I could use at > (atd) to run a background process but in my shared server, there's no at > available. If you trigger it from a web page, eventually, no matter what you do, you will hit the wall, because browsers may time out -- not just the PHP script. The ONLY option is to Bcc: everyone in your email, rather than send personalise emails. This way you only send ONE email, not 1000's. I've spent AGES researching this, and am convinced that Bcc is the only way to get the performance you want. There are many hacks work-arounds like: - have the webpage only do batches of 50 emails, and refresh with META refresh every 1 minute... come back in a few hours, and they'll all be sent. The other option to consider is to write a PHP script which runs FROM the command line. Then possibly your webpage can trigger the command line script, AND refresh to a "thanks" page, leaving the other command line script still running. Of course you need PHP as a command line executable for this. I really suggest speaking to your host. It's quite possible THEY have the solution you want. It's also quite possible that they HATE bulk mailing via their web page servers, and will actually impose restrictions. They may also have a dedicated mailing server (as my ISP does) which can handle this sorta stuff. > 2) Queuing instead of sending. I've seen that some people improved the > 'sending' (well, it's not sending anymore) by queuin only. Then some people > tell me that sendmails always queue and I'm a bit confused. Does sendmail > queue or sends mails ? if it queue, why is it send imediatly if the queue > is procesed once an hour or so ? I don't care if my mails are procesed once > an hour for this mails, I don't need them to be sent imediatly. I can't > change sendmail configuration (since it's a shared server) and I wouldn't > want to because I have other 'mail cases' when I want to send the mails > imediatly. I can't change the way PHP calls sendmail (again, it's a shared > server) but I'm using PHPMailer and I can change the way PHPMailer uses > sendmail, will `/usr/sbin/sendmail -O DeliveryMode=q` queue the mails I'm > sending ? The issue of queing is only there IF you wish to send personalised emails. Queing is NOT an issue for sending an email with a Bcc of 50,000 people. > 3) Someone told me to do it using cron, do you have any idea of how to do it > with cron ? Cron is a way of executing a process at a certain time (eg 3am daily). If you were able to write a command-line PHP script to send you email (queries a DB or text file to get the message body, then grabs the address', then send the email(s)), you could set it to run at a time which the server is less busy (eg 4am). You could also use it to partially-send to the list in batches of 100 people, at 5 minute intervals or something. The real answer to your question is: If you are doing this on a shared host, use Bcc and keep it simple... your host will probably see the huge system burden you are placing, and impose restrictions on you. If you want a dedicated mailing list with personalised emails, you should look at a dedicated mailing list system on your host, or another host, which tackles the issue properly. There's sparklist.com, ezmlm, etc etc. Your host may be interesting in setting up a program to do this... Justin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
