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
