On Mon, April 30, 2007 9:55 am, Brad Fuller wrote: > I am developing a program that does some intensive data processing, > and is > triggered from a page hit and/or a SOAP request. > > The processing takes on average 30 seconds to 1 minute, which is OK > for a > web page (I can use set_time_limit(0) and just display a > pseudo-progress bar > animated gif and a "Please wait..." message) but I can't leave the > SOAP > request hanging for that long. I need to send a response immediately.
Waiting for 1 minute for a web page is probably not acceptable. Users won't take it. Browsers will "give up" and tell them your page is dead. And it's just all around a Bad Idea for a web-based application to tie up HTTP resources that long a time. And if the SOAP client won't take it anyway, you might as well have both SOAP and normal users have a cron job list API anyway, since it's a lot easier to have ONE way to do things instead of two, usually. > What I really need to do is acknowledge the client that their request > has > been received and will be processed, and terminate that request... and > THEN > begin the processing. > > One way I thought of doing it would be to put the requests into the > database > and run a cron job every X minutes, but I would like to avoid this if > at all > possible. Since that's probably the best way to handle this, why do you want to avoid it?... > Someone had suggested pcntl_fork() but I'm not sure if that will > accomplish > what I need it to... if I fork(), then send a response, kill the > parent and > let the child run the process, will the HTTP request wait for the > child or > will it die with the parent (like I want it to) ? pcntl_fork() in a web environment is a Bad Idea [probably]. [probably explained] If you have a very heavily tested and controlled web environment, wherein you have severely pounded on it, with a stable body of code, and you are 100% sure there are no thread-safety issues, then pcntl_fork() in a web environment is okay... The preceding sentence only applies to about 0.0001% of all web-servers on the planet, at best. :-v [/probably] If you throw pcntl_fork into your average web environment, expect random crashes, with increasing frequency as load increases. Sort of like running Windows, only not. :-) So pcntl_fork is probably the WORST suggestion, and the MOST resource-intensive in terms of testing and development, which is probably your most limited resource, actually. Doing a fork in the CLI to process the cron jobs in parallel *might* be a Good Idea if you have a farm of servers or multiple CPUs... Or it might just create more overhead with no gain at all, if the bottleneck is the actual processing and it's not CPU bound to start with... You're going to need callgrind to do the job right in the end, probably... :-) -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
