Sannyasin Brahmanathaswami wrote:
> On 11/1/18 5:02 PM, Stephen MacLean via use-livecode wrote:
>> LC server, can do it, but also suffers, from what I’ve read in my
>> research, a speed penalty from CGI implementation vs direct sockets,
>> etc.
>
> Well that "speed penality" is theoretical. Our web site
>
> https://www.himalayanacademy.com
>
> uses Livacode server, and for all "gorilla dust" about LC's one
> thread, open multiple CGIs, and how it is "old fashioned"
In addition to Andre's comments earlier this morning, there is another,
perhaps more fundamental, difference between your setup and lcHTTPd:
You're still using Apache for most of the heavy lifting.
Consider the two setups, each with requests for different media types:
LC Server with .lc files:
Internet -> Apache -> LC Server
LC Server with images/CSS/everything that isn't .lc:
Internet -> Apache
lcHTTPd with LC scripts:
Internet -> LC
lcHTTPd with images/CSS/everything that isn't LC:
Internet -> LC
With LC Server, Apache handles all socket I/O and most file I/O. Indeed,
it's handling ALL file I/O for most media types, except the relatively
small subset of requests for .lc files where it still handles the
reading of the requested .lc script but from there any further file I/O
is of course up to your script.
With lcHTTPd, it must handle everything: all socket and file I/O, in
addition to whatever your script needs to do.
In short:
LC Server is a CGI that works in conjunction with dedicated HTTPd
software like Apache.
lcHTTPd does what LC Server does AND ALSO attempts to replace the role
of Apache for managing I/O and serving static files.
LC is a great language, and as Node.js and NGinX show us, being
single-threaded need not necessarily be a drawback.
But Apache, Node.js, and NGinX are written in languages compiled to
machine code, and by large teams focused on honing the engine for the
one specific set of tasks an HTTP broker needs to accomplish.
A scripted solution in a more general purpose tool like LC is unlikely
to compete favorably.
There is a role for custom HTTP handling, but with so many great tools
available that are specialized for that task the use cases where
choosing LC for that may be optimal are few.
The HTTPd lib included with LC is designed for one good use case: local
testing.
But for remote servers that need to handle public loads, better to do
what you're doing: use Apache (or other dedicated HTTP broker) to
handle the I/O, and use LC for the dynamic application-specific stuff
where LC really shines.
--
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
