You basically need to cd into the directory where you have unzipped web2py. Then run gunicorn like the following: gunicorn -w 4 gluon.main:wsgibase
There you have web2py reachable on http://localhost:8000 Which part does not work for you? 2014-03-16 21:31 GMT+01:00 horridohobbyist <horrido.hobb...@gmail.com>: > 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.
