Why is node.js faster than LC server?

[jonathandlynch at gmail.com]

Hi Richard and Andre - thanks for your replies. I was the one who mentioned millions of users at the same time, not out of drunkenness but because I wanted to understand the upper limits of these systems. 

I also found a thread discussing this idea from a few years ago that Richard was part of. It was very informative.

I think an all-LC very fast server would be a great thing, but it sounds like just using node would be more realistic. I might fiddle a bit with this idea, just to satisfy my curiosity.

Sent from my iPhone

> On Dec 4, 2017, at 1:40 PM, Richard Gaskin via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> Andre Garzia wrote:
> 
> > On Mon, Dec 4, 2017 at 3:13 PM, Richard Gaskin via use-livecode wrote:
> ...
> >> I don't even think we'd need tsNet for that.  Sockets should suffice
> >> for communicating between backend services, and using the "with
> >> messages" option makes them async; indeed that single-threaded
> >> message-driven approach is a big part of what makes Node.js so
> >> performant, offloading as much as practical from the process thread
> >> to the OS.
> ...
> > IMHO opinions it is not fair to compar NodeJS and LC Server on merits
> > of performance because they are really different beasts...
> ...
> > All this changes both inside the language itself and on top of it
> > in form of syntatic sugar serves one purpose only, give the developer
> > good ergonomics while keeping the code asynchronous/non-blocking.
> >
> > LiveCode is not an asynchronous language. It has some APIs that work
> > asynchronously when we want them to, but it is not a non-blocking
> > engine.
> 
> The stylistic differences, and their implications in implementation, is indeed important.  Thanks for that outline.
> 
> Google's massive investment in JS will be hard to match for anyone seeking to deliver equivalent systems.
> 
> Which leaves us asking:  When you want something like Nide.js, why not just use Node.js?
> 
> 
> 
> > All our "PUT URLs" calls are blocking...
> 
> Take a second look at the original libURL code.  IIRC, in the course of exploring some other issues in which what I wanted was truly sync behavior but finding it difficult to actually achieve it, it seems libURL is using the "with messages" option for socket calls, and where sync is needed that's emulated within an async socket method.
> 
> Not sure why, and I've been tempted to write my own HTTP client code just to make sure I get truly sync behavior when I need it (hoping I'll find a way to get that with tsNet once I get back to that problem).
> 
> But if it's of interest, take a gander at libURL and let me know if I've overlooked something.  If nothing else I'll finally have the true sync behavior I'm looking for.  But we may also find that socket comms in LC, when using the "with messages" option, use callbacks in a way that efficiently leverages OS integration.
> 
> Of course this alone doesn't put LC on par with Node.js, for all the reasons you noted.  But it does potentially offer opportunities for reasonably efficient socket comms, which may be esp. useful on backends where all we need are sockets, not necessarily encumbered with also supporting HTTP on top.
> 
> 
> > Your original email about scaling anything to millions of users
> > doesn't outline some needs of working at that scale.
> 
> If I ever wrote that I was drunk.  But I don't recall writing that; it's not consistent with my thinking.  I've done enough testing on the C10k problem to be well aware of the challenges of attempting C10m.
> 
> When big systems are needed, big ecosystems help.  As a right-tool-for-the-right-job kinda guy, I generally advocate industry standards for such things.
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> ____________________________________________________________________
> Ambassador at FourthWorld.com                http://www.FourthWorld.com
> 
> _______________________________________________
> 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