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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
