About MC/RR applications servers

bernard.devlin at knowledgeworks.plus.com bernard.devlin at knowledgeworks.plus.com
Mon Jul 21 13:10:03 EDT 2003


Hi Pierre,

Thanks for answering my other questions.  Just one more question, based on 
your answer to Alex.

I had a quick look in the Metcard archives and found this snippet:
>>
put "" into DbAuteurs
get shell("echo" && quote & "select distinct auteur__ from citations order 
by
auteur__" && quote && "| psql -h localhost citalis")
repeat for each line l in line 3 to -3 of it
    put word 1 to -1 of l & return after DbAuteurs
end repeat
<<
This is more or less how I imagined you were shelling out to the psql 
interpreter. Am I correct in thinking this is how you are invoking 
postgresql?

I can understand Alex's disbelief in this regard.  I share his 
understanding of how things are supposed to work using the combination the 
PHP Apache module, and persistent connections.

One of my apps is running on Linux and querying Firebird via ODBC.  All 
the queries have configurable debug parameters, so I can actually change 
the parameter to time each step of the process.  So I can isolate how long 
that app takes to connect and return a result set.

I will see if I can find some details on running Rev 2.01 as a command 
line application, and I will try to find some time next week to compare 
the speed of the two methods.
 

Bernard 






Pierre Sahores <psahores at easynet.fr>
Sent by: use-revolution-admin at lists.runrev.com
13/07/2003 01:40
Please respond to use-revolution

 
        To:     "use-revolution at lists.runrev.com" <use-revolution at lists.runrev.com>
        cc: 
        Subject:        Re: About MC/RR applications servers


On Sun, 2003-07-13 at 01:19, Alex Rice wrote:
> On Saturday, July 12, 2003, at 04:56  PM, Pierre Sahores wrote:
> >
> > 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
> 
> This doesn't make any sense to me. I would like to see the shell 
> command you are using.

Hum... It's, even for you, freely, available on the Metacard archive
list.
> 
> You're saying what you are doing is faster than PHP direct to 
> PostgreSQL? PHP direct to PosgreSQL can have a persistent connection 
> already open, and PHP (as apache module) is running already in memory?!
> 
> Your way: have to open a socket from PHP, launch the shell, then launch 
> the psql command line program, which THEN finally connects to the 
> database.

Did you learn a little (aka lots) about WebSphere Weblogic or WebObjects
before. Have you any idea about how applications servers works...
> 
> It absolutely impossible that your way could be faster.

Perhaps are you too sure of you about how unixes are handeling multiples
processes tasks. Did you ever watch at the processor idle average time
of a linux box ? To the end, you are not alone to think so... even if 
my clients are, probably, not only too rich and stupid persons...
> 
> Again, why are you even using Revolution instead of just going from PHP 
> to PostgreSQL? Call me confused,

Did you ever ask you about the difference it makes to use real
application server instead of just including sql replies in web forms ?
> 
> Alex Rice, Software Developer
> Architectural Research Consultants, Inc.
> http://ARCplanning.com
> 
> _______________________________________________
> 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

_______________________________________________
use-revolution mailing list
use-revolution at lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.runrev.com/pipermail/use-livecode/attachments/20030721/69a0582b/attachment.html>


More information about the use-livecode mailing list