PHP Script as Cron Job to Send Email, Prevent Multiple Processes

I am developing a reminder application where users can send a email to themselves by selecting time and date for the reminder.

So i would be using cron job for sending the email which will run after every minute and will check if any email is pending to send.

Now, my question is, if at any given time i have 50-100 Emails to send then i think sending email can take more than 1 minute s开发者_如何学编程o another cron job will start to run the same script. So will it be any problem ? Is running cron job every minute server resource consuming ? if yes, then what are the other options to achieve same functionality.

Please suggest !!

Thanks

---

Use a lock file strategy...create a lock file when you start a new process, and each subsequent process should check for the existence of that lock file before starting. If the lock file exists, then you know an earlier process is still running.

However, you need to ensure the existing lock file is still valid. It could be that the process that created the lock file exited without removing the lock file. Write the process id (PID) of the process that creates the lock file into the lock file. A later process that finds an existing lock file should read the PID from the file, and then make sure that process is still running.

Also, it's a good idea to limit the number of messages you'll send per-process. If you keep it open-ended, you could have issues with a system administrator killing off your long-running process. :)

---

If you are on Linux you can use this to set up a regularly executing service that keeps going until it's done then waits a minute etc.

http://code.google.com/p/atomservice/

I use it for stuff like this all the time. You could even set a limit of x emails to send per execution.

---

Well, anytime I am sending email through PHP I do it through a mailQ wrapper, which doesn't send email instantly, but puts it on a queue to send (and sends through its own stand-alone script). If you took this same approach you could simply be adding the emails to a queue (SQL table with the messages, recipients, etc... and a flag that states whether it was sent).

Then you could still run the script every minute, and then have an email script (that looks for the mail table to see if there are pending messages that need to be sent) run as a stand alone cron job - thus the work load is completely separated as the jobs should run in parallel.

And I can vouch with 100% confidence that as long as your code is sound, running a job every minute should never be an issue. I have used this approach in my CMS for years to balance the load between updating stuff that isn't high priority and would only slow down the browsing experience for the client.

I have never had performance, load or lag issues ever since using such an approach and things continue to get acted on quickly.

I do agree with AJ though in that it's important to put a cap on how many messages can be sent in one batch. Using a queuing system is ideal for this since it only sends X pending at a time, and they will still be there waiting on queue.