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
 ____________________________________________________________________
 ambassa...@fourthworld.com                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to