Virtual Server Install

[Richard Gaskin]

Mark Rauterkus wrote:

 > http://livecode.com/how-it-works/platforms-and-devices/server/
 >
 > That info above is exciting, but there has to be more depth somewhere.
 > Where?

The docs included in the package often describe all that one needs to 
know.  There are a few errors and omissions, but overall they're not a 
bad starting point.

Once we get further along with community involvement we can of course 
coordinate with the mother ship to enhance those docs - what would you 
like to see done first?


stephen barncard wrote:

 > I've been planning to send an email the CEO of Dreamhost and suggest
 > they offer Livecode with their one click installs after the community
 > edition is released. They are a pretty hip company and may already be
 > planning this.

If they'd be receptive to a petition, I'd sign it.

It may be best to do that after the next version of LiveCode Server is 
released.

The current version will fail with certain I/O routines on Dreamhost's 
current system setup, for the reasons I described here earlier with 
64-bit inodes.

But thankfully Mark Waddingham was able to find a way to reproduce the 
issue on a test machine in their office, and the fix is now evident in 
the v6.0.1 engine, confirmed by Mark and verified in my testing with a 
standalone on Dreamhost.

So once the new LiveCode Server engine is released, we'll finally be 
able to run in confidently on all Dreamhost servers (and a growing 
number of others that are migrating to the XFS file system).


One good selling point speaks to the same reason they're migrating to 
XFS: efficiency with regard to system load.  With XFS they can save 
enough energy to pay for an admin's salary.  Similarly, LiveCode is an 
unusually lean system for what it provides.

For example, I have a custom search engine written in LiveCode that is 
able to do everything it needs to do in just 30% as much memory and 10% 
as many CPU cycles as it takes Drupal just to open a page.

Even with the presumed inefficiencies of a non-threaded system, LiveCode 
loads so fast* and is done in just milliseconds that overall use of 
system resources is often lower than alternatives for equivalent tasks.

Of course one would want to frame that carefully in discussion with 
them.  For example, in all fairness to Drupal the reason it uses so much 
RAM is that it's a really complex, flexible system.  No doubt if one 
wrote something that complex in LiveCode rather than PHP it would also 
require a lot of RAM, possibly more because it can't take advantage of 
any stay-resident options like mod_php offers.

That said, I'm not even sure DH uses mod_php; it may be that they're 
running PHP in CGI mode (I'd have to check their wiki to make sure).

But either way, it's so easy to write custom stuff in LC that we don't 
need complex frameworks as frequently, so I suspect that in the larger 
view the message of resource efficiency is a sound one.


* Running LC as a CGI, as happens with LiveCode Server, places unusually 
strong emphasis on runtime efficiency, since it needs to load, 
initialize, run, and die in the time it takes to satisfy an HTTP request.

Accordingly, I've been exploring LC's boot sequence with strace on 
Linux, and have found some redundant calls that can be removed, which 
will boot its overall efficiency just a little bit more.

The biggest redundancy is unfortunately something that AFAIK only 
affects standalones:  it makes 93 attempts to open revDatabaseLibray, 
looking for various permutations (no suffice, with ".rev", with ",mc", 
etc.) and in various locations (CGI folder, one up, root, etc.).

If you're not using any database drives, all 93 of those calls are a 
waste of clock cycles.  They don't even add up to much, but with 
multiple instances of the engine running as a CGI it can add up, so I 
was glad the team was able to confirm my report and is looking into this.

It may be that this also happens with LC server, since of course it also 
may sometimes need the DB lib, so this benefit may extend to that build 
as well.

But along the way I also found other redundancies, like multiple calls 
to getSystemTime, and others, and once those are trimmed back we may see 
boot times shortened by a useful percentage, perhaps 20-30%.

Of course in real-time measurements those are trivial, amounting to less 
than a millisecond.  But thinking in terms of scalability, since each 
call to LC Server instantiates a fresh copy, any reduction in load time 
will help extend the value of a system driven by LC as its audience 
grows, also likely to trim a bit of memory usage by having fewer calls 
in the queue.

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  Follow me on Twitter:  http://twitter.com/FourthWorldSys