Re: Using parent and child processes in perl

I believe your original problem was that you aren't writing any output when this service call is happening (and it takes quite a bit of time -- half a minute or more), which causes your web server or client to give up its wait for data.

One fix to this is to output something while processing -- small HTML comments, once per second, are a good option. How are you calling the service?

Alternatively, you could try to fix the root cause (why is the service call slow?)

Comment on Re: Using parent and child processes in perl

Replies are listed 'Best First'.
Re^2: Using parent and child processes in perl by Anonymous Monk on Jul 14, 2013 at 18:49 UTC
My service call is not slow, the time it takes to return the data is long! How do I output lines while processing? Could you elaborate on that please?	[reply]
Re^3: Using parent and child processes in perl by Anonymous Monk on Jul 15, 2013 at 09:39 UTC
My service call is not slow, the time it takes to return the data is long! Aren't those the same thing? Or does "it" refer to the processing of your CGI script? How do I output lines while processing? Could you elaborate on that please? It really depends on what this "processing" of yours means. Where does it take time? What sort of structure does it have? Do post code if possible. Anyway, you should be looking into chopping the processing into smaller pieces by e.g. converting it to an iterator, and doing the intermediate output between those stages. If all your processing time is taken inside a single subroutine call you can't modify, there isn't much you can do; some things may be possible to solve with `alarm()`, but it's usually not a good fit for this. However, since you mentioned that the request takes four or five minutes, it is a good idea to not do the processing on the web server at all, but do it in the background with a separate process: you'll just need to communicate with it (e.g. through a file or database) to queue a job with it. Needs a bit more infrastructure but is probably the easiest approach!	[reply] [d/l]