2

I have a web application where users can create topics and also comment on other topics (similar to what we have here on stackoverflow). I want to be able to send notifications to participating users of a discussion.

I know the easiest way to go about it is to hook the notification to the script executed when a user interacts with a discussion. In as much as that seems very easy, I believe its not the most appropriate way as the user will need to wait till all the emails notifications (notification script finishes execution) are sent till he gets the status of his action.

Another alternative I know of is to schedule the execution of the notification script using cronjob. In order for the notification to be relevant, the script will be scheduled to execute every 3 to 7 minutes so as to make sure the users get notification in a reasonable time.

Now my concern is, will setting cronjob to run a script every 3 minutes consume reasonable system resource putting into consideration my application is still running on a shared hosting platform?

Also, am thinking is it possible to have a scenario where by the comment script will trigger or notify a notification script to send notifications to specified email addresses while the comment script continues it's execution without having to wait for the completion of the notification script. If this can be achievable, then I think it will be the best choice for me.

Thank you very much for your time.

hakre
  • 184,866
  • 48
  • 414
  • 792
user431949
  • 175
  • 1
  • 8

3 Answers3

0

Unless your notification script is enormously resource-intensive and sends dozens or hundreds of messages out on each run, I would not worry about scheduling it every 3-7min on a shared host. Indeed, if you scheduled it for 3 minutes and found performance sagging on your site, then increase it to 4min for a 25% reduction in resources. It's pretty unlikely to be a problem though.

As far as starting a background process, you can achieve that with a system call to exec(). I would direct you to this question for an excellent answer.

Community
  • 1
  • 1
Michael Berkowski
  • 260,803
  • 45
  • 432
  • 377
0

IMO adding a "hook" to each "discussion interaction" is by far the cleanest approach, and one trick to avoid making users wait is to send back a Content-Length header in the HTTP response. Well-behaved HTTP clients are supposed to read the specified number of octets and then close the connection, so if you send back your "status" response with the proper Content-Length HTTP header (and set ignore_user_abort) then the end user won't notice that your server-side script actually continues on its merry way, generating email notifcations (perhaps even for several minutes) before exiting.

Peter
  • 2,476
  • 1
  • 23
  • 32
0

I'm not sure I'd agree with the approach that sending the emails in the same process that serves the request is the way to go. Generally it's best to keep things simple; serve the request as quickly as possible and let background processes do all the hardwork. When traffic increases and your servers get busy, this approach will keep waiting times down and users happier. It will also help separate your concerns which will help you with bug fixing and refactoring later on.

Personally, I would create a script that runs periodically in the background and checks all threads for new activity. If a thread has new activity then the script can send notification emails to all participants. This separates your logic of sending emails fromthe logic used to serve requests and also physically separates them - for example if your SMTP server suddenly starts taking ages to respond, it will have no determental affect on your request response times. Also, if during peak times your server gets too busy, you can just stop running this script and let the server concentrate on serving requests.

In order to run this script you can of course just use CRON, and as suggested, set it running once every 4 minutes. However, what if the script takes longer than 4 minutes? You would end up with two scripts running at the same time, possible resulting in sending some users the same email twice. One solution to this would be to use The Fat Controller which is a daemon that I wrote in C which can periodically run any script (PHP, Python, anything) - it's basically a daemoniser for anything. Crucially, it can run a new instance x seconds after the previous instance ends, so you never have to worry about multiple instances.

The Fat Controller is very configurable and can run in all sorts of modes and even handle multiple parallel processes. You can read more about it and some use cases on the website:

http://www.4pmp.com/fatcontroller/

SlappyTheFish
  • 2,457
  • 3
  • 33
  • 41