Scott Raney wrote:
>
> On Thu, 16 Mar 2000, Pierre Sahores wrote:
>
> > How to improve the performances of Metacard's CGI stacks acting as
> > big txt files (and soon SQL) databases front-ends (Suse Linux 6.3 -
> > Intel) ?
> >
> > In using FastCGI ? No... In using MCHTTPD ? Perhaps...
> >
> > In using "xxx.mt" scripts to start using a main CGI stack ? It seems to
> > be the
> > simplest and, even, the best way, after adding some more lines in
> > "xxx.mt"...
> >
> > The "Too bad..." scripting way :
> >
> > #!/home/py/mc
> > on startup
> > send runsap to stack "wmc.mc"
> > end startup
>
> This would work, but it just loads stack wmc.mc each time the CGI is
> run...
>
> > and now, on stage..., the "Great Metacard" way :
> >
> > #!/home/py/mc
> > on startup
> > if "/home/py/mc" is not in the openProcesses then
> > open process "/home/py/mc" for read
> > open stack "/usr/local/httpd/cgi-bin/wmc.mc"
> > end if
> > send runsap to stack "wmc.mc"
> > end startup
> >
> > See by your own, what's a difference it does...
>
> I don't follow this: there isn't any way to send a message from one
> running version of MetaCard to another this way.
Sure, but it's not the case. It will only stay one Metacard process
running in the background after the first Apache's (or Roxen) request,
sent to the "xxx.mt" cgi script. If it works any way, after the first
instance of "xxx.mt" as gone and be killed by the system, it's because
all the next instances of both "xxx.mt" and "xxx.mc" will run in the
only one Metacard process that stay active in the background, the second
one. Linux don't open a new instance for each new request but activate
the sleeping process, not so far from what MacOS 8.xx/9.xx does in
sending an appleevent to an app waiting in the background.
Try just. You will see that the second script run too, and very fine.
Compare the performances betwin a stack that will, for each instance,
reload from disk Megs of text datas and an other that will only reread
the same datas from an active Metacard internal global variable. You
will see that the second option is up to 800% faster than the first,
just the same as it can be in using MCHTTPD but without to have a second
port open only for the Metacard application server (firewalls are not
realy friendly with non standard open ports and because many sharing
connections to the web are protected by those kind of stuff, we need to
accept this as a fact if we need to joint most of our web end users).
> At this point,
> assuming you can't or don't want to run mchttpd, proabably your best
> bet is to use something like the little client/server app posted to
> this list a little while back where the CGI program is the client and
> the server is the long-running MetaCard process that loads your large
> text files. This is basically the same architecture as mchttpd,
> except instead of the browser data going directly to the server, it
> goes through the system HTTP server as an intermediate step.
> Regards,
> Scott
>
> > Metacard ? Over all and always, the best and only the best...
> >
> > Regards, Pierre Sahores
> >
> > CRDP de l'academie de Creteil
> > ASP, VPN & BTB servers design
>
> ********************************************************
> Scott Raney [EMAIL PROTECTED] http://www.metacard.com
> MetaCard: You know, there's an easier way to do that...
Regards, Pierre
CRDP de l'academie de Creteil
ASP, VPN & BTB servers design
Archives: http://www.mail-archive.com/metacard%40lists.best.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.
