The benefit of FastCGI would be that the Fast cgi instance would always be running and would not need to be restarted every time a .lc script is parsed saving on the execution time.
Even as a CGI process, LiveCode should already be able to run behind a load balancing server, Kind Regards Simon On Tue, Nov 25, 2014 at 10:23 AM, Peter W A Wood <peterwaw...@gmail.com> wrote: > Hi Andre > > I agree with your comments on the appropriateness of the tests. I’ll give > some thought to incorporating more I/O based tests. > > Do you think that having FastCGI support so that LiveCode could be run > behind a load balancing server would be an improvement from a scalability > point of view. > > Regards > > Peter > > > On 24 Nov 2014, at 23:42, Andre Garzia <an...@andregarzia.com> wrote: > > > > Hi Peter, > > > > Thanks for your testing! > > > > I think we're approaching this performance issue wrong. Most webapps will > > be I/O bound and not CPU bound. Calculations are not the most common > thing > > going on but I/O in the sense of reading and writing from database and > > files are. Also the only way to deal with structured data in memory in a > > straight forward way is LiveCode multilevel arrays but there is no > built-in > > way to serialize these arrays for consumption outside of LiveCode. For > > example, a common thing these days is to have your client-side HTML5 code > > calling back your server-side code for more information which is normally > > presented in JSON but LiveCode has no built-in function for JSON encoding > > and decoding, so both operations happen in pure transcript (or whatever > > they are calling it these days) which will make it really slow. > > > > If we want LiveCode to have better performance we need ways to improve > I/O. > > Things that would be good and have a real impact out of the box: > > > > - JSON and XML encode and decode functions in the engine. > > - Non-blocking DB routines > > > > > > A different issue is scalability. Right now, LiveCode Server works in CGI > > mode which is very straight forward but it is not the most scalable thing > > under the sun. When I say scale, I am not saying things such as serving > > 5.000 users. Serving a couple thousand users is easy. I am saying serving > > some hundred thousand users with complex server side logic, afterall > doing > > 100.000 hello worlds is easy. > > > > PHP is going thru lots of revolutions in the form of the Facebook > > initiatives such as "hack" (new PHP variation), that VM they created and > > the little compiler they created which I forgot the name. The PHP > > developers are also pushing PHPNG and other gizmos. Even current > generation > > PHP is not usually server with CGI technology. > > > > Ruby, Node, Python, Clojure, Java, none are served with CGI. Most of them > > could be used as CGI but no one is using them this way. CGI is easy but > it > > is not scalable. Imagine that if you were serving 10.000 concurrent > > requests on your little server farm, you're have a collection of 10.000 > > LiveCode server processes between your servers. > > > > What we need is something like Python WSGI or a non-blocking engine such > as > > Node. Then we could with a simple pool of couple LiveCode engine > instances > > serve a lot of people. > > > > On Mon, Nov 24, 2014 at 1:33 AM, Peter W A Wood <peterwaw...@gmail.com> > > wrote: > > > >> In a previous email Richard Gaskin, the LiveCode Community Manager, > wrote > >> "Given the role of memory and performance for scaling, if we want to > see LC > >> Server taken seriously as a professional server tool we need to identify > >> and eliminate any significant performance difference between it and > PHP.” > >> > >> I thought that it would be worth spending a little time to compare the > >> speed of LiveCode against the speed of PHP. I came up with a test based > >> loosely on Carl Sassenrath’s Rebol Speed Script ( > >> http://www.rebol.com/cgi-bin/blog.r?view=0506 ). I have found it a > useful > >> base for writing comparative scripts (either comparing languages on a > >> single machine or comparing machines using a single language). It is far > >> from perfect in a multi-tasking environment but I believe provides > decent > >> comparative data. > >> > >> I have attached two scripts, speedtest.lc and speedtest.php. I’m sure > >> that both could be improved significantly and welcome such improvements. > >> The results of running the two scripts on my machine, LiveCode > 7.0.0-rc-3 > >> and PHP 5.5.14 are: > >> > >> Schulz:LiveCodeServer peter$ ./speedtest.lc > >> LiveCode Speed Test Started > >> The CPU test took: 2851 ms > >> The Memory test took: 3656 ms > >> The File System test took: 1975 ms > >> LiveCode Speed Test Finished > >> > >> Schulz:LiveCodeServer peter$ ./speedtest.php > >> PHP Speed Test Started > >> The CPU test took: 3921 ms > >> The Memory test took: 1200 ms > >> The File System test took: 666 ms > >> PHP Speed Test Finished > >> > >> So it seems the LiveCode has the edge on PHP when it comes to > calculations > >> but not on memory access or file access. > >> > >> The memory test relies on using arrays, I'm not sure if that is the best > >> way to test memory access. > >> > >> Regards > >> > >> Peter > >> > >> Speedtest.lc > >> > >> #!livecode > >> > >> if the platform = "MacOS" then > >> set the outputLineEndings to "lf" > >> end if > >> > >> put "LiveCode Speed Test Started" & return > >> > >> ##cpu test > >> put the millisecs into tStart > >> repeat with i = 1 to 10000000 > >> put sqrt(exp(i)) into tTemp > >> end repeat > >> put the millisecs into tEnd > >> put "The CPU test took: " && tEnd - tStart && "ms" & return > >> > >> ##Memory Access > >> put the millisecs into tStart > >> repeat with i = 1 to 1000000 > >> put random(255) into tMem[i] > >> end repeat > >> put the millisecs into tEnd > >> put "The Memory test took: " && tEnd - tStart && "ms" & return > >> > >> ##Filesystem > >> open file "test.tmp" > >> put the millisecs into tStart > >> repeat with i = 1 to 100000 > >> write "This is a test of the write speed" && random(255) to file > >> "test.tmp" > >> read from file "test.tmp" for 1 line > >> end repeat > >> put the millisecs into tEnd > >> put "The File System test took:" && tEnd - tStart && "ms" & return > >> delete file "test.tmp" > >> > >> ##Finish > >> put "LiveCode Speed Test Finished" & return > >> > >> Speedtest.php > >> > >> #!/usr/bin/php > >> > >> <?php > >> > >> print "PHP Speed Test Started\n"; > >> > >> //cpu test > >> $start = microtime(true); > >> for( $i = 0; $i < 10000000; $i++ ) { > >> $temp = sqrt(exp($i)); > >> } > >> $end = microtime(true); > >> $time = ($end - $start) * 1000 + 0.5; > >> printf("The CPU test took: %5.0f ms\n", $time); > >> > >> //Memory Access > >> $start = microtime(true); > >> for( $i = 0; $i < 1000000; $i++ ) { > >> $mem[i] = rand(0, 255); > >> } > >> $end = microtime(true); > >> $time = ($end - $start) * 1000 + 0.5; > >> printf("The Memory test took: %5.0f ms\n", $time); > >> > >> //Filesystem > >> $file = fopen("test.tmp", "w+"); > >> $start = microtime(true); > >> for( $i = 0; $i < 100000; $i++ ) { > >> rewind($file); > >> fwrite($file, "This is a test of the write speed".rand(0,255)); > >> fread($file, 34); > >> } > >> $end = microtime(true); > >> $time = ($end - $start) * 1000 + 0.5; > >> printf("The File System test took: %5.0f ms\n", $time); > >> unlink("test.tmp"); > >> > >> //Finish > >> print "PHP Speed Test Finished\n"; > >> > >> ?> > >> > >> > >> > >> _______________________________________________ > >> 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 > > > > > > > > > > -- > > http://www.andregarzia.com -- All We Do Is Code. > > http://fon.nu -- minimalist url shortening service. > > _______________________________________________ > > 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 > -- *Simon Smith* *seo, online marketing, web development* w. http://www.simonsmith.co m. +27 83 306 7862 _______________________________________________ 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
