perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Beamish" <tal...@gmail.com>
Subject Re: Forking to an interactive program under mod_perl
Date Wed, 13 Dec 2006 01:03:38 GMT
On 12/12/06, Jonathan Vanasco <modperl-list@2xlp.com> wrote:
>
>
> On Dec 12, 2006, at 6:13 PM, Robert Landrum wrote:
>
> > Alex Beamish wrote:
> >> What I'm trying to do is come up with scaled page images from a
> >> PDF on the fly. Thus, I want to launch Ghostscript and then ask
> >> for a couple of page images. So, launching Ghostscript and getting
> >> the first page might happen on the first request; subsequent
> >> requests would come back to the Ghostscript session left running
> >> from the first request, and thus would be able to quickly produce
> >> the required page image.
> >> Suggestions welcome.
> >
> > What you're gonna need is a daemon that lives outside of mod_perl.
> > It's job will be to answer ghost script requests made from within
> > your mod_perl handler, track open files, purge unused files, and
> > generally do all the things you want to do.  I don't really see a
> > clean way to do it otherwise.
>
> I'm going to agree with that.
>
> There's no way to make sure that you'll have the same apache instance
> handle each request.   You need to either have an external daemon
> handle sessions ( and apache + cookies will id which session a user
> has ) or you'll need to forget about open files and resuming
> sessions, and just open files on every request.
>
> I'd probably go for the latter option.  It sounds like you'll have a
> lot of overhead with  opening files on each request, but if you have
> a daemon handle it, you're going to have to write a ton of logic to
> handle
>     how many concurrent files can be open
>     what is the timeout
>     what happens on errors
>
> my  .02ยข -- keep the whole thing in MP, don't fork, write a
> wrapperclass to "save state" and resume on what you're doing with the
> ghostscript files, and serialize that data / save it  with
> Apache::Session.


Robert, Jonathon,

Interesting suggestions, thank you, and I'm coming around to the idea that a
daemon will need to be used for the heavy lifting .. and then perhaps
mod_perl can communicate with the daemon using named pipes ..

The whole point of this exercise is to keep all of the page information in
memory so that when Ghostscript gets another page request it can service it
right away, rather having to reload everything all over again. Lower
latency, at the cost of higher memory requirements. So that tells me I don't
want to load Ghostscript each time a new request comes in.

I'll deal with multiple documents with some combination of stale timers and
LRU slots, but that's not really what I see as the most complicated or
difficult part of this problem. For this particular application, my
inactivity timer will probably by 10-15 minutes, and I'll expect to have 6-8
documents open at any given time, so it shouldn't be a big drain on memory.
And I will probably be able to set something up that signals that a document
has been expired as well .. (this is just me thinking out loud) ..

Thanks for your feedback .. I think named pipes is my next focus.

Cheers,

-- 
Alex Beamish
Toronto, Ontario
aka talexb

Mime
View raw message