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, jonathandly...@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@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@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, jonathandly...@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@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 >>>>> ____________________________________________________________________ >>>>> ambassa...@fourthworld.com http://www.FourthWorld.com >>>>> >>>>> _______________________________________________ >>>>> use-livecode mailing list >>>>> use-livecode@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@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@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
