> Le 29 mars 2016 à 22:29, Richard Gaskin <ambassa...@fourthworld.com> a écrit : > > Pierre Sahores wrote: > > >> Le 29 mars 2016 à 17:44, Richard Gaskin a écrit : > >> > >> Pierre Sahores wrote: > ... > > Interesting reads even if the 2d article's last test related to > > micro-caching needs to be read with care... > > Understood. I offered them merely as inspiration for the scope of > specialized services that can be delivered on super-affordable VPSes. Mine > are costing only US$5 and US$6 per month, and both are well below capacity > when running these stress tests. > > Of course each type of app will have its own unique requirements, but my > crude early tests coupled with the results we see elsewhere reinforce your > ongoing support for LiveCode as a very powerful addition to one's server-side > toolkit. > > > > If you read this, Mark, Kevin,… Well powered behind an Opentesty > > front-end (Nginx/LuaJIT), Livecode application’s server (demon fork) > > can do exactly all what Tarantool is able to do « et réciproquement > > », no less, no more while, in the mean time, Tomcat, JBoss2, > > Websphere, etc… just can’t, even in a very more costly price range > > (millions), as i use to verify it recently in being hired for an > > audit of one of the two SAP Hybris multi canal e-commerce suite / > > associated soft/hardware infrastructure handling the online shop > > services of the french « La Poste » postal service company... > > I would imagine interest is quite high in such things at the company.
Even if, as a typical JVM powered app example, SAP Hybris can work clearly well as long as it’s not urbanized in a head-down way to go with dozens of bottlenecks mainly aimed to makes the invoice fly to the sky, SAP Hybris will never work smoother, nor as fast as a well urbanized LC application’s server or Tarantool powered solution. Why ? At least because the JVM Heap Memory model will never being 50% as reliable as the C based LiveCode or Lua (Tarantool) based ones. At least, because the Java pseudo-multithreading model don’t work more well than a clean and fast single-threaded process. Where some ones are thinking that Livecode should be revamped as a multi-threaded engine to being able compete on the app's servers market, Tarantool (LuaJIT powered witch is officially a single-thread engine) proves that this assertion is irrelevant. To illustrante this point, a simple demonstration will suffice : 50 HTTP POST incoming requests —> Lua script proxy able to connect TCP ports 5941 to 5945 —> one LC application server deamon (launched via init.d at boot in starting the same application stack file via symlinks attached to the five standalone runners) behind each port —> each LC server will handle its 10 requests before going back to idle and that’s all the story. This way to go works so fine and perfectly that i permits us to reserve a port to development work while the other are in production mode. At this point, a simple restart suffice to update the production app’s servers each time it is appropriate. Simple, is’t ? At a point or an other, after adding, say, a dozen of Application’s servers to the config, the hardware host will begin to say STOP with a TOP average over 50%, the regular way to go to improve scalability in a smooth, reliable and affordable way will be to deport the RDBMS server on a separate hardware box, to add new app servers on a new box, to build a RDBMS cluster (multiple hardware boxes where the master RDBMS is configured to the receive all the incoming write operations while its slaves (the other RDBMS boxes are playing two complementary roles : a.- they receive replication requests triggers from the master after each write operation completed on it - important : UDP replications methods have to be forbidden there in favor of TCP ones; b.- they respond to all read requests to avoid asynchronous loads on both the master and the slaves RDBMS. More practical and simple as it should appears at first glance and an infinite way to scale up configurations in the most simple way to go (linear complexity model à la LegoLand). > The nature of these types of deployments make it a longer-term payoff for > them, as GPL works well for server work. Would be the case, for sure, as soon as a reference project could be established and, at this point, the legitimacy of Edinburgh to act in this way is at 100% for both UK and Western Europ at least. As an example, about what is starting up on the Lua side, the most reliable company is a 6 persons web agency established at Vincennes (near Paris). Visit them at to see what they are successfully doing with lots of smart methods and low if no investment needs at all : http://mamas.am/ Amazing works and prestigious clients, is’t ? > But systems like these can put LiveCode into the hands of some very > interesting companies, and used in conjunction with other smart tools like > NginX and postreSQL can provide a unique advantage for rapid deployment of > micro services. > In my experience, the most interesting customers will never really ask for knowledge transferts and will always prefer not to endorse the service provider responsibilities at all. It’s a good cursor to get in mind along the budget negotiation timeline. To the end, Livecode is legitimate to investigate this way to go to establish the company on a market where big gains are just awaiting for such an initiative. Its indirect competitors (IT services operators alike,at least, the french GFI, GapGemini, Thales,... would be surprised as they could be by what begins to appears on the Lua side. > > >> But my test setup was a bit weirder: lcHTTPd doesn't use Apache at > >> at all. > >> > >> The only thing handling the transactions is that one humble > >> single-threaded LC standalone process. > > > > Probably not the best way to go to setup a slave-mode reliable and > > WAF well protected server-side solution. I would recommend, at least, > > a basic Apache+LC CGI server configuration instead or, best, a > > Nginx+FCGIWrap+LC CGI server. The solutions available permits to > > deliver 50 pages/second on appropriate VPS or hosting services and > > on the reliability side, WAF configuration included), such > > configuration really helps to avoid big problems (unreachability, > > data loss, piracy, etc…). > > Exactly. These early tests were merely to measure the effectiveness of LC's > message-based network I/O. The advantage of any scripting language isn't up > front -- too many great tools like NginX for that role. > > Where LC can shine is as a worker behind NginX. And there all results seen > thus far suggest it can shine brightly. > More AB tests to come soon (LC application server versus Tarantool) as soon as the recently realized Nginx/LuaJIT master app will run from inside Tarantool. At this point, i have to terminate both its LC version clone and Tarantool deployment version but it should not take more than a couple of weeks. Any Nginx+LuaJIT+PostgreSQL or, best, Openresty+PostgreSQL hosting service to recommend ? > > >> Once moved behind a reverse proxy such a tool could easily handle > >> very high loads, using the LC engine we know and love today. > > > > For sure, clearly preferable : LC CGI is’t aimed to be an F-16 in > > about speed BUT IT IS 100% RELIABLE AS LONG IT IS CLEANLY CONFIGURED > > AND RUNS WELL CODED ROW OR, BEST, REVIGNITER POWERED SOLUTIONS. > > ...or far faster and more scalable, leave the bounds of CGI behind and use > sockets with a standalone. > > It would take only minimal work to craft a glue lib for RevIgniter or Andre's > revSpark to work with a standalone rather than the CGI-dependent LC Server. > > > > note : see about MessagePack : http://msgpack.org/ > > Good stuff. > > And in those cases where the client is also LiveCode we can use LSON > (LiveCode encoded arrays) for superfast transport and decoding. > I went not, for years now, able to defend this way to go even if its lots more reliable and affordable than relying on web stuff on the client-side. Are french clients are like sheeps in about this ? Am i an irrelevant vendor in about such solutions ? Probably Yes + Yes... > > >> Did you see Charles Warwick's post last June about a Docker > >> container for LC Server?: > >> http COLON SLASH SLASH > lists.runrev.com/pipermail/use-livecode/2015-July/216882.html > > > > I did’t. Thanks for pointing it out to me. Will read it attentively. > > On the other hand, i did, months ago, extensive tests in running a > > good num of Docker VM and to the end, i went to the conclusion that > > such configurations can’t compete against real-world configuration > > because the Docker concept itself : well to slow to replace > > production’s dedicated platforms. > > That may be a role where Juju could come in, but the more I think about this > for needs as modest as my own the more I think there's an opportunity for > something far simpler: > > Rather than Docker or Juju or something else that requires a managing process > running on the server, a VPS is already "containerized" by virtue of the "V" > in "VPS" - so why not use a simple bash script to download the various > LiveCode elements, put them into place and set permissions, install any > databases desired, config SSH and UFW to reflect how one wants to use the > machine. > > Given some time I could write a GUI that can generate such bash scripts, but > there's the rub: "given some time". :) > > > > did you test an Ubuntu smartphone / tablet ? I’m really curious about > > this and no far from abandoning Android after iOS for my personal > > needs if it can work as smoothly on phone as it runs on our laptops > > and server today ;D > > I've spent several minutes with an Ubuntu phone at the UbuCon Summit here in > February. Very nice implementation, with some bold ideas about what an > application is with their "scopes". > > Personally I'm quite immersed in the Android ecosystem, but as a developer my > hope is the Linux/ARM LiveCode engine could be outfitted with glue for Qt > using LC Builder and then we can add Ubuntu Touch to the mobile deployment > platforms. > The problem i see with the technically very reliable Android ecosystem is not related to technics but to privacy… As long as i know, Google and, even, tiers components and software providers grant access to all of our private data. On the other hand, nor Ubuntu or Canonical don’t own my credit card number and i like this. > > >> PS - Note on funky URL formats: This is my fifth attempt to send > >> this email to the list.... > > > > PS : sent this one from mail (El Capitan) without tourbe. Seems to be > > OK when i use Thunderbird from Ubuntu 14.04 too. Did you report this > > to David ? > > Heather's recommendation is to send such requests to support AT for best > routing, which I've done. > > > > PS2: I’m a Debian and Ubuntu fan. Would never roll back anymore to > > Suse (so fine before being sold to Netware) or RedHat/CentOS… > > Red Hat's been a very generous sponsor of our local Linux user group, and > they've had so much success in recent years I certainly have no complaints. > And I admire the design goals of Fedora, and others. > > But like you, I've been rather enamored of Ubuntu, both client and server. > It's popular enough that it no longer feels particularly adventurous to use > it - it's no more of a niche these days than choosing Mac or any other > non-Windows system. But ah, the flexibility.... > > -- > 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 -- Pierre Sahores mobile : 06 03 95 77 70 www.sahores-conseil.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
