hi, 2010/1/21 Peter Rundle <[email protected]>: > I said it might take a few seconds, I didn't say it was computationally > heavy.
fair enough, but still worth questioning, i think. for a typical app, i'd be concerned if a fat apache child process was spending more than a quarter to a third of a second servicing a single request. cheers justin > > > justin randell wrote: >> >> hi, >> >> 2010/1/21 Peter Rundle <[email protected]>: >>> >>> It's alleged Ken Foskey did scribe: >>> >>>> You could try closing STDOUT which will tell apache that your script has >>>> stopped output. >>> >>> This is interesting idea, I think I will give that a try if I can find >>> out >>> how to get hold of the STDOUT file pointer. >>> >>>> In perl I executed a background task with an system( "command &" ); to >>>> perform the background tasks. I then emailed a reponse to the client to >>>> tell them the job was done. >>> >>> That's the kinda thing I need to do. I was hoping to avoid doing a system >>> command because the action I need to do is easily done right away in the >>> php >>> (database connection is already open with right privileges etc). I just >>> need >>> to let the browser know that there's not gonna be any more output, it's >>> finished go and render the page and be happy. If I call a system command >>> I >>> have to pass all the info I current have in the application open a new >>> connection to the database in the other process etc. Doable but if I can >>> just close the network connection that'd be neater. >>> >>> Cron jobs aren't the go, this is an event driven task that needs to >>> happen >>> when the event occurs, not some minutes/hours later when the cron jobs >>> wakes >>> up at the specified interval. >> >> i'm interested in the requirements that led to this problem. to be >> honest, it sounds a bit fishy from a design point of view. maybe it >> just has to be that way, but requiring big chunks of computation that >> have to happen straight away, are triggered by network requests (that >> don't need to see the results of the processing in real time) is not >> something i'd allow unless absolutely necessary. at the very least, >> i'd want the resource that triggers that access controlled. >> >> sorry if this is a blind alley, but this is a problem i would be >> trying *not* to solve if possible. any architecture that requires this >> will be harder to scale and easier to DOS, which might not bite you >> straight away, but will probably bite you at some point. >> >> so, the client request that triggers the processing doesn't see the >> results. what is it about the app that requires it to happen straight >> away? is it a consistency issue - no other client should see the site >> before the processing is done? would it be enough for other clients to >> just see the site with all or none of the processing finished? >> >> cheers, >> justin > > -- > SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ > Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html > -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
