About MC/RR applications servers

[Pierre Sahores]

On Sat, 2003-07-12 at 14:13, revolution at knowledgeworks.plus.com wrote:

-- snip --

> If I remember rightly, it was this kind of reliance on speed (and
forking of processors) that Pierre was using to have Rev acting as the
CGI engine to a PostgreSQL db. Normally people recommend against CGI
becuase of the overhead of forking, but his scenario seems to run
against this wisdom and yet be successful.

-- snip --

Hi Folks, 
I'm new to the rev list but it seems it could be an idea to share a little about the way i 
use MC/RR to build deamon apps (not cgi - too slow and unsecure) to drive web's and erp's apps.

I.- About the working stuff and platforms :

1.- The client-side app :

a.- Web browsers (Netscape 4.7/4.8), Mozilla 1.x, Opera, for a good javascript support)
b.- MC/RR front-ends (sending POST requests over the web - LibURL requiered with MC 2.4+ and
Revolution)

2.- The server-side suit of stuff :

a.- Apache 1.3.x or 2.0.x
b.- PHP 3.x or PHP 4.0.x or PHP 4.1 or above
c.- Metacard 2.32 or above or Revolution 1.1.1 or above
d.- PostgreSQL 7.xx
e.- HTMLDOC 1.8 or above (dynamic PDF pages on-the-fly edition)

3.- The server platform :

a.- Linux 2.0 or above (2.4.21), natively able to start MC/RR deamon apps in console mode, 
from a startup script dropped in the "../rc3.d/.." directory.
b.- Jaguar, even if i had no time to build a production-grade issue of my apps on OSX, for yet.
c.- BSDs, Win32 and Solaris platforms must be ok too but, not tested for yet.

4.- The client-side platform :

a.- Web browsers : any that supports the needed browser (with or without the javascript support
option)
b.- MC/RR front-ends : any that supports the MC engine, even if, because some platform specific 
debbugging work is always needed, the best is to support the most used one only (aka Win32 and OSX).

II.- About the processes design (can send a pict schema, on demand) :

1.- The client-side app (Web browser or MC/RR front-end) sends a POST request to the Apache demon 
(on the standard 80 port), over the Web.

2.- The Apache demon (configured to accept up to 150 requests peer second) send the request to a 
.php sockets listener, witch open a socket on a root protected port to the MC/RR demon app running
in the background.

3.- The MC/RR read/split the POST request and, if the request is corresponding to a closed list of task
the demon is able to do, the job (AI calculations, flat files databases access, SQL requests), he does the
job, else nothing to prevent any attack or security lacking.

If the demand is not containing any SQL request, the MC/RR demon builds his answer and send it back to
the opened .PHP socket, close the socket and wait for the next request.

If the demand contains an SQL request, the MC/RR demon open a connection to the psql command-line client of 
the Postmaster demon of PostgreSQL trough a metatalk/transcript shell() request, waits for the response,
makes if needed calculations on the SQL datas reply and, send it back to the opened .PHP socket, close 
the socket and wait for the next request.

Comment : As anyone can see, the MC/RR app always runs as a slave server (of the .PHP sockets listener, on
the first side ; of the PostgreSQL Postmaster demon, on the second side. It was the best way to solve the
concurrency problems management : Apache+PHP are maintaining perfectly the client-side part of the problem.
The PostgreSQL Postmaster do the same about the muti-concurrents access to the databases, in an ACID SQL
level of quality only available in using first-class db servers (aka. 0racle 7/8/9, Firebird, SAPDB and
PostgreSQL.

About using the shell() in place of ODBC or others middleware to bind the MC/RR demon to the SQL server :
just lost more faster, best protection in the fact that only one user:password key is opened on the
PostMaster side (the MC/RR one, in localhost mode only), all the end-users clients authentifications and
sessions persistence are build on encrypted keys included in the "POST" datas.

Because the MC/RR demon has nothing to handle, by it-self, about the concurrent accesses and sessions,
because it's always able to respond very fast, there is no possibles lacks in the complete processes and,
because that, it ways to add to the MC/RR demon many special procedure to replace the ones that don't
work as easy and fast in the other parts of the server (aka. build-in replacements of the SQL triggers,
stoked procedure and vues).

This kind of apps is using, in production mode, 7/7 days and 24/24 hours, to serve Extranet web's and erp's
apps, with up to 1000 clients peer app. The clients are french administrations, in the education and towns
management sphere. I never add a server down since i use those kind of apps, else the time my provider add
all this servers down because no more electricity at all.

About PostgreSQL : It's, for me, the best and fastest ACID SQL server available today. Backups and databases 
restaurations are done in seconds and, in writing mode, it supports more concurrent accesses on the same record
(over 350 peer sec) than any other db server, Oracle included.

About MySQL : Its 3.23 issue dont support more than 10/15 writing-mode concurrent accesses. The 4.0.12-Max
issue is more sure (aka the same level of db like Sybase ASE 12.5 or MS SQL Server) but why use it when it's
no more harder to install and run PostgreSQL.

About Oracle 8/9i : i ran both issues of this server in binding them to one of my tests MC application server.
What i found was not so far from comic : the java-installer needs on-line corrections, from within the shell
to run up to the end of the installation. The footprint of the Oracle server is in 100's of Megs where the
PostgreSQL one is in Megs. The only good news is probably that, by default, the Oracle SQL*Plus demon seems
always able to handle the requests very fast (cache).

III.- About a more detailled presentation :

a.- Read, beside my post on the Metacard archive list, what many of us wrote on the subject
(Sadhu, Andu, and many others of us..).

b.- Ask again fore more specifics responses when needed.

Hope this can help,
-- 
Bien cordialement, Pierre Sahores

Serveurs d'applications & bases ACID SQL
Penser et produire l'avantage compétitif