perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Perrin Harkins <per...@elem.com>
Subject Re: Forking to an interactive program under mod_perl
Date Wed, 13 Dec 2006 18:58:32 GMT
Alex Beamish wrote:
> The current solution is that we generate high resolution page images for 
> the documents in question, and then resize them on the fly using mod_perl.
> 
> This solution works well locally, but the problem is that we also have a 
> satellite office, and the VPN between the offices is not that great -- 
> we get between 50K and 100K in bandwidth. When we're dealing with tens 
> of thousands of pages, that's a fair bit of data to pass back and forth 
> and to store. I currently have a daemon process that takes care of 
> asynchronously rsyncing the page images to the satellite office.

Since it's just for small-scale use in a couple of offices, you could 
consider simpler solutions.  The daemon ideas proposed so far are one 
good to solve the problem that your users will often hit different 
apache children in the same session.  The daemon can keep the open 
ghostscript processes going and route requests from different mod_perl 
processes to the right one.

However, you could also avoid the problem by running only one apache 
process.  Then you just keep the ghostscript handles open from mod_perl, 
and you don't need to code a daemon.  If you serve a lot of other 
requests from this server that don't involve ghostscript, you might run 
this as a separate apache server and just proxy the requests for gs 
stuff to it, while handling the other stuff in a server running multiple 
processes.

I'm still troubled that you had problems with IPC::Run.  It is supposed 
to work with mod_perl, and has been used successfully by people on this 
list.  It uses IO::Pty, and should be fine.  Where did you get stuck 
with it?  You weren't getting the debug output?

Can anyone here attest that IPC::Run works with mod_perl 2?

- Perrin

Mime
View raw message