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
