[REBOL] Re: About FastCGI
From: petr:krenzelok:trz:cz at: 3-Jul-2001 20:36
----- Original Message -----
From: "Holger Kruse" <[holger--rebol--com]>
Sent: Tuesday, July 03, 2001 7:25 PM
Subject: [REBOL] Re: About FastCGI
> On Fri, Jun 29, 2001 at 12:07:45AM -0300, Rondon Andrade wrote:
> > Hi Rebolers!!
> > I've installed Rebol Command implementing the FastCGI in CGI
> > Mode. Is this the best way to get high performance, or I must implement
> > FastCGI Stand-Alone Mode? What mode are you using? Do I have to install
> > Session Afinity also to get more performance ?
> It depends. Usually CGI compatibility mode is fine. The only drawback is
> requests are serialized within each instance of REBOL. For most scripts
> is actually faster than multiplexing over ports (FastCGI native mode),
uhm, now I am confused - FastCGI native mode (described as "dynamic" mode in
fastcgi dos) uses multiplexed connection? The docs distinguish three
- static mode - only when FastCGIServer directive is used - you can specify
amount of instances Apache will preload once it starts ...
- dynamic mode - you don't need to specify anything - it's default mode
(probably CGI compatible too) - Apache loads/kills instances of fastcgi
servers (rebols) according to FastCgiConfig directive
- external mode - FastCgiExternal mode - Apache doesn't care of your
servers, it assumes they are running ...
Am I correct or wrong? In what way does Apache (fastcgi process manager)
communicate with Rebol, once in default mode? I saw some strange code in my
error log - I posted it here few days ago and it seemed to me Rebol is
listening even in default mode? "open fastcgi://" was part of error
message, - but no listen port specified ... it would result in error, once I
would try to use such piece of code in console :-)
->> ble: open fastcgi://
** Access Error: Invalid port spec: none
** Near: ble: open fastcgi://
Could you explain a little bit of Rebol internals here, please :-)
> particular if your script never waits (e.g. does not access databases via
> ODBC etc.)
Why isn't it possible to have non-blocking 'insert with ODBC?
> and the amount of data it processes is rather small. If each
> request takes considerable time to process (either because of backend
> database accesses or because of large amounts of data being sent/received)
> then consider using FastCGI native mode instead.
Hmm, as for scenario you described, it is imo:
1) not too good to access live system anyway :-) We will have some 1600 SAP
R3 users, and noone can tell us, if hw IBM specified for us, will be fast
2) better to spool rebol requests and let some app server to handle db
requests natively, using stored procedures e.g.
3) we are still investigating some kind of aggregate databases, being
on-line updated from XY transactions of our huge IS, just to keep our e-biz
system from possible ERP slow responses, shutdowns etc ...
Well, just theoretising :-)