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
