Re: Concept for an Apache/mod_perl Perl Application Server

Hi Stephen,

On Tuesday, November 26, 2002, at 05:45 PM, Stephen Adkins wrote:

> This last thread has been very interesting.

My thoughts exactly.


>  To build a Perl Application Server, use Apache+mod_perl for
>    processing of backend functions *as well as* interacting with
>    the users.
>
>    Although the Apache server only listens for HTTP requests,
>    other timed and system events can be "injected" into the app
>    server using an HTTP request (using LWP perhaps) from small
>    programs waiting on those events (time elapsed/cron/at,
>    resource becomes available, IO unblocks, etc.).

What I initially wanted was something RMI-ish: within an app server live 
objects whose methods (some of them) can be called from elsewhere (e.g. 
other processes on the same machine but most likely other processes on 
other machines). In top of that, I needed the ability to have 
simultaneous methods calls (each handled by an instance of one of these 
objects).

So I wanted some server framework that would allow concurrent requests 
and a way to call methods in that server. The other options I looked at 
(Net::Server::*/sample code from the perl network programming 
book/home-grown stuff) but there were problems with those (stability 
being an important one; I used 'ab' to hit on them and they would just 
crash sometimes for no apparent reason).

I did take a look at POE, and still do now and then, but I just don't 
seem to get it's concepts to actually get something done on top of it. 
Recently I tried one of the examples on poe.perl.org 
(http://poe.perl.org/?Poe_cookbook/Web_Server_With_Forking) briefly but 
it wasn't very fast, even for NOOP requests.

In the end, I picked Apache/mod_perl and I'm reasonably satisfied with 
it but there are things missing like an easy way to share stuff or 
synchronize activities between children. I can build something to handle 
that but I haven't gotten around to it.


>    (Presumably it is not outside this central vision too much
>    to have separate Apache/mod_perl server sets serving the
>    "user requests" and the "system requests" if it is desired.)

I have a bunch (5 now) of these "Apache/mod_perl" app servers running, 
works fine for me. They tend to run on different machines and handle 
different components of the system.


> P.S. Besides my interactive processes (interacting with the users)
> and my queue worker (data collection) processes, I also have a
> nightly batch which loads data files which have been FTP'ed to
> the server from another Reservations System vendor.
>
> Do Rob/Perrin/others recommend that this also be done by Apache
> children? If I understand the proposal correctly, the answer would
> be yes.

I think it depends. The reason I used an external timer daemon that 
calls my app server using HTTP is this: I usually design my systems with 
an object model running above an SQL database and I already had this 
running inside the mod_perl server (with nice stuff like dynamically 
precompiling modules on startup, share information about the configured 
objects within the app server etc.). It didn't make sense to duplicate 
all this code in another daemon so I decided to call methods on objects 
in the app server (again, using HTTP requests which in turn result in a 
method call).

In other words: if there is a lot of code sharing between what you have 
in your mod_perl server and the batch proces, do it within the mod_perl 
server. If not, don't. There's also a performance issue here: batch 
loading into a database will be faster if you do it directly instead of 
translating all data into transactions that can be fed to your mod_perl 
server (i.e. one HTTP call into mod_perl per row in your datafile).

Regards,

Bas.