About MC/RR applications servers

[Pierre Sahores]

On Sat, 2003-07-12 at 23:46, revolution at knowledgeworks.plus.com wrote:
> Thanks Pierre for stepping in.  I had indeed misremembered what I had read a few months ago.
> 
> This makes very interesting reading and is a great overview of what you have done.
> 
> Let me see if I understand your process:
> 
> >>
> 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 backg
> <<
> Do I take it from this that Apache thinks it is talking to a PHP engine?  That your MC app is answering as though it is going to process .PHP files?
> 

Apache lets PHP do what he has to do and the .PHP sockets listener
script just open a tcp/ip socket on port xxx without care about the app
(MC/REV in our case) witch will respond to the socket embedded request.
The .PHP sockets listener will just block until he get a contents reply
to send back to the Apache demon.

> >>
> 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
> <<
> If I understand so far, the MC demon app then processes the request, shelling out to the OS and invoking the command-line interface to the PostgreSQL SQL interpreter.
> 

Yes

> If I have understood it, then it is quite surprising that it should be so fast.  Surely the invokation of the shell() to connect to PostgreSQL is precisely the kind of process forking that is advised against with CGI?
> 

Just do tests and you will see as me that this works perfectly, faster
for example, than in using ASP's or PHP commands, because the linux bash
optimisations, because the psql perfect design to work in command-line
pipe mode.

> >>
> About using the shell() in place of ODBC or others middleware to bind the MC/RR demon to the SQL server :
> just lots more faster, 
> <<
> This really does go against the prevailing wisdom.  
> 

Yes, probably because this way is not as expensive as it could be in
using, instead, best knowed commercial middlewares ;-)

> >>
> 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).
> <<
> You mean by this, that triggers, SPs, views, etc all work via command line interaction, but because they are slow you have replaced the functions they perform with MC processing?
> 

I just remplace all of them by metatalk/transcript calculations on very
simple SQL requests replies (all my tables have a dual column index key
- chars+unique integer - and internal sequences are controlling the
unicity of the records), available inside the MC/RR process as global
vars.

> >>
> 1000 clients peer app
> <<
> Do I take it from this, that each of your servers is running just one of the MC demons, and that this demon is expected to be able to serve 1000 client requests? 
> 
No and yes : Some servers are running up to five different MC/RR demons,
each one listening for sockets requests on a different port. Two of my
MC/RR demons are serving an ERP app to 1000 clients but those are never
connected in writing mode at the same second (in practice, non more than
50 connections peer sec, aka 1/3 of what Apache is accepting before
queuing the more requests he could receive). The others MC/RR demons are
no serving more than 250 clients. The two first apps are each hosted on
a different Suse 8 Pro x86 - Athlon 800 1 Go Ram - server. All the other
apps are hosted on 3 st box, again Suse 8 Pro x86 - Athlon 800 1 Go Ram.
I'm in discussion about the possibility to switch some apps on an
XServe, but, for yet, because Jaguar is lots slower than Linux is, i
prefer "wait and see" until having testing Panther ;-)

> What is the specification of your server in terms of RAM and CPU?  
> How large is the database that the clients query?
> What is the proportion of reads to writes?

75% of writes on databases going from some megs (events statistics) up
to 250 Megs of datas, with, as an average, no more than 10 Megs peer
table (administrative forms).
> 
> I'm sure you have only fuelled the interest in running server-side faceless Revolution apps :-)
> 
> Thanks again,
> Bernard.  
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
-- 
Bien cordialement, Pierre Sahores

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