LC Server- Optimum setup

Richard Gaskin ambassador at fourthworld.com
Tue Oct 20 21:30:01 EDT 2020


When you are, you're in good company. Just let us know if you get stuck 
on anything and we'll get your server running in no time.

'Tween now and then, you might want to check out this blog post on a 
nice addition to LC Server added a couple years back, letting you use LC 
as a general purpose command-line language in addition to how most 
people use it as a PHP replacement:
https://livecode.com/livecode-server/

This blog post may help spark ideas for how to put LC to work on system 
monitoring and other tasks:
https://livecode.com/keeping-an-eye-on-your-server/

-- 
  Richard Gaskin
  Fourth World Systems


William Prothero wrote:
> Thanks, Richard. Good info. I’m not quite ready to jump in on this yet, but soon, and probably with Trevore’s Levure app.
> Best,
> Bill
> 
> William A. Prothero
> https://earthlearningsolutions.org
> 
>> On Oct 19, 2020, at 11:03 AM, Richard Gaskin via use-livecode <use-livecode at lists.runrev.com> wrote:
>> 
>> prothero wrote:
>> 
>> > I’ve been thinking about experimenting with Livecode server. I have
>> > a vps and root access, but I’m wondering what are the speed and user
>> > consequences of installing it at root level, or as a cgi. The cgi is
>> > fairly large and I’m concerned about both speed and memory issues when
>> > multiple users are accessing it.
>> >
>> > I know this has been discussed in the past, but would appreciate any
>> > advice based on recent experience.
>> 
>> CGIs are CGIs, whether configured for all users via admin access to Apache config, or for individual users on a shared host via .htacces.
>> 
>> Also, the size on disk is not reflective of real-world RAM requirements. You can check RAM requirements in Terminal by calling the engine with a simple script using the timing tool located at /usr/bin/time:
>> 
>>  /user/bin/time -v /path/to/your/lcserver somescript.lc
>> 
>> The -v flag is for "verbose", listing a wide range of runtime stats including "Maximum resident set size" and "Average resident set size", with "set size" referring to physical RAM used.
>> 
>> For example, running that on the script I posted earlier for my example CGI yields:
>> 
>>        User time (seconds): 0.02
>> 	System time (seconds): 0.02
>> 	Percent of CPU this job got: 97%
>> 	Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.04
>> 	Average shared text size (kbytes): 0
>> 	Average unshared data size (kbytes): 0
>> 	Average stack size (kbytes): 0
>> 	Average total size (kbytes): 0
>> 	Maximum resident set size (kbytes): 19728
>> 	Average resident set size (kbytes): 0
>> 	Major (requiring I/O) page faults: 0
>> 	Minor (reclaiming a frame) page faults: 1526
>> 	Voluntary context switches: 1
>> 	Involuntary context switches: 0
>> 	Swaps: 0
>> 	File system inputs: 0
>> 	File system outputs: 0
>> 	Socket messages sent: 0
>> 	Socket messages received: 0
>> 	Signals delivered: 0
>> 	Page size (bytes): 4096
>> 	Exit status: 0
>> 
>> 
>> Separate from anything to do with LC, there is a modest performance difference between using .htacess and making those directives available to all users in Apache config: if you don't enable mod_rewrite, Apache doesn't need to scan folders for .htaccess files.  This is a VERY minor difference, however, and if you need the flexibility of mod_rewrite you should use it.
>> 
>> But FWIW most production servers set things up in Apache config, and since you're not limited to the issues with shared hosting you might as well do it the standard way.  It's more work, and you'll be using sudo a lot since permissions are tighter.  But for a production server, more restrictive permissions are exactly what we want.
>> 
>> -- 
>> Richard Gaskin
>> Fourth World Systems
>> Software Design and Development for the Desktop, Mobile, and the Web
>> ____________________________________________________________________
>> Ambassador at FourthWorld.com                http://www.FourthWorld.com
>> 





More information about the use-livecode mailing list