Thank you Andre, The fact that one of the bottlenecks is in waiting for the database to get the data back is what I was targeting. If LC just sends a request to a different program, and that program spawns a new thread for each request, then LC is free to keep working. In this way, LC would be single-threaded and handling database activities asynchronously.
It appears this can be done with using asynchronous http requests sent to a database program with an http plugin, but that seems weird and clunky to me. Just to clarify, I am not trying to multithread with LC or use multiple processes with LC. I am wondering about using multithreading in an external that then sends search results back to LC as they become available. LC would still be single-threaded in this scenario. The end result is that LC keeps working while the database is handling multiple searches. Sent from my iPhone > On Dec 5, 2017, at 9:40 AM, Andre Garzia <an...@andregarzia.com> wrote: > > Jonathan, > > It is not that simple. There is no silver bullet that can be added to a > language to make it scale by couple orders of magnitude like this. LiveCode > engine while is executing your business logic is not doing anything else (it > might be tidying up the house bit, I haven't looked at it but it is > definitely not executing other parts of your business code). Other languages > with support of fibers/coroutines can basically switch what they are doing > like an OS with multithreading without actually the threading part. Some > other languages support full threads and some even allow you to fork(). But > as far as I am aware LC datatypes and workflow is not thread safe (someone > familiar with the internals might correct me here) which makes it a time bomb > if you go spawning threads. Also thread programming is quite complex and data > races are a real problem, Mozilla creation of Rust was in-parts to prevent > data races with a safer language, thats how big this problem is, people go > and create new languages to solve it. > > LC bottleneck is not database queries, the queries spend more time inside the > database than they do in transit between the revdb external and the rdbms. > There is not something that we can bolt on top of the current LC engine to > make it behave like nodejs (non-blocking with async language and jit) and > that is not even desirable. NodeJS programming requires a ton of tooling and > knowledge that is not at all related to whatever business you're trying to > solve, LC is much more a pick and go language than NodeJS ever will be. Doing > a simple setup of a modern NodeJS sample based on server-side rendering and > react will probably download hundreds of megabytes in developer dependencies, > just to get the sample to compile. Imagine if one of your stacks required > THOUSANDS of little stacks that amounted to HUNDREDS of megabytes on disk, > just to load. That is the land of NodeJS, it has its own problems. > > Other potential solutions for deploying LC based server software have been > attempted in the past, I will summarize two of them below as > food-for-thoughts. > > ## THE FASTCGI APPROACH ## > Long long time ago, in a Runtime Revolution far far away, I coded a fastcgi > stack. Fastcgi is a protocol specification that allows using a single > connection (or a pool) to multiplex requests from a server. So using > something like a persistent TCP connection to Apache, you could answer > multiple requests. The problem with fastcgi and LC is the same as outlined > above, while the cgi part was trying to solve something, it would not respond > to requests, thats the bottleneck: the blocking code part. Imagine that your > cgi needs to fetch a large data set from a file and process it before > answering and that this process took 5 seconds. During those seconds, the > server would be unresponsive. > > ## THE ENGINE POOL ## > I believe it was Richard who did this, can't recall, it was definitely not > me. Keep a pool of engines running, lets say 20, use a node balancer to round > robin them. This allows you to answer at least 20 concurrent requests. Then > engine pool is only desirable over our normal CGI method in one very specific > case: The current LC server is CGI based, so it spawns a new engine for each > request, if you're on a memory constrained machine that can't afford this > escalation of memory and cpu usage, you keep a pool of engines in a safe > threshold and use the pool. I can only see this working well on a raspberry > pi, all other cases CGI should work better. > > ## Curiosity nuggets of semi-related trivia ## > Oh, and sometimes even NodeJS is slow, check out this article I wrote couple > weeks ago: http://andregarzia.com/en/blog/creating-rust-based-nodejs-modules > in which I show a dramatic speedup in a NodeJS codebase by converting the > most critical part of the code into a Rust based module. The code used to > execute in 3 seconds and went to execute in 150 miliseconds. > > >> On Tue, Dec 5, 2017 at 9:29 AM, Jonathan Lynch via use-livecode >> <use-livecode@lists.runrev.com> wrote: >> To make this happen, it seems like we would need an external that >> multithreads database queries and sends the query results back to LC as a >> new message. It would have to bring in a new ID for each request and return >> that ID with the result. >> >> Can the ODBC external do that? >> >> Sent from my iPhone >> >> > On Dec 4, 2017, at 2:06 PM, Richard Gaskin via use-livecode >> > <use-livecode@lists.runrev.com> wrote: >> > >> > jonathandlynch wrote: >> > >> > > Hi Richard and Andre - thanks for your replies. I was the one who >> > > mentioned millions of users at the same time, not out of drunkenness >> > > but because I wanted to understand the upper limits of these systems. >> > >> > Scaling is a fascinating problem. I found the C10k problem a good >> > starting point (in recent years supplanted with C10m): >> > >> > <https://en.wikipedia.org/wiki/C10k_problem> >> > >> > >> > > I also found a thread discussing this idea from a few years ago that >> > > Richard was part of. It was very informative. >> > >> > I usually just quote Pierre or Andre, but once in a while my OCD habits >> > with benchmarking add something useful. :) >> > >> > >> > > I think an all-LC very fast server would be a great thing, but it >> > > sounds like just using node would be more realistic. I might fiddle >> > > a bit with this idea, just to satisfy my curiosity. >> > >> > Node.js is good where Node.js is needed. In some cases NginX is good. In >> > other cases Lighttpd is fine. And in many cases Apache is fine, even with >> > simple CGI. >> > >> > Most of us never need to think about C10m, or even C10k. If we do, that's >> > a wonderfully fortunate problem to have. Just having that problem makes >> > it much easier to get funding to solve it with specialists. Let the >> > t-shirts sort it out while the suits focus on strategy. >> > >> > -- >> > 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 > > > > -- > http://www.andregarzia.com -- All We Do Is Code. > http://fon.nu -- minimalist url shortening service. _______________________________________________ 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
