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 > [email protected] > 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 _______________________________________________ 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
