Why is node.js faster than LC server?
andre at andregarzia.com
Tue Dec 5 09:40:39 EST 2017
It is not that simple. There is no silver bullet that can be added to a
language to make it scale by couple orders of magnitude like this. LiveCode
engine while is executing your business logic is not doing anything else
(it might be tidying up the house bit, I haven't looked at it but it is
definitely not executing other parts of your business code). Other
languages with support of fibers/coroutines can basically switch what they
are doing like an OS with multithreading without actually the threading
part. Some other languages support full threads and some even allow you to
fork(). But as far as I am aware LC datatypes and workflow is not thread
safe (someone familiar with the internals might correct me here) which
makes it a time bomb if you go spawning threads. Also thread programming is
quite complex and data races are a real problem, Mozilla creation of Rust
was in-parts to prevent data races with a safer language, thats how big
this problem is, people go and create new languages to solve it.
LC bottleneck is not database queries, the queries spend more time inside
the database than they do in transit between the revdb external and the
rdbms. There is not something that we can bolt on top of the current LC
engine to make it behave like nodejs (non-blocking with async language and
jit) and that is not even desirable. NodeJS programming requires a ton of
tooling and knowledge that is not at all related to whatever business
you're trying to solve, LC is much more a pick and go language than NodeJS
ever will be. Doing a simple setup of a modern NodeJS sample based on
server-side rendering and react will probably download hundreds of
megabytes in developer dependencies, just to get the sample to compile.
Imagine if one of your stacks required THOUSANDS of little stacks that
amounted to HUNDREDS of megabytes on disk, just to load. That is the land
of NodeJS, it has its own problems.
Other potential solutions for deploying LC based server software have been
attempted in the past, I will summarize two of them below as
## THE FASTCGI APPROACH ##
Long long time ago, in a Runtime Revolution far far away, I coded a fastcgi
stack. Fastcgi is a protocol specification that allows using a single
connection (or a pool) to multiplex requests from a server. So using
something like a persistent TCP connection to Apache, you could answer
multiple requests. The problem with fastcgi and LC is the same as outlined
above, while the cgi part was trying to solve something, it would not
respond to requests, thats the bottleneck: the blocking code part. Imagine
that your cgi needs to fetch a large data set from a file and process it
before answering and that this process took 5 seconds. During those
seconds, the server would be unresponsive.
## THE ENGINE POOL ##
I believe it was Richard who did this, can't recall, it was definitely not
me. Keep a pool of engines running, lets say 20, use a node balancer to
round robin them. This allows you to answer at least 20 concurrent
requests. Then engine pool is only desirable over our normal CGI method in
one very specific case: The current LC server is CGI based, so it spawns a
new engine for each request, if you're on a memory constrained machine that
can't afford this escalation of memory and cpu usage, you keep a pool of
engines in a safe threshold and use the pool. I can only see this working
well on a raspberry pi, all other cases CGI should work better.
## Curiosity nuggets of semi-related trivia ##
Oh, and sometimes even NodeJS is slow, check out this article I wrote
couple weeks ago:
http://andregarzia.com/en/blog/creating-rust-based-nodejs-modules in which
I show a dramatic speedup in a NodeJS codebase by converting the most
critical part of the code into a Rust based module. The code used to
execute in 3 seconds and went to execute in 150 miliseconds.
On Tue, Dec 5, 2017 at 9:29 AM, Jonathan Lynch via use-livecode <
use-livecode at lists.runrev.com> wrote:
> To make this happen, it seems like we would need an external that
> multithreads database queries and sends the query results back to LC as a
> new message. It would have to bring in a new ID for each request and return
> that ID with the result.
> Can the ODBC external do that?
> Sent from my iPhone
> > On Dec 4, 2017, at 2:06 PM, Richard Gaskin via use-livecode <
> use-livecode at lists.runrev.com> wrote:
> > jonathandlynch wrote:
> > > 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.
> > Scaling is a fascinating problem. I found the C10k problem a good
> starting point (in recent years supplanted with C10m):
> > <https://en.wikipedia.org/wiki/C10k_problem>
> > > I also found a thread discussing this idea from a few years ago that
> > > Richard was part of. It was very informative.
> > I usually just quote Pierre or Andre, but once in a while my OCD habits
> with benchmarking add something useful. :)
> > > 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.
> > Node.js is good where Node.js is needed. In some cases NginX is good.
> In other cases Lighttpd is fine. And in many cases Apache is fine, even
> with simple CGI.
> > Most of us never need to think about C10m, or even C10k. If we do,
> that's a wonderfully fortunate problem to have. Just having that problem
> makes it much easier to get funding to solve it with specialists. Let the
> t-shirts sort it out while the suits focus on strategy.
> > --
> > 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
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
http://www.andregarzia.com -- All We Do Is Code.
http://fon.nu -- minimalist url shortening service.
More information about the Use-livecode