Livecode <=> SQL?

[Richard Gaskin]

Robert Brenstein wrote:

 >>Still works but purely outdated. It was before
 >>LC-Server came out and i warmly recommend to use
 >>it instead of my old fashion « PHP listener +
 >>Metacard/Rev stacks » way to go.
 >
 > I haven't got into the LC-Server game yet, but it
 > seems to be that the server stacks are not
 > staying resident. My application will require lot
 > of pre-loading of various stuff (from a db as
 > well as disk files) that stays the same for all
 > user calls. Are you saying that this is of no
 > concern anymore?

With any CGI nothing stays resident, whether Perl, PHP, Python, or 
LiveCode.  CGIs are command-line apps called by Apache to handle certain 
requests, and they're born, live, and die in the time it takes to return 
data to stdout so Apache can return it to the client.

One way to have resident resources would be FastCGI, in which the 
process is loaded once and forks child processes for incoming requests 
in a way that passes off the connection to each child.  PHP offers a 
forking compile, but at this time the LiveCode engine doesn't fork 
(though there's some interest in the community to make a version that 
does down the road).

In most cases straight CGI is sufficient for reasonable traffic, 
depending of course on the complexity of the CGI app itself.  For many 
years until just this last summer the default configuration for PHP on 
Dreamhost was simple CGI.

For higher traffic loads a forkable engine like PHP can be used under 
FastCGI, or if you need to use LiveCode with high-traffic requirements 
and are using a dedicated server or VPS you can write your own daemon to 
handle requests for specific application needs, feeding a pool of child 
workers for surprisingly good throughput using what we have today.

If writing a custom application server from scratch seems a bit more 
than you'd care to take on for your project, you may be pleasantly 
surprised by how well LiveCode performs under CGI for most reasonable 
traffic loads.

Comparing a custom search engine I wrote for a project in LC to a Drupal 
install on the same server running under PHP, our search engine was able 
to parse the incoming expression, dive into several index files, obtain 
the results, rank them, wrap them in HTML, and hand them back to Apache 
in 1/5th the amount of CPU time Drupal required to just load a page, and 
1/3 the memory.

Performance can be improved even further by being mindful of what a 
friend calls "going to TOWN" - Touch Only What's Needed.   In the short 
lifecycle of a CGI app time is precious, so it helps to make sure you're 
only obtaining the data you'll actually use, and in a form well 
optimized for accessing.  For example, in some cases the time it takes 
to run a stored array file through arrayDecode can be much longer than 
just using a delimited file with lineoffset (lots of specifics at play 
there, so benchmark your specific algos first).

RevIgniter is a very good example of LiveCode Server used well.  It 
performs admirably, while making extensive use of many files and even 
database connections, all withing the CGI lifecycle.

Besides, with the efficiency of Linux RAM caching you're rarely actually 
reading files from disk.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com