Hi Kee -
Great blueprint! Thanks.
Phil Davis
kee nethery wrote:
Am trying to cut through the marketing chatter and understand the
limitations of using RunRev for CGI work. Here is what I think I know,
I'd appreciate corrections.
Andre Garzia's RevHTTP stack is a really nice way to build a web based
application in RunRev. You can use the debugger and you can store data
in stacks and you can use the various installer apps to keep the web
stack updated. It is single threaded such that when one connection comes
in, no other connections can be processed until the current connection
is done.
Stack based - yes (build and troubleshoot on your desktop and copy to
server)
Apache server "cgi" - no
Built-in web server - yes (IT folks are uncomfortable with standalone
web servers)
Debuggable - yes (you can have a connection go through the debugger on
the server)
Negligible launch and tear down overhead for each connection - yes
(launch once and it is always running)
Multiple connections - no
Multiple simultaneously processing connections - no
Global Variables that are global for all connections to the web service
- yes (one stack)
Global Variables that are specific to a single connection - yes (each
connection can get setup with the initial connection globals)
File based script version of Jacqueline Landman Gay's tutorial uses the
traditional Apache CGI structure and RunRev as the backend process and
as such, a new instance of the script gets created for each incoming
connection. This is good for simultaneous multiple connections, but the
text script version prevents using the RunRev debugger.
Stack based - no
Apache server "cgi" - yes (IT folks are comfortable managing Apache
installations, it's a known knowledge set)
Built-in web server - no
Debuggable - no
Negligible launch and tear down overhead for each connection - no (each
script instance is fast to handle but with hundreds of connections per
second, launch and tear down will become an issue)
Multiple connections - yes (each connection spawns a new instance of the
script)
Multiple simultaneously processing connections - yes (the separate
instances have no connections with each other and Apache handles the
simultaneous processing)
Global Variables that are global for all connections to the web service
- yes (when stored in a common text file read at startup)
Global Variables that are specific to a single connection - yes (the
script can have setup variables at launch)
The stack based version of Jacqueline Landman Gay's tutorial uses a
simple file based script to execute scripts in stacks. This uses the
traditional Apache CGI structure where a new incoming connection spawns
a new instance of the script and that script interacts with a stack.
This is where I am unsure. If the processing happens in stack scripts,
how is contention handled when 100 script instances want to utilize the
same stack? Do the scripts single thread one at a time to the stack? How
is data stored in the stack by one connection handled by all the other
connections?
Stack based - yes
Apache server "cgi" - yes
Built-in web server - no
Debuggable - yes
Negligible launch and tear down overhead for each connection - no
Multiple connections - yes
Multiple simultaneously processing connections - no
Global Variables that are global for all connections to the web service
- yes (stored in "the stack")
Global Variables that are specific to a single connection - yes (because
"the stack" can only be used by one connection at a time and the
connection can reset the connection variables)
What I'd like is the following. I want to build and debug using all the
stack editing tools. I'm OK with single threading while I am debugging.
But once I've debugged it, I want, for example, 100 simultaneous
connections each running their copy of "the stack", with each stack
having access to shared data (Globals), but containing it's own data
about it's connection (connection specific globals), and for these
connections to stay up and be available for the next connection without
the overhead of launching a fresh copy of the script or of the stack
(high performance), oh and while I'm at it, if a stack is 2Mb in size
and the data that I add to it is another 2Mb in size, can the memory
footprint for additional connections be just the additional RAM needed
for another set of data and not for another copy of the stack? Is there
a way to get this using RunRev?
Stack based - yes
Apache server "cgi" - yes
Built-in web server - no
Debuggable - yes
Negligible launch and tear down overhead for each connection - yes
Multiple connections - yes
Multiple simultaneously processing connections - yes
Global Variables that are global for all connections to the web service
- yes (stored in "the stack")
Global Variables that are specific to a single connection - yes
(initialized by the CGI script before being fed to "the stack")
Is anyone doing a combo of Jacqueline's file and stack methods? Using
the stack method to debug and keeping everything in the stack script and
avoiding the commands that don't work when in a text file.
Kee Nethery
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
