StevenMiles
asked on
Can a perl program that takes a long time to run tie up Apache?
I think this question might be a bit naive, but that's why I come here to learn ...
I'm planning a Web site using Apache and perl on Linux, to run on a server that handles other sites as well. Most of the pages of all my sites are delivered through html constructed on the fly in perl programs. The new site will contain a perl cron job that runs with some frequency. My basic question is whether access to the sites that the server operates will be degraded if the cron job runs a perl program that takes, for example, 10 minutes to run.
I can see that if the perl cron job is computing pi to a bazillion digits, it can cause access to the server's sites to stop, but I don't think the cron job wouldn't be tying up the processor: it might be using LWP to download pages from other Web sites, or accessing a Web service to send text messages. So most of the time, the perl cron program would be waiting for responses from other servers, and would not by any means completely occupy the processor.
So, even though it might take the program 5 or 10 minutes to run, Apache will keep delivering other pages and generally doing it's job, right?
Then, what if I'm using mod_perl? Would that be a disadvantage? Maybe because other instances of perl wouldn't run?
See, there may be a fundamental piece of information I lack here, but I trust someone can set me straight. Thanks.
I'm planning a Web site using Apache and perl on Linux, to run on a server that handles other sites as well. Most of the pages of all my sites are delivered through html constructed on the fly in perl programs. The new site will contain a perl cron job that runs with some frequency. My basic question is whether access to the sites that the server operates will be degraded if the cron job runs a perl program that takes, for example, 10 minutes to run.
I can see that if the perl cron job is computing pi to a bazillion digits, it can cause access to the server's sites to stop, but I don't think the cron job wouldn't be tying up the processor: it might be using LWP to download pages from other Web sites, or accessing a Web service to send text messages. So most of the time, the perl cron program would be waiting for responses from other servers, and would not by any means completely occupy the processor.
So, even though it might take the program 5 or 10 minutes to run, Apache will keep delivering other pages and generally doing it's job, right?
Then, what if I'm using mod_perl? Would that be a disadvantage? Maybe because other instances of perl wouldn't run?
See, there may be a fundamental piece of information I lack here, but I trust someone can set me straight. Thanks.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi, Adam and Tintin,
Very helpful so far. Tintin, the html pages are indeed constructed on the fly with CGI. The cron job(s) are not run in response to requests from web browsers. Rather, they handle various housekeeping tasks on a schedule. The cron jobs don't send html anywhere. Did I explain that okay?
Very helpful so far. Tintin, the html pages are indeed constructed on the fly with CGI. The cron job(s) are not run in response to requests from web browsers. Rather, they handle various housekeeping tasks on a schedule. The cron jobs don't send html anywhere. Did I explain that okay?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
However, one thing that isn't clear is the nature of your pages. You say you have a Perl cronjob generating the pages, but you also say "constructed on the fly in perl programs", which seems to imply CGI or SSI.
Could you please expand a little more on this as mod_perl only makes sense to use if you actually use Perl/CGI scripts.