How to judge if a per-minute cron wont overload our web (Apache) server

Just curious how I can judge performance on this one. We're running Apache with a PHP/Postgresql based products/shopping website.

We have 2 servers - one for the website (PHP scripts, all static content) and one for the database.

Our orders run with a remote payment gateway as follows: 1. Customer completes checkout on the web server 2. Customer then is redire开发者_如何学JAVActed to the payment gateway for payment. 3. A notification is then sent to our web server script (from the payment gateway) to inform us of the status of the order. At this point, we check if the payment was successful and then place the order to the client's stock system accordingly.

Now, on step 3, we have a situation where we need to do some tasks, pause for 60 seconds (this is a custom workaround for the client's stock reservation system until it is upgraded later in the future), and then continue with the remainder tasks. The "pause for 60 seconds" is the part I'm not sure about. The script needs to literally wait for a while (one minute) and then we do the other tasks (transfer the order to our client).

I can think of doing this in two ways:

a) We set a timeout/interval on the PHP script for 60 seconds, and then finish the job. This is probably not workable since we are dealing with a payment gateway and we do not know if they will timeout or if any issues can happen here.

OR

b) We do the first round of tasks, and then, a cron runs every 60 seconds to check for incomplete order transfers, and then does the balance work for us. The cron needs to run every 60 seconds to catch those orders that are to be sent to the client.

The web server has a number of crons running, mostly at off peak times. Can anyone advise:

• If you can see a different solution to the above

• If you agree with solution b), could this be somewhat of an overload to our web server? What is the best way for me to judge this? The task itself it not demanding (checks database, transfers a file from one place to another on our web server), but I'm wondering if a cron should execute every minute like that.

Thanks, Rishi

Given your constraints, and timing, why not write a system daemon that does the work? It can run "all the time", going to sleep when there is no work, and awakening as often as needed. It also avoids the "there are 5 of me running" problems. You can build up a queue, as John stated, and keep up with it. I've done this a few times with success.

The answer is B. If you're worried about your server's performance at minute-level intervals, then you really just need a bigger machine/richer architecture. Most performance issues on a Web server come down to usage spikes at more granular levels.

If you are worried, the solution is pretty simple. Instead of dumbly firing off a bunch of processes every minute, build in a queue and some state management. Mark the machine as 'processing' when you start your queue. If the cron fires again and the machine is still 'processing', then just dump out and wait for the next tick. When you're done with the queue, unmark the machine.

If you go 3-4 ticks without breaking out of 'processing', then you can call somebody's pager.