in reply to Re^3: Perl needs Zend (mod_perl vs. fastcgi)
in thread Perl needs Zend

The requests to Apache will probably end up with different processes every time.

So fastcgi should be better for keeping a very large data model in-memory for a user?

(Yes, I have such an odd case where lots of data has to be read in before doing anything. It is an editor for game data.)

  • Comment on Re^4: Perl needs Zend (mod_perl vs. fastcgi)

Replies are listed 'Best First'.
Re^5: Perl needs Zend (mod_perl vs. fastcgi)
by shmem (Chancellor) on Oct 23, 2006 at 05:32 UTC
    Oh, yes, that's one thing in that post which I didn't set right - the "primitive process management facility" is quite complete, actually.

    As you say, fastcgi can be used to run a perl program as standalone server (e.g. apache directive FastCgiServer filename options) or pretty much like mod_perl, as multiple instances controlled by the process manager (dynamic mode, new processes are spawned as necesary up to a confiurable maximum).

    --shmem 

    _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
[reply]
      As you say
      I didn't say, I was asking if my guesses were correct. :-)

      Thanks for the informative answer! If even BrowserUK didn't know, maybe the differences fastcgi/mod_perl should go into a FAQ/tutorial?

[reply]
        BerntB++ - I'll write one (but not before end of november). Well, I plan to write one... ;-) <update> no time for that now.. </update>

        --shmem 

        _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
[reply]
Re^5: Perl needs Zend (mod_perl vs. fastcgi)
by perrin (Chancellor) on Oct 23, 2006 at 14:39 UTC
    I think the answer is no. It looks like someone has requested a "sticky" load-balancing option for the FastCGI implementation in lighttpd, but it hasn't been implemented. It's a pretty dangerous route to go down, making your app depend on getting the same process every time, since it hurts your scalability. If you have few users and can't partition your data, you could consider a single-threaded server approach (like POE), but most of the time it is safer to partition the data into more manageable chunks.
[reply]
      most of the time it is safer to partition the data into more manageable chunks.
      Agreed. But there is no good way to solve my problem.

      I'd be happy to give my example; if you can point out a simple way to reorganize my 70 page of model, I'd be very happy. :-)

      (No, I'm not a complete idiot that has done something simple in a complex manner; it was a very hard problem.)

      It's a pretty dangerous route to go down, making your app depend on getting the same process every time, since it hurts your scalability.
      Very good point. If this could get heavy use, I'd write it so the different backend servers had different DNS addresses for active sessions, then it should scale. Of course, another server could take over the job (heartbeat) -- but would have to reinit the data.

      But when that design start to trash (not enough memory for all models of all users), I'd start to cry. :-)

[reply]
        If you start a new thread for it, I'd certainly read it and offer ideas. Starting it buried down here is probably not a good idea.
[reply]

In Section Meditations