Another server question (mixing node.js and LC)

jonathandlynch at gmail.com jonathandlynch at gmail.com
Thu Mar 1 07:41:47 EST 2018


Is it possible to solve the C10k problem with simple CGI? LC has a relatively small footprint in RAM. If each LC process takes up 7 meg, then 10,000 processes would take 70 gig of ram. NginX can manage that  no problem on a dedicated server. Is there any reason why that would not work?

Sent from my iPhone

> On Feb 28, 2018, at 2:49 PM, jonathandlynch at gmail.com wrote:
> 
> 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 lists.runrev.com> 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...
>> https://httpd.apache.org/docs/2.4/misc/perf-tuning.html ) 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 lists.runrev.com> 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 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
>>> 
>>> _______________________________________________
>>> 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://lists.runrev.com/mailman/listinfo/use-livecode




More information about the Use-livecode mailing list