Another server question (mixing node.js and LC)

[jonathandlynch at gmail.com]

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 gmail.com 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 lists.runrev.com> 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:
>> http://lists.runrev.com/pipermail/use-livecode/2016-March/225068.html
>> 
>> 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 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