Another server question (mixing node.js and LC)

jonathandlynch at jonathandlynch at
Wed Feb 28 14:49:41 EST 2018

I think you might be right, Mike. I have been reading about benchmark tests between node, Apache, and ningx. Node does not seem to live up to the hype at all. 

Sent from my iPhone

> On Feb 28, 2018, at 2:27 PM, Mike Bonner via use-livecode <use-livecode at> wrote:
> One thing you might do if you were to decide to stick with apache would be
> to make sure you use either the worker mpm or events mpm (sounds like
> events would be the one you wanted for this) (read more on this page...
> ) to get better
> performance.
> Alternatively as Richard mentioned, there is nginx, which might be just
> what the doctor ordered.  Basically, a request comes in, is handed off to
> the your lc script, and when a response is ready, it handles it and sends
> it back to the client, meanwhile still being able to listen for, and accept
> new requests. At least this is what I get from my reading, some of which
> are older postings. Sounds pretty much like what you are thinking of doing
> with node.js.
> I'm also wondering where a docker swarm might fit into your needs. multiple
> containers with a custom nginx image that can run your scripts, with load
> balancing and auto failover could be a great thing, and still be very
> lightweight. (the nginx docker on alpine is amazingly tiny, lightweight)
> I've no clue how performance and reliability might compare to node.js for
> this.
> On Wed, Feb 28, 2018 at 11:26 AM, Jonathan Lynch via use-livecode <
> use-livecode at> wrote:
>> In reading about fastCGI and LC, it seems rather experimental. I am just
>> wondering if replacing Apache with node.js as the http server would give us
>> the necessary concurrency capacity for using LC server on a large scale.
>> Basically, I am soon going to start pitching augmented tours (idea
>> suggested by guys at a business incubator) to tourism companies, using
>> Augmented Earth, and I don’t want to have the server crash if a large
>> number of people are using it all at once.
>> Sent from my iPhone
>>> On Feb 28, 2018, at 12:48 PM, jonathandlynch at wrote:
>>> Thank you, Richard
>>> A given transaction involves processing a user request, making two or
>> three requests to the database, and returning around 500 kB to the user.
>>> I certainly don’t need to load fonts in the LC process. Can that be
>> turned off?
>>> I like the idea of maintaining a queue of running LC processes and
>> growing or shrinking it as needed based on request load.
>>> How does the http server know which process to access?
>>> I know that node.js has a pretty simple code for launching a CGI process
>> and listening for a result. I don’t know how it would do that with an
>> already-running process.
>>> Sent from my iPhone
>>>> On Feb 28, 2018, at 12:22 PM, Richard Gaskin via use-livecode <
>> use-livecode at> wrote:
>>>> jonathandlynch wrote:
>>>>> I have another server question. I really like scripting with LC,
>>>>> because I can make improvements very quickly. This is important
>>>>> because of my very limited free time.
>>>>> But, I want to be able to handle many many concurrent server requests,
>>>>> the way node.js does.
>>>> Good timing.  Geoff Canyon and I have been corresponding about a
>> related matter, comparing performance of LC Server with PHP.
>>>> PHP7 is such a radical improvement over PHP5 that it's almost unfair to
>> compare it any scripting language now.  But it also prompts me to wonder:
>> is there anything in those PHP speed improvements which could be applied to
>> LC?
>>>> But that's for the future, and for CGI.  In the here-and-now, you're
>> exploring a different but very interesting area:
>>>>> Would it work to have node take In a request, launch an LC cgi
>>>>> executable to process the request, set an event listener to wait
>>>>> for LC to send the results back to Node, then have node return
>>>>> the results to the user?
>>>>> This is not unlike using Apache to launch LC CGI processes, but
>>>>> the asynchronous nature of node would, presumably, tie up fewer
>>>>> system resources and allow for larger concurrency. This could mean
>>>>> having a couple thousand LC processes running at any one time - would
>>>>> that be okay as long as the server had enough RAM?
>>>>> In general, would this work for a system that hand to handle, say,
>>>>> 10,000 server requests per minute?
>>>> A minute's a long time.  That's only 167 connections per second.
>>>> Likely difficult for any CGI, and certainly for LC (see general
>> performance relative to PHP, and the 70+% of LC boot time spent
>> initializing fonts that are almost never used in CGIs - BZ# 14115).
>>>> But there are other ways beyond CGI.
>>>> A couple years ago Pierre Sahores and I traded notes here on this list
>> about tests run with LC socket servers.  There's a lot across multiple
>> threads, but this may be a good starting point:
>>>> One thing is clear:  if high concurrency is a requirement, use
>> something dedicated to manage comms between connected clients and a pool of
>> workers.
>>>> My own tests were measuring lchttpd against Apache, a different model
>> but instructive here because it's still about socket comms.  What I found
>> was that an httpd written in LC was outmatched by Apache two-fold.  But
>> that also means that a quickly-thrown-together httpd script in LC was about
>> half as fast as the world's most popular httpd written in C by hundreds of
>> contributors specializing in that task.
>>>> So, promising for certain tasks. :)
>>>> The key with my modded fork of the old mchttpd stack was rewriting all
>> socket comms to use callbacks.  The original used callbacks only for
>> incoming POST, but I extended that to include all writes as well.
>>>> Applying this to your scenario:
>>>>  client      client      client
>>>> --------    --------    --------
>>>>    \           |          /
>>>>     ........internet.......
>>>>      \         |       /
>>>> |----------- HTTP SERVER -----------|
>>>> |     /           |          \      |
>>>> |  worker       worker      worker  |
>>>> |-----------------------------------|
>>>> While LC could be used in the role of the HTTP SERVER, that would be
>> wasteful.  It's not an interesting job, and dedicated tools like Node.js
>> and NginX will outperform it many-fold.  Let the experts handle the boring
>> parts. :)
>>>> The value LC brings to the table is application-specific.  So we let a
>> dedicated tool broker comms between external clients and a pool of workers,
>> where the workers could be LC standalones.
>>>> That's where much of Pierre's experiments have focused, and where the
>> most interesting and productive use of LC lies in a scenario where load
>> requirements exceed practical limitations of LC as a CGI.
>>>> The boost goes beyond the RAM savings from having a separate LC
>> instance for each CGI request:  as a persistent process, it obviates the
>> font-loading and other init that take up so much time in an LC CGI.
>>>> As with the lchttpd experiments, using callbacks for all sockets comms
>> between the LC-based workers and the HTTP SERVER will be essential for keep
>> throughput optimal.
>>>> TL;DR: I think you're on the right track for a possible solution that
>> optimizes your development time without prohibitively impeding scalability.
>>>> The suitability of this comes down to:  what exactly does each
>> transaction do?
>>>> 167 transactions/sec may not be much, or it might be a lot.
>>>> If a given transaction is fairly modest, I'd say it's probably worth
>> the time to put together a test system to try it out.
>>>> But if a transaction is CPU intensive, or heavily I/O bound, or
>> otherwise taking up a lot of time, the radical changes in PHP7 may make it
>> a better bet, esp. if run as FastCGI.
>>>> Can you tell us more about what a given transaction involves?
>>>> --
>>>> Richard Gaskin
>>>> Fourth World Systems
>>>> Software Design and Development for the Desktop, Mobile, and the Web
>>>> ____________________________________________________________________
>>>> Ambassador at      
>>>> _______________________________________________
>>>> use-livecode mailing list
>>>> use-livecode at
>>>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
> _______________________________________________
> use-livecode mailing list
> use-livecode at
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:

More information about the Use-livecode mailing list