Re: LC Server- Optimum setup
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. Best, Bill William Prothero http://es.earthednet.org > 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: > 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 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.comhttp://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
Re: LC Server- Optimum setup
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 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.comhttp://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
Re: LC Server- Optimum setup
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 > 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 > > ambassa...@fourthworld.comhttp://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
Re: LC Server- Optimum setup
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 ambassa...@fourthworld.comhttp://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
RE: LC Server- Optimum setup
I use it daily for everything from web pages to my homebrew web services. I don't have a heavy load but I have not received and performance complaints from customers. Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net -Original Message- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of prothero--- via use-livecode Sent: Monday, October 19, 2020 1:27 PM To: JJS via use-livecode Cc: proth...@earthlearningsolutions.org Subject: LC Server- Optimum setup Folks, I’ve reposted this in a new thread, at Sean's suggestion. Please ignore my posting in the ssl thread. 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. Thanks! Bill William A. Prothero Santa Barbara, CA. 93105 http://earthlearningsolutions.org/ ___ 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
