Re: Concept for an Apache/mod_perl Perl Application Server

[Bas A . Schulte]

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.