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? >> 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. 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? >> 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, << This really does go against the prevailing wisdom. >> 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? >> 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? 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? I'm sure you have only fuelled the interest in running server-side faceless Revolution apps :-) Thanks again, Bernard. _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
