Could it be the GIIL. web2py is a multi-threaded app. Are the threads created by the web server doing anything? What if you use a non-threaded server like gunicorn instead?
On Saturday, 15 March 2014 21:34:56 UTC-5, 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
