Thanks, Richard!
RevIgniter also looks like something I should explore.
Would a program that needs to produce graphs be practical? My current work 
requires various plots of earth data. Just wondering if I could think about 
getting it on a web server.


William Prothero

> On Oct 20, 2020, at 6:30 PM, Richard Gaskin via use-livecode 
> <> wrote:
> 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:
> This blog post may help spark ideas for how to put LC to work on system 
> monitoring and other tasks:
> -- 
> 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
>>>> On Oct 19, 2020, at 11:03 AM, Richard Gaskin via use-livecode 
>>>> <use-livecode at> 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
>>> 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      
> _______________________________________________
> use-livecode mailing list
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to