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
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
