@Massiom, @hb > python anyserver.py -s gunicorn -i 127.0.0.1 -p 8000
with the above just one worker is started, hence requests are serialized. 2014-03-17 1:03 GMT+01:00 Massimo Di Pierro <massimo.dipie...@gmail.com>: > easy_install gunicorn > cd web2py > python anyserver.py -s gunicorn -i 127.0.0.1 -p 8000 > > Anyway, you need to run a test that does not include "import Package first" > Because definitively treats imports differently. That must be tested > separately. > > Massimo > > > > On Sunday, 16 March 2014 15:31:17 UTC-5, horridohobbyist wrote: >> >> Well, I managed to get gunicorn working in a roundabout way. Here are my >> findings for the fred.py/hello.py test: >> >> Elapsed time: 0.028 >> Elapsed time: 0.068 >> >> Basically, it's as fast as the command line test! >> >> I'm not sure this tells us much. Is it Apache's fault? Is it web2py's >> fault? The test is run without the full web2py scaffolding. I don't know how >> to run web2py on gunicorn, unless someone can tell me. >> >> >> On Sunday, 16 March 2014 16:21:00 UTC-4, Michele Comitini wrote: >>> >>> gunicorn instructions: >>> >>> $ pip install gunicorn >>> $ cd <root dir of web2py> >>> $ gunicorn -w 4 gluon.main:wsgibase >>> >>> >>> >>> 2014-03-16 14:47 GMT+01:00 horridohobbyist <horrido...@gmail.com>: >>> > I've conducted a test with Flask. >>> > >>> > fred.py is the command line program. >>> > hello.py is the Flask program. >>> > default.py is the Welcome controller. >>> > testdata.txt is the test data. >>> > shippackage.py is a required module. >>> > >>> > fred.py: >>> > 0.024 second >>> > 0.067 second >>> > >>> > hello.py: >>> > 0.029 second >>> > 0.073 second >>> > >>> > default.py: >>> > 0.27 second >>> > 0.78 second >>> > >>> > The Flask program is slightly slower than the command line. However, >>> > the >>> > Welcome app is about 10x slower! >>> > >>> > Web2py is much, much slower than Flask. >>> > >>> > I conducted the test in a Parallels VM running Ubuntu Server 12.04 (1GB >>> > memory allocated). I have a 2.5GHz dual-core Mac mini with 8GB. >>> > >>> > >>> > I can't quite figure out how to use gunicom. >>> > >>> > >>> > On Saturday, 15 March 2014 23:41:49 UTC-4, horridohobbyist wrote: >>> >> >>> >> I'll see what I can do. It will take time for me to learn how to use >>> >> another framework. >>> >> >>> >> As for trying a different web server, my (production) Linux server is >>> >> intimately reliant on Apache. I'd have to learn how to use another web >>> >> server, and then try it in my Linux VM. >>> >> >>> >> >>> >> On Saturday, 15 March 2014 22:45:27 UTC-4, Anthony wrote: >>> >>> >>> >>> Are you able to replicate the exact task in another web framework, >>> >>> such >>> >>> as Flask (with the same server setup)? >>> >>> >>> >>> On Saturday, March 15, 2014 10:34:56 PM UTC-4, horridohobbyist wrote: >>> >>>> >>> >>>> Well, putting back all my apps hasn't widened the discrepancy. So I >>> >>>> don't know why my previous web2py installation was so slow. >>> >>>> >>> >>>> While the Welcome app with the calculations test shows a 2x >>> >>>> discrepancy, >>> >>>> the original app that initiated this thread now shows a 13x >>> >>>> discrepancy >>> >>>> instead of 100x. That's certainly an improvement, but it's still too >>> >>>> slow. >>> >>>> >>> >>>> The size of the discrepancy depends on the code that is executed. >>> >>>> Clearly, what I'm doing in the original app (performing >>> >>>> permutations) is >>> >>>> more demanding than mere arithmetical operations. Hence, 13x vs 2x. >>> >>>> >>> >>>> I anxiously await any resolution to this performance issue, whether >>> >>>> it >>> >>>> be in WSGI or in web2py. I'll check in on this thread >>> >>>> periodically... >>> >>>> >>> >>>> >>> >>>> On Saturday, 15 March 2014 16:19:12 UTC-4, horridohobbyist wrote: >>> >>>>> >>> >>>>> Interestingly, now that I've got a fresh install of web2py with >>> >>>>> only >>> >>>>> the Welcome app, my Welcome vs command line test shows a consistent >>> >>>>> 2x >>> >>>>> discrepancy, just as you had observed. >>> >>>>> >>> >>>>> My next step is to gradually add back all the other apps I had in >>> >>>>> web2py (I had 8 of them!) and see whether the discrepancy grows >>> >>>>> with the >>> >>>>> number of apps. That's the theory I'm working on. >>> >>>>> >>> >>>>> Yes, yes, I know, according to the Book, I shouldn't have so many >>> >>>>> apps >>> >>>>> installed in web2py. This apparently affects performance. But the >>> >>>>> truth is, >>> >>>>> most of those apps are hardly ever executed, so their existence >>> >>>>> merely >>> >>>>> represents a static overhead in web2py. In my mind, this shouldn't >>> >>>>> widen the >>> >>>>> discrepancy, but you never know. >>> >>>>> >>> >>>>> >>> >>>>> On Saturday, 15 March 2014 11:19:06 UTC-4, Niphlod wrote: >>> >>>>>> >>> >>>>>> @mcm: you got me worried. Your test function was clocking a hell >>> >>>>>> lower >>> >>>>>> than the original script. But then I found out why; one order of >>> >>>>>> magnitude >>> >>>>>> less (5000 vs 50000). Once that was corrected, you got the exact >>> >>>>>> same clock >>> >>>>>> times as "my app" (i.e. function directly in the controller). I >>> >>>>>> also >>> >>>>>> stripped out the logging part making the app just return the >>> >>>>>> result and no >>> >>>>>> visible changes to the timings happened. >>> >>>>>> >>> >>>>>> @hh: glad at least we got some grounds to hold on. >>> >>>>>> @mariano: compiled or not, it doesn't seem to "change" the mean. a >>> >>>>>> compiled app has just lower variance. >>> >>>>>> >>> >>>>>> @all: jlundell definitively hit something. Times are much more >>> >>>>>> lower >>> >>>>>> when threads are 1. >>> >>>>>> >>> >>>>>> BTW: if I change "originalscript.py" to >>> >>>>>> >>> >>>>>> # -*- coding: utf-8 -*- >>> >>>>>> import time >>> >>>>>> import threading >>> >>>>>> >>> >>>>>> def test(): >>> >>>>>> start = time.time() >>> >>>>>> x = 0.0 >>> >>>>>> for i in range(1,50000): >>> >>>>>> x += (float(i+10)*(i+25)+175.0)/3.14 >>> >>>>>> res = str(time.time()-start) >>> >>>>>> print "elapsed time: "+ res + '\n' >>> >>>>>> >>> >>>>>> if __name__ == '__main__': >>> >>>>>> t = threading.Thread(target=test) >>> >>>>>> t.start() >>> >>>>>> t.join() >>> >>>>>> >>> >>>>>> I'm getting really close timings to "wsgi environment, 1 thread >>> >>>>>> only" >>> >>>>>> tests, i.e. >>> >>>>>> 0.23 min, 0.26 max, ~0.24 mean >>> >>>>>> >>> > -- >>> > 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. -- 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.
