Hello Richard, > Le 29 mars 2016 à 17:44, Richard Gaskin <ambassa...@fourthworld.com> a écrit : > > Pierre Sahores wrote: > >> If your lcHTTPd standalone is a TCP sockets server, the low TOP load >> (less than 25%) is not surprising at all and can even go lots less in >> using nginx instead of apache... > > Yes, the benefits of using NginX as the broker instead of Apache are well > documented in these articles on achieving high concurrency counts on cheap > VPSes (see note on funky url formats below): > http COLON SLASH SLASH > markmaunder.com/2009/12/01/how-to-handle-1000s-of-concurrent-users-on-a-360mb-vps/ > http COLON SLASH SLASH > reviewsignal.com/blog/2014/06/25/40-million-hits-a-day-on-wordpress-using-a-10-vps/
Interesting reads even if the 2d article's last test related to micro-caching needs to be read with care : this will only work against CMS targets where mostly always the same pages are served. As soon as a real-world networked apps will serve millions of atomic different requests (E-Commerce, CRM, ERP, Most of the big Saas applications,…), those performances will reasonably and rationally decrease in the following way : In using multi-core standalone servers (VLANs always deliver less suitable performances per buck invested), if needed interconnected in master-slaves modes via software proxying (Nginx excels in this task too) : - more than 90% read requests : nginx+luajit (openresty) + well configured micro caching -> multi-thousands of requests / second (lots less under apache2 because its architecture bottlenecks); - 50% read / 50% write : nginx+luajit (openresty) + well configured socket’s accessible application server (my own Livecode’s application server fork soon on GITHUB, Tarantool by mail.ru, as both the most suitable to date, ) + PostgreSQL or an other serious skilled ACID-SQL RDBMS (AKA: MySQL/MariaDB excluded) + round-robin proxying of the client’s incoming requests -> : up to thousands of requests / second (lots less under apache2) - 50% read / 50% write : nginx+luajit (openresty) + LUA or fine tuned/Heap RAM scaled Tomcat7 : thousands of requests / second (lots less under apache2) - 50% read / 50% write : nginx+luajit (openresty) in its fastCGI different API (FastCGI, FMP-PHP, FCGIWrap,…) + CGI engine (JSP, PHP, LC, Perl, Python, RoR,… : hundreds of requests / second (lots less under apache2) - 30% read / 70% write and less : nginx+luajit (openresty) + well configured socket’s accessible application's servers (my own Livecode’s application server fork, Tarantool by mail.ru, or, lots more expensive options instead : JBoss2, Websphere, WebLogic,… ) + PostgreSQL or an other serious skilled ACID-SQL RDBMS are mandatory to be sure that the full scalable periodic bottleneck will always stay on the RDBMS side. It will, by the way, never become a problem as long as technical skills are, there, the sole needs to scale-up on demand such configurations (dynamically or manually) in adding application’s servers instances (one per TCP port behind a round-robin proxy to made the story short) and slave nodes to the RDBMS cluster (physical servers instances needed there, even if lots of VirtualBoxed ones are, in fact, promoted by the IT services providers… -> unrecoverable crashes happening on ACID-SQL RDBMS what is conceptually impossible in hosting each one on its own physical server) note : see about Tarantool : http://tarantool.org/doc/intro.html#an-application-server-together-with-a-database-manager note : Tarantool is the platform i have decided to choose after careful AB tests as the host of my Livecode’s application server port to LUA with lots less to do as i expected previously, most of the work having been very well done for us by the mail.ru engineers. note : Tarantool is , in short, a deamon witch embedded the LuaJIT virtual machine in the exact same way Livecode let us embed the Livecode engine inside a deamon. If you read this, Mark, Kevin,… Well powered behind an Opentesty front-end (Nginx/LuaJIT), Livecode application’s server (demon fork) can do exactly all what Tarantool is able to do « et réciproquement », no less, no more while, in the mean time, Tomcat, JBoss2, Websphere, etc… just can’t, even in a very more costly price range (millions), as i use to verify it recently in being hired for an audit of one of the two SAP Hybris multi canal e-commerce suite / associated soft/hardware infrastructure handling the online shop services of the french « La Poste » postal service company... > > But my test setup was a bit weirder: lcHTTPd doesn't use Apache at at all. > > The only thing handling the transactions is that one humble single-threaded > LC standalone process. Probably not the best way to go to setup a slave-mode reliable and WAF well protected server-side solution. I would recommend, at least, a basic Apache+LC CGI server configuration instead or, best, a Nginx+FCGIWrap+LC CGI server. The solutions available permits to deliver 50 pages/second on appropriate VPS or hosting services and on the reliability side, WAF configuration included), such configuration really helps to avoid big problems (unreachability, data loss, piracy, etc…). > > Once moved behind a reverse proxy such a tool could easily handle very high > loads, using the LC engine we know and love today. For sure, clearly preferable : LC CGI is’t aimed to be an F-16 in about speed BUT IT IS 100% RELIABLE AS LONG IT IS CLEANLY CONFIGURED AND RUNS WELL CODED ROW OR, BEST, REVIGNITER POWERED SOLUTIONS. > > Coupled with something like Andre's revSpark library for easily crafting > RESTful APIs revised for an always-on process like lcHTTPd, the range of > scalable, performant ad hoc microservices solutions that could be deployed > ultra-rapidly with LiveCode is nearly endless. > > Message-based server architectures are all the rage lately, and when we take > full advantage of callbacks for network I/O we LiveCoders find we've had the > opportunity to enjoy them all along. I never being a JSON nor XML fan in about reliability and high trafic throughput and was’t sole in this case. Fortunately, the FullREST and MessagePack ways to go covers most of n-tier powered apps in the most reliable ways (and without buzz needs at all !). note : see about MessagePack : http://msgpack.org/ > > Did you see Charles Warwick's post last June about a Docker container for LC > Server?: > http COLON SLASH SLASH > lists.runrev.com/pipermail/use-livecode/2015-July/216882.html I did’t. Thanks for pointing it out to me. Will read it attentively. On the other hand, i did, months ago, extensive tests in running a good num of Docker VM and to the end, i went to the conclusion that such configurations can’t compete against real-world configuration because the Docker concept itself : well to slow to replace production’s dedicated platforms. > > I can imagine a Docker container, and perhaps a Juju charm for Ubuntu Server > and even a Snap for the newer Ubuntu Core, set up to deploy a complete > LiveCode microservices solution in one line.... > > Ah, if only I had more time for such things. The funny part is that I'm > discovering we have solutions for far larger server loads than any project > I'm currently working on actually needs. :) Not just about fun but indeed... : did you test an Ubuntu smartphone / tablet ? I’m really curious about this and no far from abandoning Android after iOS for my personal needs if it can work as smoothly on phone as it runs on our laptops and server today ;D > > PS - Note on funky URL formats: This is my fifth attempt to send this email > to the list. In trying to discern why some of my emails come through while > others don't, it occurred to me that only those with URLs in them were > blocked from posting. Since no bounce message was received and I haven't yet > heard back from support I can only guess how I need to post here now while > this seeming email filter problem gets sorted out, so please forgive the > funky URL format and if my other emails eventually come through please > forgive the redundancy. PS : sent this one from mail (El Capitan) without tourbe. Seems to be OK when i use Thunderbird from Ubuntu 14.04 too. Did you report this to David ? PS2: I’m a Debian and Ubuntu fan. Would never roll back anymore to Suse (so fine before being sold to Netware) or RedHat/CentOS… Cheers, Pierre > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > ____________________________________________________________________ > ambassa...@fourthworld.com http://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 -- Pierre Sahores mobile : 06 03 95 77 70 www.sahores-conseil.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
