In 2007, I wrote my first web application using Smalltalk/Seaside. I chose Seaside because it was a very easy-to-learn, easy-to-program, easy-to-deploy, highly productive, self-contained all-in-one web framework. (It still is, today.) Unfortunately, web2py hadn't been born yet, but clearly the two frameworks had similar goals. (Born in 2002, Seaside has 5 years over web2py.)
I deployed the Seaside app under Apache on the same hardware that I'm using today for web2py. Yes, my 2.4GHz quad-core Xeon Dell server with 4GB RAM is over 7 years old!! Recently, I switched over to web2py because I had heard so many good things about it. I can now say that web2py is far superior to Seaside. It's even more easy-to-learn and easy-to-program; it's even more productive. And Seaside was pretty darn good in this respect! I believe web2py is the best available web framework in the world today, regardless of language (ie, Java, Ruby, PHP, etc.). I am 100% in agreement with its philosophy and goals. Please, keep up the good work! On Wednesday, 19 March 2014 07:27:54 UTC-4, horridohobbyist wrote: > > Yes, "processes=3" and "threads=1". > > I tried "processes=1" and "threads=3", and performance was still 10x bad. > So I guess that answers my question: the threads parameter is not helpful. > > > On Wednesday, 19 March 2014 05:24:01 UTC-4, Tim Richardson wrote: >> >> Did you explicitly set the number of threads as well? By default you get >> 15 threads per process. The documentation implies that this is a hard >> limit, but I'm not sure. >> Maybe you have simply found a bottleneck in threads. Did you also try >> increasing the number of threads instead of adding more processes? >> Multi-threaded apache is supposed to be faster than multi-process apache >> under real load (i.e. multiple users) because starting (and switching) >> processes is expensive in time and memory.* >> So any conclusion that you need more processes is dubious, I think. I >> can't recall how many simultaneous users your benchmarking is testing. >> Bear in mind that the fastest servers, the greenlet or co-operative async >> servers, are not only limited to one process, but even to one thread. >> >> http://nichol.as/benchmark-of-python-web-servers >> >> >> >> >> >> >> >> >> >> >> On Wednesday, 19 March 2014 14:25:47 UTC+11, horridohobbyist wrote: >>> >>> I shall do that. Thanks. >>> >>> With the knowledge about "processes=", I've tuned my actual Linux server >>> to eliminate the 10x slowdown. As it turns out, for my 2.4GHz quad-core >>> Xeon with 4GB RAM, "processes=2" works best. I found that any other value >>> (3, 4, 5) gave very inconsistent results–sometimes I would get 1x (the >>> ideal) and sometimes I would get 10x. Very bizarre. >>> >>> "processes=2" is counter-intuitive. After all, I have 4 cores. Why >>> shouldn't "processes=4" be good? >>> >>> Anyway, not only is the shipping code fast, but I find that my overall >>> web2py app feels a lot snappier. Is it just my imagination? >>> >>> If "processes=2" is boosting the speed of Python in general, then you >>> would expect all of web2py to benefit. So maybe it's not my imagination. >>> >>> Anyway, the takeaway, I think, is that you must tune the Apache >>> configuration for the particular server hardware that you have. The default >>> "processes=1" is not good enough. >>> >>> >>> On Tuesday, 18 March 2014 22:37:58 UTC-4, Massimo Di Pierro wrote: >>>> >>>> Thank you for all your tests. You should write a summary of your >>>> results with recommendations for Apache users. >>>> >>>> On Tuesday, 18 March 2014 19:44:29 UTC-5, horridohobbyist wrote: >>>>> >>>>> Done. With processes=3, the 10x discrepancy is eliminated! (And this >>>>> is in a Linux VM configured for 1 CPU.) >>>>> >>>>> >>>>> On Tuesday, 18 March 2014 16:26:24 UTC-4, Michele Comitini wrote: >>>>>> >>>>>> > WSGIDaemonProcess hello user=www-data group=www-data threads=5 >>>>>> >>>>>> with web2py try the following instead: >>>>>> WSGIDaemonProcess hello user=www-data group=www-data >>>>>> processes=<number >>>>>> of cores + 1> threads=(0 or 1) >>>>>> >>>>>> If it's faster, then the GIL must be the cause. flask by default has >>>>>> much less features active (session for instance) >>>>>> >>>>>> >>>>>> >>>>>> 2014-03-18 21:04 GMT+01:00 horridohobbyist <horrido...@gmail.com>: >>>>>> > I took the shipping code that I ran in Flask (without Apache) and >>>>>> adapted it >>>>>> > to run under Apache as a Flask app. That way, I'm comparing apples >>>>>> to >>>>>> > apples. I'm comparing the performance of the shipping code between >>>>>> Flask and >>>>>> > web2py. >>>>>> > >>>>>> > Below, I've included the 'default' file from >>>>>> Apache2/sites-available for >>>>>> > Flask. >>>>>> > >>>>>> > Basically, the code in Flask executes 10x faster than the same code >>>>>> in >>>>>> > web2py. So my question is: if Apache is at fault for the web2py >>>>>> app's slow >>>>>> > performance, why doesn't Apache hurt the Flask app's performance? >>>>>> (This >>>>>> > doesn't seem to be related to GIL or WSGI.) >>>>>> > >>>>>> > >>>>>> > <VirtualHost *:80> >>>>>> > ServerName 10.211.55.7 >>>>>> > WSGIDaemonProcess hello user=www-data group=www-data threads=5 >>>>>> > WSGIScriptAlias / /home/richard/welcome/hello.wsgi >>>>>> > >>>>>> > <Directory /home/richard/welcome> >>>>>> > Order Allow,Deny >>>>>> > Allow from all >>>>>> > </Directory> >>>>>> > </VirtualHost> >>>>>> > >>>>>> > -- >>>>>> > Resources: >>>>>> > - http://web2py.com >>>>>> > - http://web2py.com/book (Documentation) >>>>>> > - http://github.com/web2py/web2py (Source code) >>>>>> > - https://code.google.com/p/web2py/issues/list (Report Issues) >>>>>> > --- >>>>>> > You received this message because you are subscribed to the Google >>>>>> Groups >>>>>> > "web2py-users" group. >>>>>> > To unsubscribe from this group and stop receiving emails from it, >>>>>> send an >>>>>> > email to web2py+un...@googlegroups.com. >>>>>> > For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
