Livecode Server performance
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
Livecode Server performance
I like Livecode because it is a multiplatform code base.
I doubt the performance.
i compared php 7 and livecode server business 9.6.1.
1GB RAM 1CPU Linode with Apache2
code references from here. http://lists.runrev.com/pipermail/use-l ... 03033.html
the results were disappointing.
whether the livecode is not optimal for the server?
is there any way to do optimization?
thank you for helping
I doubt the performance.
i compared php 7 and livecode server business 9.6.1.
1GB RAM 1CPU Linode with Apache2
code references from here. http://lists.runrev.com/pipermail/use-l ... 03033.html
the results were disappointing.
whether the livecode is not optimal for the server?
is there any way to do optimization?
thank you for helping
-
- VIP Livecode Opensource Backer
- Posts: 9847
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Livecode Server performance
The LiveCode results note that the test was aborted due to errors. What was the error?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Livecode Server performance
Hai Richard ,
loader.io will return an error, if the request requests too many errors.
loader.io will return an error, if the request requests too many errors.
-
- VIP Livecode Opensource Backer
- Posts: 9847
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Livecode Server performance
Understood. What is the error that there are too many of?
It seems we're having a recursion error in this thread.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Livecode Server performance
Hi,
Remark:
In "lc9" is a LiveCodeCommunityServer-9_6_2_rc_4-Linux-x86_64.
In "lc8" is a LiveCodeCommunityServer-8_1-Linux-x86_64.
All settings are identical. The problem consists since 9.5.1-64 at least.
Server is:
(It's a shared server)
Have fun!
Maybe it's the same error I encounter?What is the error that there are too many of?
Code: Select all
ssh-[prompt]:/www/htdocs/[user]/domain.de/cgi-bin$ ./lc9/lcserver ./test.lc
Segmentation fault
ssh-[prompt]:/www/htdocs/[user]/domain.de/cgi-bin$ ./lc8/lcserver ./test.lc
Hello World! 8:52 PM
In "lc9" is a LiveCodeCommunityServer-9_6_2_rc_4-Linux-x86_64.
In "lc8" is a LiveCodeCommunityServer-8_1-Linux-x86_64.
All settings are identical. The problem consists since 9.5.1-64 at least.
Server is:
Code: Select all
ssh-[prompt]:/www/htdocs/[user]$ uname -a
Linux dd33820 5.4.0-67-generic #75-Ubuntu SMP
Fri Feb 19 18:03:38 UTC 2021
x86_64 x86_64 x86_64 GNU/Linux
Have fun!
All code published by me here was created with Community Editions of LC (thus is GPLv3).
If you use it in closed source projects, or for the Apple AppStore, or with XCode
you'll violate some license terms - read your relevant EULAs & Licenses!
If you use it in closed source projects, or for the Apple AppStore, or with XCode
you'll violate some license terms - read your relevant EULAs & Licenses!
-
- VIP Livecode Opensource Backer
- Posts: 9847
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Livecode Server performance
Thanks, Ax.
For server work I tend to use only Stable versions; testing with the latest Stable (v9.6.1) reports no error.
Are you able to reproduce the error with v9.6.1?
For server work I tend to use only Stable versions; testing with the latest Stable (v9.6.1) reports no error.
Are you able to reproduce the error with v9.6.1?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Livecode Server performance
I mean. Livecode server has no errors. The response from the livecode server to the requests from the loader is very slow.
with a php server response of 400 or 500 is 0 meaning that php can receive quite a lot of requests.
with livecode server get a response 500 is 208 and 440 timeouts.
some of the steps i did was.
1. fresh install ubuntu server linode 1GB RAM and 1vCPU
2. install apache server
3. install livecode server. I use a livecode server business version with install php7
4. without doing "apache performance tuning"
5. create an lcstest.lc file
6. create a phptest.lc file
6. use loader.io to do a server test.
Take a look at how the php server responds better than the livecode server.
I stick with the livecode server in this case. because I don't want to rewrite it in another language. I chose the Livecode server because I can write the same code for mobile and desktop apps. my case is to build an MVP.
currently to handle a lot of requests is to use a load balancer. and I think it is enough to handle a lot of requests in my case.
anyone who has ever tried to optimize livecode server.
You are welcome to share suggestions.
with a php server response of 400 or 500 is 0 meaning that php can receive quite a lot of requests.
with livecode server get a response 500 is 208 and 440 timeouts.
some of the steps i did was.
1. fresh install ubuntu server linode 1GB RAM and 1vCPU
2. install apache server
3. install livecode server. I use a livecode server business version with install php7
4. without doing "apache performance tuning"
5. create an lcstest.lc file
Code: Select all
<?lc
put 0 into myVar
repeat for 100 times
add 1 to myVar
put myVar
end repeat
?>
Code: Select all
<?php
$myVar=0;
while($myVar < 100) {
$myVar ++;
echo $myVar;
}
?>
Take a look at how the php server responds better than the livecode server.
I stick with the livecode server in this case. because I don't want to rewrite it in another language. I chose the Livecode server because I can write the same code for mobile and desktop apps. my case is to build an MVP.
currently to handle a lot of requests is to use a load balancer. and I think it is enough to handle a lot of requests in my case.
anyone who has ever tried to optimize livecode server.
You are welcome to share suggestions.
-
- VIP Livecode Opensource Backer
- Posts: 9847
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Livecode Server performance
How does LC compare to Python and Ruby?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Livecode Server performance
Hi,
The "segmentation fault" I speak of is only noticeable in SSH - when called as CGI (via Apache) I get only:
I did some tests again. Calling from LC:
Using on the server:
<?php ?> & <?lc ?> lines omitted ...
Results:
Each test was run 10 - 20 times, and a typical result was selected. For "long" the results was too variable to show a trend - shown is a "best time" for PHP, LC was even faster sometimes.
My interpretation: For short tasks LC 8.1 is slower (~150%). PHP (7.2 here) seems well optimized for this.
With a growing amount of data LC comes closer. I have yet to test database operations.
Too bad I have no ldd in my SSH.
Have fun!
PS: Made a bug report (23163).
What I meant was that maybe LC server throws an error & the loader then reports timeout? Have you made sure your .lc is actually executed, using SSH directly?
The "segmentation fault" I speak of is only noticeable in SSH - when called as CGI (via Apache) I get only:
Code: Select all
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Code: Select all
on mouseUp
put empty
put "https://domain.com/cgi-bin/" into myserverURL
-- =============================================================
/* Acivate only one of these 2 2-liners: */
-- put "Alonglonglongword" into myVar
-- put "short" into myLen
-- -------------------------------------------------------------
put "What I meant was that maybe LC server throws an error & the loader " & \
"then reports timeout? Have you made sure your .lc is actually executed, " & \
"using SSH directly?The segmentation fault I speak of is only noticeable in SSH " & \
"- when called as CGI (via Apache) I get only:" into myVar
put "long" into myLen
-- =============================================================
/* Acivate only one of these 2 lines: */
put "charsum" into myScript
-- put "upperme" into myScript
-- =============================================================
put the millisecs into t1
repeat 10
get URL (myServerURL & myScript & ".lc?data=" & myVar)
end repeat
put the millisecs into t2
put t2 - t1 into myLCTime
put the millisecs into t1
repeat 10
get URL (myServerURL & myScript & ".php?data=" & myVar)
end repeat
put the millisecs into t2
put t2 - t1 into myPhpTime
put "Time ('" & myscript & ", " & myLen & "') PHP / LC: " & myPhpTime & " / " & myLCTime & CR & \
"If PHP = 100%, LC = " & round((myLCTime / (myPhpTime / 100)),0) & "%"
end mouseUp
Code: Select all
// == upperme.php:
echo strtoupper($_GET['data']);
// == upperme.lc:
put upper($_GET["data"])
==============================
// == charsum.php:
$Strg = $_GET['data'];
$SLen = strlen($Strg);
$Res = 0;
for ($i = 0; $i < $SLen; $i++){
$Res = $Res + ord($Strg[$i]);
}
echo $Res;
// == charsum.lc:
repeat for each char C in $_GET["data"]
add charToNum(C) to myRes
end repeat
put myRes
Results:
Code: Select all
Time ('charsum, short') PHP / LC: 518 / 765
If PHP = 100%, LC = 148%
Time ('charsum, long') PHP / LC: 2107 / 2089
(huge variances here, random good result)
Time ('upperme, short') PHP / LC: 520 / 765
If PHP = 100%, LC = 147%
Time ('upperme, long') PHP / LC: 3101 / 3099
(huge variances here, random good result)
My interpretation: For short tasks LC 8.1 is slower (~150%). PHP (7.2 here) seems well optimized for this.
With a growing amount of data LC comes closer. I have yet to test database operations.
I'd be happy enough if I could find someone to answer even some basic questions about LC server here. But it seems this is a rather forgotten niche product, used by close to no one :/
Hmpff. Everytime else I'm recommended to always use the newest version ... :/
Yup. Just tried again: "Segmentation fault". 8.1 runs.
Too bad I have no ldd in my SSH.
Have fun!
PS: Made a bug report (23163).
All code published by me here was created with Community Editions of LC (thus is GPLv3).
If you use it in closed source projects, or for the Apple AppStore, or with XCode
you'll violate some license terms - read your relevant EULAs & Licenses!
If you use it in closed source projects, or for the Apple AppStore, or with XCode
you'll violate some license terms - read your relevant EULAs & Licenses!
-
- VIP Livecode Opensource Backer
- Posts: 9847
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Livecode Server performance
Thanks for filing the bug report, Ax.
RE versions: I generally use the latest build for day-to-day work to make any bug reports more actionable, with deployments like standalones and servers limited to Stable to minimize regressions.
RE shared hosts: I use shared myself for many things, but given that an average machine at a profitable hosting company will have between 200 and 300 other tenants running on it, the "noisy neighbor" problem makes benchmarking problematic. I'll see if I can get some time to run this test on a VPS soon.
RE PHP7+ speed: For most of the history of server-side scripting, PHP, Perl, Python, MetaCard/LiveCode all ran about the same, with a few things a bit faster in one than the other. Then PHP 7 happened. Total game changer. Much has been written about it, but in short no other scripting language in common use even comes close to it for raw speed. They did some great work.
This chart shows relative performance of a wide range of server languages: That's from this article, a worthy read: What Programming Language Should I Learn First in 2021?
If speed is the only consideration, even better than PHP would be Node.js. And even better than Node would be Go. And faster than Go is machine code compiled from C.
Performance is always important, and on servers even more so. But does it override all other considerations when choosing a language to develop a given project in?
Not for the inventor of the Rails framework, who found Ruby fast enough when he first wrote Rails, and shared some thoughts on that a few years ago:
Ruby has been fast enough for 13 years.
Security is also a consideration, and while I would never advocate "security by obscurity", PHP is a high-value target walking around dark alleys with a target on its back. Proportionately, PHP gets more attention from organized crime than it does from recruiters.
I won't blame PHP for being popular. It's a fine language. And so is Ruby. And Python. And LiveCode.
Indeed, LiveCode's chunk expressions make it a natural fit for server work, where most of what we do is parsing and concatenating text. For myself, the ability to deploy robust code quickly is a high priority. I'd much rather shave two weeks off my development schedule than 20 milliseconds off a response time.
Where performance is critical, shared hosting is a bigger impediment than nearly any differences between scripting languages. And far less predictable.
But I don't think shared hosting is necessarily a bad thing. I use it myself where it's a good fit.
Shared hosting is fast enough for many millions of sites.
And so is LiveCode.
The optimizations that pushed PHP 7 ahead of most other scripting languages didn't mean Ruby or Python or anything else went away. We have many languages to choose from because each brings something uniquely valuable to the table.
LiveCode has a place among the great scripting languages of our time. Use what works for you.
And all that said, benchmarks that include errors aren't very helpful in assessing performance. And when those are run on a shared host, even less so.
Any comparison of nearly anything that isn't Node or Go will measure slower than PHP 7. But whether that makes any difference in real-world performance depends on the app. And where real-world performance matters enough to worry about, it isn't happening on a shared host.
Let's get those errors sorted. Doesn't matter how fast something is if it isn't producing a reliable result. Your bug report on that is a great first step. Thanks.
RE versions: I generally use the latest build for day-to-day work to make any bug reports more actionable, with deployments like standalones and servers limited to Stable to minimize regressions.
RE shared hosts: I use shared myself for many things, but given that an average machine at a profitable hosting company will have between 200 and 300 other tenants running on it, the "noisy neighbor" problem makes benchmarking problematic. I'll see if I can get some time to run this test on a VPS soon.
RE PHP7+ speed: For most of the history of server-side scripting, PHP, Perl, Python, MetaCard/LiveCode all ran about the same, with a few things a bit faster in one than the other. Then PHP 7 happened. Total game changer. Much has been written about it, but in short no other scripting language in common use even comes close to it for raw speed. They did some great work.
This chart shows relative performance of a wide range of server languages: That's from this article, a worthy read: What Programming Language Should I Learn First in 2021?
If speed is the only consideration, even better than PHP would be Node.js. And even better than Node would be Go. And faster than Go is machine code compiled from C.
Performance is always important, and on servers even more so. But does it override all other considerations when choosing a language to develop a given project in?
Not for the inventor of the Rails framework, who found Ruby fast enough when he first wrote Rails, and shared some thoughts on that a few years ago:
Ruby has been fast enough for 13 years.
Security is also a consideration, and while I would never advocate "security by obscurity", PHP is a high-value target walking around dark alleys with a target on its back. Proportionately, PHP gets more attention from organized crime than it does from recruiters.
I won't blame PHP for being popular. It's a fine language. And so is Ruby. And Python. And LiveCode.
Indeed, LiveCode's chunk expressions make it a natural fit for server work, where most of what we do is parsing and concatenating text. For myself, the ability to deploy robust code quickly is a high priority. I'd much rather shave two weeks off my development schedule than 20 milliseconds off a response time.
Where performance is critical, shared hosting is a bigger impediment than nearly any differences between scripting languages. And far less predictable.
But I don't think shared hosting is necessarily a bad thing. I use it myself where it's a good fit.
Shared hosting is fast enough for many millions of sites.
And so is LiveCode.
The optimizations that pushed PHP 7 ahead of most other scripting languages didn't mean Ruby or Python or anything else went away. We have many languages to choose from because each brings something uniquely valuable to the table.
LiveCode has a place among the great scripting languages of our time. Use what works for you.
And all that said, benchmarks that include errors aren't very helpful in assessing performance. And when those are run on a shared host, even less so.
Any comparison of nearly anything that isn't Node or Go will measure slower than PHP 7. But whether that makes any difference in real-world performance depends on the app. And where real-world performance matters enough to worry about, it isn't happening on a shared host.
Let's get those errors sorted. Doesn't matter how fast something is if it isn't producing a reliable result. Your bug report on that is a great first step. Thanks.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 9847
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Livecode Server performance
FWIW via shell on a VPS, similar time, LC took about 1MB less RAM:
Code: Select all
$ /usr/bin/time -v php test.php
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100
Command being timed: "php test.php"
User time (seconds): 0.01
System time (seconds): 0.00
Percent of CPU this job got: 83%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.03
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): 16212
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 1259
Voluntary context switches: 1
Involuntary context switches: 109
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
$ /usr/bin/time -v /var/www/cgi-bin/lcs/lcs961 test.lc
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100
Command being timed: "/var/www/cgi-bin/lcs/lcs961 test.lc"
User time (seconds): 0.01
System time (seconds): 0.01
Percent of CPU this job got: 87%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.03
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): 15284
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 1120
Voluntary context switches: 1
Involuntary context switches: 107
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
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Livecode Server performance
thank you for your explanation.
whether Livecode can run as a webserver without apache?
like GOLang it has the ability to run its own web server without apache or nginx.
the "open socket" command in the directory allows for that?
whether Livecode can run as a webserver without apache?
like GOLang it has the ability to run its own web server without apache or nginx.
the "open socket" command in the directory allows for that?
Re: Livecode Server performance
Hi,
for your information:
Thx to Richard/ Panos (in bug report 23163) it has been found out that there are new, added dependencies in the LC 9 server series:
This explains the segFaults I talked about (above) & will prohibit the use of any LC 9 server on more stringent configured servers that will not come with some of these installed (for instance Ubuntu 20.04).
That also may have a noticeable impact on LC server performance when used as CGI - after all, the size of the executable has grown to 24MB (9.6.2.rc5), from ~17MB (8.0), and ~6MB (6.7.10-32).
Too bad there's no 6.7.10-64 server, such a beast should wipe the floor even with PHP 7.2! One of these days (when I get rich finally ...) I'll post a bounty for a LC 6.7.10-64 ;-)
Have fun!
for your information:
Thx to Richard/ Panos (in bug report 23163) it has been found out that there are new, added dependencies in the LC 9 server series:
Code: Select all
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fbb81611000)
libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007fbb81352000)
libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007fbb81110000)
libz.so.1 => /lib64/libz.so.1 (0x00007fbb80104000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fbb7fef4000)
libpng15.so.15 => /lib64/libpng15.so.15 (0x00007fbb7fcc9000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fbb7fac4000)
That also may have a noticeable impact on LC server performance when used as CGI - after all, the size of the executable has grown to 24MB (9.6.2.rc5), from ~17MB (8.0), and ~6MB (6.7.10-32).
Too bad there's no 6.7.10-64 server, such a beast should wipe the floor even with PHP 7.2! One of these days (when I get rich finally ...) I'll post a bounty for a LC 6.7.10-64 ;-)
Have fun!
All code published by me here was created with Community Editions of LC (thus is GPLv3).
If you use it in closed source projects, or for the Apple AppStore, or with XCode
you'll violate some license terms - read your relevant EULAs & Licenses!
If you use it in closed source projects, or for the Apple AppStore, or with XCode
you'll violate some license terms - read your relevant EULAs & Licenses!
-
- VIP Livecode Opensource Backer
- Posts: 9847
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Livecode Server performance
Anything that handles standard Unix sockets can use those sockets to support the HTTP protocol (or nearly any other socket-based protocol).
In fact, there's an HTTP server library included with the LiveCode you have installed on your machine right now, used for testing via localhost.
A simple web server was included in the older MetaCard product before LC acquired it, and a few years ago I updated that to handle the more modern HTTP 1.1:
http://fourthworld.net/lc/mchttpd-4W.zip
It's fun, and these types of tools can be *very* useful during development. But I wouldn't suggest running a production server with them.
I haven't used Go's httpd so I have no opinion about it. Apache is the most commonly used, with Lightly being a leaner, faster drop-in replacement. Use cases involving static files often benefit from NginX, and web services sometimes use Node.js directly. And there are many others.
Which is best depends on what you're doing. As a general rule, I use Apache unless I have a specific reason to use something else. It's too easy to spend years evaluating all possible options for all possible use cases, taking the strengths, weaknesses, and tradeoffs inherent in each into account.
Apache offers a good mix of efficient static file serving with many options for adding dynamic processing. It's well documented, more than any other server package; its popularity makes it the most documented and supported web server package on the planet.
It's possible to write one in a scripting language, and that can be very useful for specific tasks. But scripting an httpd in my spare time cannot match the performance of compiled machine code purpose-built by an army specialists over many years.
That didn't stop me from having fun experimenting, though. Here's a summary of my results:
http://lists.runrev.com/pipermail/use-l ... 23364.html
Bonus: Pierre Zahores is among the most experienced in our community with providing web services, and my post above was in response to a very interesting set of siege benchmarks he posted, showing how a pool of LC workers behind NGinX was rather blazingly fast:
http://lists.runrev.com/pipermail/use-l ... 23353.html
Bottom line: HTTP parsing and socket management are boring commodity tasks best performed by boring commodity packages purpose-built for that one role. The good ones have extensibility, where you can plug in LC and spend your time focusing on the functionality unique to your app.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 9847
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Livecode Server performance
Smaller is always better, but I'm not sure the file size of the executable will matter much, at least not with current sizes. In my time test results above I used -v to get RAM usage as well, and found that LC used about 1 MB less than PHP for the given task. And besides, with Linux caching you're not pulling from disk very often.
That said, if there were a Lean Edition of LC Server I'd like it, not so much for the size but for the fewer sys calls on boot.
I was using standalones for CGI long before LC Server was invented, and for some installations still do. If your server will run LC 6.7, go for it. The only thing you lose with the standalone is Server's PHP-style implicit merge, but the built-in merge function is close enough where needed, and for many services I don't mix output with HTML at all anyway.Too bad there's no 6.7.10-64 server, such a beast should wipe the floor even with PHP 7.2! One of these days (when I get rich finally ...) I'll post a bounty for a LC 6.7.10-64
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn