Virtual Server Install

Sat Jun 1 06:44:31 EDT 2013

Thanks for this great resume Richard! Add me to the petition, friends, if this way of hosting services LC-server evangelization is chosen ;-)

Pierre

Le 31 mai 2013 à 20:58, Richard Gaskin a écrit :

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

--
Pierre Sahores
mobile : 06 03 95 77 70
www.sahores-conseil.com